Re: [TLS] TLS Digest, Vol 65, Issue 76

[Marsh Ray <[e-mail]>]

Ravi Ganesan wrote:
> 
> I know everyone on this thread knows otherwise, but the way the terms
> get used, can easily result in confusion between "full handshake",
> "abbreviated handshake" and "renegotiated full handshake".

It took me a long time to stop getting mixed up between "renegotiation"
and "resumption". There was some discussion about this, but it turns out
they are completely orthogonal.

> The attack
> only applies of course to last category, and NOT to the abbreviated
> handshake.

No, it applies equally to session resumption "abbreviated" handshakes.

They can also be conducted during a renegotiation. OpenSSL even defines
an option SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION. I'm sure
there's a story behind that one.

> [...]
> 
> Sorry if this is so obvious to those on this thread, but a lot about SSL
> is *not* obvious to the world at general, and unfortunately a number of
> people are convinced that the attack discovered a flaw in session
> resumption or opening parallel sessions using the abbreviated handshake.
> If it did, I missed it perhaps.  If not, perhaps language in text
> clarifying this 'obvious' point might be useful.

draft-ietf-tls-renegotiation-02 contains the text:

> The above rules apply even when TLS session resumption is used.

and

>    TLS clients which support this specification MUST generate either the
>    "renegotiation_info" extension or the TLS_RENEGO_PROTECTION_REQUEST
>    SCSV with every ClientHello, including ClientHellos where session
>    resumption is being offered.

The RI extension should fix renegotiation regardless of whether a new
session is being established or a previous session is being resumed.

- Marsh