2929bis etc.

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

description

2929bis etc. Donald E. Eastlake 3 rd +1-508-786-7554 [email protected]. 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 - PowerPoint PPT Presentation

Transcript of 2929bis etc.

November 2005, Vancouver, BC IETF DNSEXT Slide 1

2929bis etc.

Donald E. Eastlake 3rd

+1-508-786-7554

[email protected]

November 2005, Vancouver, BC IETF DNSEXT Slide 2

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

November 2005, Vancouver, BC IETF DNSEXT Slide 3

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

November 2005, Vancouver, BC IETF DNSEXT Slide 4

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.

November 2005, Vancouver, BC IETF DNSEXT Slide 5

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.

November 2005, Vancouver, BC IETF DNSEXT Slide 6

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.

November 2005, Vancouver, BC IETF DNSEXT Slide 7

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

November 2005, Vancouver, BC IETF DNSEXT Slide 8

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”)

November 2005, Vancouver, BC IETF DNSEXT Slide 9

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?