1. Slide 1 August 2005, Paris, FranceIETF DNSEXT 2929bis etc. Donald E. Eastlake 3 rd +1-508-786-7554 Donald.Eastlake@motorola.com

2. Slide 2 August 2005, Paris, FranceIETF DNSEXT Contents Pretty Quick Items –draft-ietf-dnsext-tsig-sha-04.txt –draft-ietf-dnsext-ecc-key-06.txt –draft-ietf-dnsext-rfc2536bis-dsa-06.txt –draft-ietf-dnsext-rfc2539bis-dhk-06.txt Not So Quick Item –draft-ietf-dnsext-2929bis-00.txt

3. Slide 3 August 2005, Paris, FranceIETF DNSEXT TSIG Algorithms Current TSIG Proposed Standard [RFC 2845] defines only “HMAC-MD5.SIG- ALG.REG.INT”. –Weaknesses in MD5/SHA-1 do not apply to HMAC so it may be OK but: –Some people want to use government approved algorithms, i.e., at least SHA-1. –Various SHA-224+ algorithms are believed to be stronger than MD5/SHA-1. –Some people want to truncate their MACs. Open Source for all SHA algorithms –draft-eastlake-sha2-00.txt

4. Slide 4 August 2005, Paris, FranceIETF DNSEXT Changes Specified by Draft “HMAC SHA TSIG Algorithm Identifiers” –draft-ietf-dnsext-tsig-sha-02.txt formerly: draft-eastlake-tsig-sha-*.txt Standardizes added HMAC algorithm FQDN syntax “TLDs” for all SHAs as follows: –SHA1., SHA224., SHA256., SHA384., and SHA512. How to specify and use truncation via TSIG MAC size field. Recommends implementation of SHA1 with 96 bit truncated SHA1, makes implementation of HMAC-SHA-1 and HMAC-SHA-256 MANDATORY in addition to HMAC-MD5.

5. Slide 5 August 2005, Paris, FranceIETF DNSEXT ->04 TSIG SHA Draft Changes Based on WG Last Call comments on list and implementer feedback: –Specify error code for “signature too weak” to be the same as missing signature. –Specify that truncated signature value in request is used in calculating signature for reply. –State that policies SHOULD accept longer signatures than they require and SHOULD reply with a signature at least as long as that in the corresponding query. –Say a little more about recent hash function breaks. Read for publication?

6. Slide 6 August 2005, Paris, FranceIETF DNSEXT Other Algorithm Drafts draft-ietf-dnsext-ecc-key-07.txt formerly draft-schroeppel-dnsind-ecc-*.txt –Need feedback on draft, ideally from implementers. draft-ietf-dnsext-rfc2536bis-dsa-04.txt –Updates DSA key/signature RFC draft-ietf-dnsext-rfc2539bis-dhk-04.txt –Updates Diffie-Hellman key RFC

7. Slide 7 August 2005, Paris, FranceIETF 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. This draft now defines both a key format and a signature format using Algorithm #4 previously reserved for this purpose.

8. Slide 8 August 2005, Paris, FranceIETF 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, and some IETF Consensus, and few reserved or Standards Action required.

9. Slide 9 August 2005, Paris, FranceIETF DNSEXT RFC 2929 (cont.) Problem: “IETF Consensus” and even “Publication Requires” generally considered too hard to get Type codes, etc., so people overload TXT, etc. Solution?: Permit “Early Allocation” by invoking RFC 4020. No: RFC 4020 only applies to Standards Actions (not Experimental, etc.) and is still way too burdensome.

10. Slide 10 August 2005, Paris, FranceIETF DNSEXT RFC 2929bis Primary Effect: Replace RFC 2929 with a more liberal document draft-ietf-dnsext-2929bis-00.txt Major change: –Replace many “IETF Consensus” occurrence with “DNS Special Allocation Policy” Minor changes: –Also cover AFSDB Subtypes –Provides some Specification Required RCODE allocation –Update references, other very minor changes

11. Slide 11 August 2005, Paris, FranceIETF DNSEXT RFC 2929bis DNS Special Allocation Policy IANA allocation under ANY of the following: –Standards Action –Approval as Experimental –Temporary / Early Allocation based on RFC 4020 if request meets ALL of the following: Adequately documented in an Internet Draft Complete template Published to Namedroppers for at least two weeks in advance Approval by WG Chair and Area Director (or 2 Area Directors for individual draft)

12. Slide 12 August 2005, Paris, FranceIETF DNSEXT 2929bis DNS Special Allocation Policy (cont.) DNS Special Allocation Policy applies to parts of the RR TYPE, RR CLASS, and AFSDB Subtype spaces. Provision for some different template questions for each of the above but these are not yet fully specified.

13. Slide 13 August 2005, Paris, FranceIETF DNSEXT DNS Special Allocation Policy Possible Template Questions for an RR TYPE Special Early Allocation: –Why won’t an existing RR type do? –Does the proposed RR require special handling within DNS different than an Unknown RR Type?

14. Slide 14 August 2005, Paris, FranceIETF DNSEXT DNS Special Allocation Policy (Cont.) Possible Template Questions for a CLASS Special Early Allocation: –Why can’t this use an existing CLASS such as being a subtree under the IN CLASS? –Does the proposed CLASS require special handling within DNS?

15. Slide 15 August 2005, Paris, FranceIETF DNSEXT DNS Special Allocation Policy (Cont.) Possible: Template Questions for an AFSDB Subtype Special Early Allocation: –Why is an AFSDB subtype more appropriate than a new RR TYPE? –Why won’t this result in excessively large retrieval results with mixed subtypes for AFSDB queries?