Subject: Re: [TLS] TLS Digest, Vol 65, Issue 86

From: Ravi Ganesan <[email-masked]>
Date: Sat, 19 Dec 2009 17:24:18 -0800

> You've confused renegotiation with resumption.  The peers DO renegotiate,
> but they perform a full handshake if either side doesn't want to resume
> a previous session.

That would be ironic since I was trying to iron out the confusion between
them. But it is entirely possible as a definition of renegotiation did not
jump out at me from the RFC. If its there (and I carefully searched through
RFC 5246 again just now) and I missed it my apologies in advance.  If by
renegotiation one means "brand new keying material"  then the abbreviated
handshake does not achieve it, as there is no new master_secret. If your
definition is new encryption/hashing keys based on the old master_secret and
the new (sent in clear and available to opponent) client_random and
server_random, then sure you can say the peers do renegotiate. I would not
call this renegotiate as for me the primary reason I'd want to renegotiate
for privacy concerns is to use fresh keys. i.e. I'll assume that for
whatever reason the security of my master_secret over time deteriorates and
would be nice to start over afresh. (the only other  reason for
renegotiation I have seen so far, the serverauth-renego-clientauth sequence
use case does not apply as they need to do a full handshake anyway to
achieve that).

But like I said, its pretty clear that everyone else is comfortable with
allowing the abbreviated handshake to play out after one side requests a
renegotiation - so, so be it!!! I do hope my other point on the distinction
below makes it into the draft. Thx. Ravi

> But regardless even if there is something in existence called a
> "renegotiated abbreviated handshake", I think the distinction between
> 'abbreviated handshakes without renegoitation' which are very very widely
> used should not be confused with 'renegotiated handshakes of any kind'.
>
> It would be very helpful if the draft made this point.

As long as it does so in a way that doesn't add further confusion, yes.

---

From: Michael D'Errico <[email-masked]>
Date: Sat, 19 Dec 2009 18:49:30 -0800

Ravi Ganesan wrote:
> ....  If by renegotiation one means "brand new keying 
> material"  then the abbreviated handshake does not achieve it, as there 
> is no new master_secret.

A renegotiation is a _handshake_ that occurs after the initial handshake.

First, you perform an initial handshake to establish a secure channel.
Then if you ever perform a handshake over this previously-established
secure channel, you are renegotiating.

The initial handshake may be full or abbreviated, and the renegotiation
may be full or abbreviated.  TLS does not require the renegotiation
handshake to be related in any way to the initial handshake (except now
we are adding the Renegotiation_Info extension to prevent man-in-the-
middle attacks).

A full handshake creates a new master secret and an abbreviated handshake
reuses one.  All handshakes generate new keying material based on the
master secret.

Mike