Opportunistic Encryption using the Internet Key Exchange (IKE)
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: RFC Editor <firstname.lastname@example.org> Cc: The IESG <email@example.com>, <firstname.lastname@example.org>, email@example.com Subject: Re: Informational RFC to be: draft-richardson-ipsec-opportunistic-18.txt The IESG has no problem with the publication of 'Opportunistic Encryption using The Internet Key Exchange (IKE)' <draft-richardson-ipsec-opportunistic-18.txt> as an Informational RFC. The IESG would also like the IRSG or RFC-Editor to review the comments in the datatracker (https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=7384&rfc_flag=0) related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the comment log. The IESG contact person is Steve Bellovin. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-richardson-ipsec-opportunistic-18.txt The process for such documents is described at http://www.rfc-editor.org/indsubs.html. Thank you, The IESG Secretary
Technical Summary This document describes how the Linux FreeS/WAN project used DNS TXT and KEY records to perform opportunistic IPsec encryption. "Opportunistic encryption" permits secrecy without prearrangement between the parties concerned. Working Group Summary Future opportunistic encryption systems will use the IPSECKEY DNS record instead, in compliance with RFC 3445. This document describes the historic usage. RFC Editor Note: Section 1, second paragraph: Old text: Note that 2.01 and beyond implements RFC3445 [RFC3445], in a backward compatible way. A future document will detail compliance to RFC3445. For project information, see http:// www.freeswan.org. New text: Note that 2.01 and beyond implements [RFC3445] in a backward compatible way. A future document [IPSECKEY] will describe a variation that complies with RFC3445. For project information, see http://www.freeswan.org. Section 2.2: Old text: Multiple networks are necessary to adequately explain examples. New text: Because multiple networks are necessary to adequately explain the examples, [RFC3330] addresses are not used. Add the following non-normative references: [IPSECKEY] Richardson, M., "A Method for Storing IPsec Keying Material in DNS", July 2004. [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002. Protocol Quality Steve Bellovin has reviewed this document for the IESG.