[TLS] Comments on TLS identity protection

[Eric Rescorla <[e-mail]>]

I've reviewed both draft-hajjeh-tls-identity-protection-00
and draft-urien-badra-eap-tls-identity-protection-01. Extensive
reviews below but the executive summary is that i think these
proposals are poorly motivated and do not believe they should
be adopted by the TLS WG.

-Ekr


Comments on: draft-hajjeh-tls-identity-protection-00

BACKGROUND
The TLS handshake occurs in the clear. Thus, any observer can
determine the credentials used by the client or server to authenticate
themselves. This document describes an "identity protection" mode for
TLS designed to hide the client's certificate.


GENERAL COMMENTS
I don't understand what the motivation for this mode is. I appreciate
that it was an advertised feature of IPsec, but TLS doesn't 
need to replicate every feature of IPsec. In particular, since
certificate-based client authentication is actually fairly
rare, it's not clear that *privacy* of that client authentication
is really a big consideration.

The good news is that TLS has a very simple mechanism for achieving
this: do an ordinary TLS handshake without client authentication
and then do an immediate re-handshake with client auth. As the 
authors observe, this is slower (two sets of crypto computations
and 4 RTTs) than a specialized identity protection mode. However,
it is available now and as far as I can tell is rarely done.
I don't find the argument that there is a large demand for this
feature if it were only 50% faster particularly persuasive.
Rather, this seems like a premature optimization.

As a secondary consideration, this mechanism provides imperfect
privacy guarantees. Although the Certificate is hidden, the
CertificateVerify is not. As a consequence, if an attacker
ever obtains a client's certificate it can do trial verification
to determine whether a new handshake uses that certificate.

In order for the identity protection to be protected against
MITM attack, the server cert needs to be verified prior to
sending the Certificate message. Because the question of whether
this is the correct certificate is outside of TLS, in many TLS
stacks the handshake completes prior to checking the server
hostname. That won't work here.


DETAILED COMMENTS
S 1.

   Client identity protection may also be done through a EDH exchange 
   before establishing an ordinary handshake with identity information 
   [RESCORLA]. This wouldn't however be secure enough against active 
   attackers and wouldn't be favorable for some environments (e.g. 
   mobile), due to the additional cryptographic computations. 

It's important to be clear about "secure enough". The active
attack here discloses the client's certificate. It does not
result in compromise of the connection.


S 2.
   If the server selects one of the ciphersuites defined in this 
   document, the client MUST encrypt its certificate using the 
   symmetric algorithm selected by the server from the list in 
   ClientHello.cipher_suites and a key derived from the 
   SecurityParameters.master_secret (see section 3 for the key 
   computation). 

This is underspecified. How is the encryption process
performed?


S 3.
This changes the TLS state machine. In TLS the ClientKeyExchange
precedes the Certificate message.


   The identity_protection_key is set to the low order bits of the 
   key_block, and its length is set appropriately to 
   ServerHello.cipher_suite.

"low-order bits"? And what about the next extension which wants
the "low-order bits". You need to specify complete slicing and
dicing instructions.


Comments on: draft-urien-badra-eap-tls-identity-protection-01

NOTE:
This document is somehow related to draft-hajjeh-tls-identity-protection-00.
See the review for that document.

GENERAL COMMENTS
I don't understand what the relationship of this document is to
draft-hajjeh-tls-identity-protection-00, which seems to
be similar. See my comments on that document for why I don't
think this work is adequately motivated.

I note that this mechanism has the same partial information
leakage problem as described in that document.

I note that this document talks about EAP-TLS but it clearly
is a modification to TLS.


DETAILED COMMENTS
S 5.
The "Implicit" mode creates a situation in which two implementations
both of which would be willing to do client auth without encryption
of the Certificate can't communicate because the client insists
on encrypting. That's not really an acceptable situation.


S 6.
Notified mode implies a change to TLS behavior (And the Certificate
reading state machine) from some mechanism that's not detectable
or negotiable inside TLS. That doesn't seem acceptable either.

_______________________________________________
TLS mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tls