Last Modified: 2003-02-26
The original DNSSEC specification explicitly specified flags on the KEY resource records for use by IPSEC. Experience has shown that this has operational problems. The DNSEXT working group is restricting the use of the KEY record to DNS uses only. Thus, IPSEC keying via DNS needs a new resource record.
The scope of work is to identify what information is needed in an IPSEC-specific keying resource record. The content of the resource record are not limited to only the information that is in the DNS KEY record but may also contain useful IPSEC information information, such as that which is required for Opportunistic Encryption. Other possible uses are out of scope for this working group, since any reuse will require a careful analysis of the trust model and possible security interactions with IPsec.
The WG will define the semantics of the record only in terms of how the data in the record can be used for initializing an IPSEC session. Questions of when it is appropriate to do so are regarded as policy issues that are out of scope for this WG.
This effort is specific to providing IPSEC information in DNS. All other distribution channels are out of scope.
MAR 03 | Solicit various proposals on what information is needed in IPSEC specific KEYing record | |
APR 03 | Publish first Internet-Draft of consensus DNS Resource Record | |
MAY 03 | Complete WG Last Call on consensus DNS RR proposal document and pass document to IESG for consideration as a Proposed Standard |
IPSECKEY IETF56, San Francisco 18 March 2003 Minutes reported by Charlie Kaufman Meeting convened at 5:01pm Michael Richardson presented draft-richardson-ipsec-rr-02.txt Suggestion was made and accepted to swap the order of the precedence and algorithm fields and make the presentation format match the wire format. Olafur Gudmundsson suggested that the working group accept the draft as a working group document, make a nits pass, and go to working group last call. The proposal was accepted by the room without dissent. Meeting adjourned at 5:08 pm. Steve Bellovin explained likely timeframes for advancement to RFC. Meeting adjourned again at 5:12 pm with goal of revising the document before the scheduled end time of 6 pm. |