The IESG recommends that 'Credential Protection Ciphersuites for Transport Layer Security (TLS)' <draft-hajjeh-tls-identity-protection-06.txt> NOT be published as an an Experimental RFC. 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-06.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) (which the authors say doesn't apply to this draft -- there has been no statement from the patent owner). 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 document has been in Independent Submission Review phase since then; at least Pasi Eronen and Eric Rescorla (as then TLS co-chairs) provided input (largely negative) to the RFC Editorial Board; the document has been updated couple of times since. 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 believes that note #5 from RFC 3932 applies: The IESG thinks that this document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval. Rationale: The document introduces several changes to the core cryptographic parts of TLS: for example, the contents of Certificate and CertificateVerify handshake messages are changed, and keys that are currently used in TLS (the premaster secret) are re-used for another purpose. TLS does have extension mechanisms that have been used in the past to negotiate a different format for the Certificate handshake message (RFC 5081), and replace the Certificate handshake message with a different message (RFC 4366). Since these extension mechanisms can have "subtle (and not-so-subtle) interactions that may occur in this protocol between new features and existing features that may result in a significant reduction in overall security" (to quote text from RFC 4366), the IANA allocation rules require IETF Consensus (and in certain cases, Standards Action) for defining such extensions. Earlier versions of the draft (when still named draft-urien-badra- eap-tls-identity-protection) did actually use these extension mechanisms. By the time the draft was submitted to the RFC Editor, it had been changed to re-use already allocated numbers with different contents to get around the IANA rules, and instead uses bits from the "Cipher Suite" field to negotiate this extension. The IANA rules for Cipher Suite numbers allow Specification Required, since it's relatively simple to define how, for example, a new encryption algorithm can be used in TLS (without having to worry about subtle interactions with existing feature). However, Cipher Suites don't change the overall syntax of Certificate or CertificateVerify messages, or specify new uses for the premaster secret key. The IESG feels that using this loophole to change core parts of TLS is not appropriate, and not in line with the TLS architecture. _______________________________________________ IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
