Re: Experimental RFC to be: draft-hajjeh-tls-identity-protection-06.txt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF]     [IETF Discussion]     [Linux Kernel]

  Powered by Linux