The IESG has no problem with the publication of 'Credential Protection Ciphersuites for Transport Layer Security (TLS)' <draft-hajjeh-tls-identity-protection-09.txt> as an Experimental 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=15465&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 Pasi Eronen. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hajjeh-tls-identity-protection-09.txt The process for such documents is described at http://www.rfc-editor.org/indsubs.html. Thank you, The IESG Secretary Technical Summary When a TLS connection is authenticated using certificates, the certificates are normally sent before encryption is actived, and thus an eavesdropper can see them, leading to privacy concerns especially when client certificates are used. To address these concerns, TLS also supports a longer handshake where the server is authenticated first, and the client's certificate is then sent encrypted. This draft specifies a new handshake variation for the same purpose (client's certificate is sent encrypted). Compared to the existing mechanism, this new variation uses two roundtrips less, and may need slightly fewer cryptographic operations. Working Group Summary This document is not the result of any IETF Working Group. It is an independent submission to the RFC Editor. Some background: This draft is a continuation of older draft with different name (draft-urien-badra-eap-tls-identity-protection). Around the same general topic area, the authors also have couple of academic papers ("Hiding User Credentials during the TLS authentication phase" in NTMS 2007, and "Adding Identity Protection to EAP-TLS Smartcards" in IEEE WCNC 2007), and a patent application (WO/2007/115982) (see IPR disclosures 1036 and 1045). The Internet-Drafts were briefly discussed in late 2006 in EMU and TLS WGs, but there was basically zero interest, since there was no evidence suggesting that the current mechanism -- which is already standardized, implemented, and deployed -- needed optimization in real-world scenarios. Thus, it was felt that introducing another mechanism for the same purpose would be just unnecessary complexity with possible impacts on interoperability. In June 2007, the authors asked Dan Romascanu if he'd sponsor the document as an AD sponsored individual submission; Dan forwarded the authors to Tim Polk, as this clearly belonged in the security area. Tim turned down the request due to concerns about interoperability, and suggested just documenting the experiment using numbers from the "Private Use" range. The authors submitted the document to the RFC Editor as independent submission in December 2007 (not using the Private Use range, but requesting IANA allocated numbers) . The IESG performed its RFC 3932 check in September 2008 for version 06 of this draft; this resulted in "Do Not Publish" recommendation which is available here: http://www.ietf.org/mail-archive/web/ietf-announce/current/msg05192.html Subsequent discussions between the IESG and the RFC Editor (in November-December 2008) proposed a compromise where the draft would be published for historical record and/or experimentation without any IANA-assigned numbers, and with a note explaining that experimentation would require agreeing on numbers from the "Private Use" range (which are not intended for deployments or shipping in products). Version -09 has completely removed the "IANA Considerations" section, and was resubmitted for 3932bis check in November 2009. Other changes between versions -06 and -09 are minor, and not relevant for the 3932bis check. Protocol Quality The extension has not been reviewed by TLS WG or any other IETF WG. Even a superficial look during the RFC Editor Independent Submission Review phase discovered things like "two-time pad" (incorrect use of stream cipher that allowed recovering the XOR of two plaintexts). Note to RFC Editor The IESG has concluded that this work is related to IETF work done in TLS WG, but this relationship does not prevent publishing. However, the IESG requests including the following IESG note to clarify the relationship to IETF work, and the approach to experiments: The content of this RFC was at one time considered by the IETF, but was not adopted by the IETF. The RFC Editor has chosen to publish this document at its discretion for historical record and limited experimentation. If mutually consenting hosts want to perform experiments with these cipher suites, they need to agree on what values to use from the "Private Use" range (RFC 5246, Section 12). These values are not to be used for any kind of deployments (i.e., they are not to be shipped in any products). _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
