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