90 likes | 210 Views
2929bis etc. Donald E. Eastlake 3 rd +1-508-786-7554 Donald.Eastlake@motorola.com. Contents. Security Algorithm Related Drafts draft-ietf-dnsext-ecc-key-08.txt draft-ietf-dnsext-rfc2536bis-dsa-06.txt draft-ietf-dnsext-rfc2539bis-dhk-06.txt
E N D
2929bis etc. Donald E. Eastlake 3rd +1-508-786-7554 Donald.Eastlake@motorola.com IETF DNSEXT
Contents • Security Algorithm Related Drafts • draft-ietf-dnsext-ecc-key-08.txt • draft-ietf-dnsext-rfc2536bis-dsa-06.txt • draft-ietf-dnsext-rfc2539bis-dhk-06.txt • DNS IANA Considerations updated based on extensive discussion at last meeting in Paris • draft-ietf-dnsext-2929bis-01.txt IETF DNSEXT
More on Algorithm Drafts • draft-ietf-dnsext-ecc-key-08.txt • formerly draft-schroeppel-dnsind-ecc-*.txt • Clarified that it also covers signatures using SHA-1. • Could use more feedback on draft, ideally from implementers. • Updates to remove SIG/KEY RR dependency and update DNSSEC RFC references: • draft-ietf-dnsext-rfc2536bis-dsa-06.txt • Updates DSA key/signature RFC • draft-ietf-dnsext-rfc2539bis-dhk-06.txt • Updates Diffie-Hellman key RFC IETF DNSEXT
Elliptic Curve Crypto • A Public Key system. • Keys, signatures, etc., much more compact than RSA. [RFC 3766] • A standard format is needed for interoperability. • There are numerous patents and claims related to implementations, etc. However, NSA will be broadly re-licensing a number of patents for elliptic curves of GF(p) for p a prime greater than 2255. • This draft (-08) defines both a key format and a signature format using Algorithm #4 previously reserved for this purpose and SHA-1 for signatures. IETF DNSEXT
RFC 2929 • RFC 2929 Provided first IANA considerations for RR TYPEs, CLASSes, RCODEs, OpCodes, header bits, etc. • RFD 2929 generally provides some Private Use, some Publication Required, some IETF Consensus, and few reserved or Standards Action required allocation policies. IETF DNSEXT
RFC 2929 (cont.) • Problem: • “IETF Consensus” and even “Specification Required” were considered too hard for allocating Type Codes, so people overload TXT, etc. • Solution? • There initially appeared to be a strong desire for a liberalized version of “Early Allocation” (RFC 4020) which was put in draft -00. • Then there was a backlash with “Expert Review” desired for Type Codes and with most other parameters about as specified in RFC 2929. IETF DNSEXT
RFC 2929bis • Primary Effect: Replace RFC 2929 with a more liberal document • draft-ietf-dnsext-2929bis-01.txt • Changes: • Replace “IETF Consensus” for RR Type Codes with “DNS Type Allocation Policy” • Cover AFSDB Subtypes per IETF Consensus • Augment “IETF Standards Action” for Op Codes with “as modified by [RFC 4020]”. • Provides some Specification Required RCODE allocation • Update references, other very minor changes IETF DNSEXT
RFC 2929bis DNS Type Allocation Policy • About half of the RR Type Codes can be allocated with • Expert Review • after a completed DNS RR Type Allocation Template has been posted for at least three weeks on the namedroppers mailing list. • (most of the other half is “Specification Required”) IETF DNSEXT
DNS RR Type Parameter Allocation Template • Provides for • Date • Name and email of originator • Pointer to detailed RR description document • Need for new RR Type? • Closest existing RR Type • Does new RR Type require special handling different from an Unknown RR Type? IETF DNSEXT