Re: [TLS] Closing some open comments on draft-ietf-tls-renegotiation

[Eric Rescorla <[e-mail]>]

At Wed, 9 Dec 2009 00:36:55 +0100 (MET),
Martin Rex wrote:
> 
> Eric Rescorla wrote:
> > 
> > 6. Explicitly state that this extension may also be used with
> >    SSLv3 (we don't have any authority to update SSLv3 in any
> >    way but we can certainly say that there is no technical
> >    obstacle.)
> 
> What we're doing is giving recommendations to implementors what
> to do in their implementations when protocol version { 0x03, 0x00 }
> is negotiated.  We do not need any formal authority to do so.
>
> I would suggest to mention the sizes of the SSLv3 finished
> messages (36 octets), since these are considerably larger than
> in TLS (12 octets).

I have no problem with any of this. I was just saying that this
seems to be different from the situation with TLS where we 
can say you MUST do X, Y, and Z, and one could say that
implementations were nonconformant if they did not.


> > 7. Clarify that RI MUST be generated in all rehandshakes, per the
> >    issue Martin raised earlier and proposed resolution by Marsh
> >    and Nelson.
> 
> 
> Please add that this applies to _all_ handshakes, including
> TLS session resumes, i.e. the Server must return the
> TLS extension RI in the ServerHello of a TLS session resume as well!

Some text to this effect appears earlier, but I'm happy to
add it here as well.


> I feel a little uneasy with the term "rehandhshake". 
> I assume you refer to "renegotiation", i.e. a handshake that
> is performed when the "current connection state" differs
> from "no encrytion, no compression, no MAC".
> 
> I realize that the word "rehandshake" was added in one place to
> rfc5246 -- but I still would prefer a single term only.

Good point. I'm fine with using renegotiation throughout.

-Ekr