1. Slide 1 November 2005, Vancouver, BCIETF DNSEXT 2929bis etc. Donald E. Eastlake 3 rd +1-508-786-7554 Donald.Eastlake@motorola.com

2. Slide 2 November 2005, Vancouver, BCIETF 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

3. Slide 3 November 2005, Vancouver, BCIETF 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

4. Slide 4 November 2005, Vancouver, BCIETF 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 2 255. 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.

5. Slide 5 November 2005, Vancouver, BCIETF 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.

6. Slide 6 November 2005, Vancouver, BCIETF 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.

7. Slide 7 November 2005, Vancouver, BCIETF 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

8. Slide 8 November 2005, Vancouver, BCIETF 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”)

9. Slide 9 November 2005, Vancouver, BCIETF 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?