Re: [TLS] TLS 1.2

On Mon, Aug 29, 2005 at 09:47:10PM +1200, Peter Gutmann wrote:

> [...]            Most of the use in TLS is as PRFs and in HMAC, none of which
> are even remotely endangered by any known attack.  Signatures, however, need
> to be fixed for three main reasons:
[...]
> 3. Signing of hashes that don't correspond to anything that's calculated
>    during part of the normal handshake.  That is, the dual-MAC that's sent in
>    the Finished message isn't what gets signed, so it's necessary to run a
>    parallel hash of handshake messages that terminates before the Finished-
>    message hashing does.  Since client certs are almost never used, there's a
>    lot of extra overhead involved in running an extra dual hash that (most of
>    the time) never gets used.

Whether this is overhead depends on the hashing API used by the TLS
implementation -- if you can copy the current hash state if a client
CertificateVerify is to be sent, then you won't have to do the hashing
work twice.

>                                In practice all that's needed is to sign the
>    client and server nonces to ensure signature freshness,
> 
> So my proposal was to include a new extension signatureSuites, consisting of
> (currently) three values:
> 
>   SIG_RSA_PKCS1_WITH_SHA1
>   SIG_RSA_PKCS1_WITH_SHA256
>   SIG_DSA_WITH_SHA1
> 
> and if that gets acknowledged by the other side (as per RFC 3546) then using a
> standard signature of the given type over the value:
> 
>   { "certificate verify" || client_nonce || server_nonce }

This will provide the server with assurance that the client holding
the appropriate signing key is currently engaging in a TLS handshake,
and that *either* said client *or* a man in the middle is the other
party to the key exchange that the server is directly involved in.  In
other words, it does not say anything on whether the ClientKeyExchange
comes from the legitimate client or the man in the middle and thus
whether the symmetric key material has actually been negotiated with
the client whose certificate was sent, or with Mr Wile E Coyote
c/o General Delivery, Grand Canyon AZ 86023.

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls