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

[Ravi Ganesan <[e-mail]>]

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