Re: [TLS] Comments on TLS identity protection

[[e-mail]]

Hi Eric,

Thank you for your review, please find comments in-line.

Note: my comments concern the draft-hajjeh-tls-identity-protection-00,
since the second document proposes the same feature but by using, among
others, a TLS extension.

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

In EAP-TLS, an implementation of TLS for Wireless LAN and later for WiMAX,
the client is authenticated based on the certificate's use. This is the
initial motivation of this work.


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


OK. in this case, CertificateVerify should be symmetrically encrypted too.


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


Could you clarify that please? I didn't get the point regarding the server
cert which is sent in cleartext.


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

Right, I will modify the text with regard to your remark.



> 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?


The following text will be added:

If a stream cipher is chosen, then the peer's certificate is encrypted
with the derived key, without any padding byte.

If a block cipher is selected, then padding bytes are added to force the
length of the certificate message to be an integral multiple of the bloc
cipher's length.


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

Right. The following sequence replaces the sequence used by the actual
version of the document. It is true that the server must read the
ClientKeyExchange before the Certificate. Is that a big change to the TLS
machine-state?
                                              ....
                              <--------       ServerHelloDone
        {Certificate}
         ClientKeyExchange
         CertificateVerify
        [ChangeCipherSpec]
         Finished             -------->       ....



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

OK.
TLS notes that P_hash can be iterated as many times as is necessary to
produce the required quantity of data.

Then, both the client and the server derive the identity_protection_key as
follow:

       client_write_MAC_secret[SecurityParameters.hash_size]
       server_write_MAC_secret[SecurityParameters.hash_size]
       client_write_key[SecurityParameters.key_material_length]
       server_write_key[SecurityParameters.key_material_length]
       client_write_IV[SecurityParameters.IV_size]
       server_write_IV[SecurityParameters.IV_size]
       identity_protection_key[SecurityParameters.key_material_length]


> Comments on: draft-urien-badra-eap-tls-identity-protection-01
>
> 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.


Agree.

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

Idem for S 3.

Best regards,
Badra

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