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

The IESG <iesg-secretary@ietf.org> Mon, 21 December 2009 20:46 UTC

Return-Path: <wwwrun@core3.amsl.com>
X-Original-To: ietf-announce@ietf.org
Delivered-To: ietf-announce@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 30) id 11D483A67EA; Mon, 21 Dec 2009 12:46:52 -0800 (PST)
X-idtracker: yes
From: The IESG <iesg-secretary@ietf.org>
To: RFC Editor <rfc-editor@rfc-editor.org>
Subject: Re: Experimental RFC to be: draft-hajjeh-tls-identity-protection-09.txt
Message-Id: <20091221204653.11D483A67EA@core3.amsl.com>
Date: Mon, 21 Dec 2009 12:46:53 -0800 (PST)
Cc: iana@iana.org, The IESG <iesg@ietf.org>, ietf-announce@ietf.org
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-announce>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Dec 2009 20:46:53 -0000

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).