Re: [TLS] Final (hopefully) issues with DTLS 1.2

[Nikos Mavrogiannopoulos <[e-mail]>]

On 05/23/2011 03:19 PM, Eric Rescorla wrote:

Hello,

> Record Sequence Number: When responding to a HelloVerifyRequest the
> client MUST use the same parameter values (version, random,
> session_id, cipher_suites, compression_method) as it did in the
> original ClientHello.  The server SHOULD use those values to generate
> its cookie and verify that they are correct upon cookie receipt.  The
> server MUST use the same version number in the HelloVerifyRequest
> that it would use when sending a ServerHello. Upon receipt of the
> ServerHello, the client MUST verify that the server version values
> match. In order to avoid

What is the rationale of this restriction? Given my points in
http://permalink.gmane.org/gmane.ietf.tls/8336
I believe interoperability will be harmed in the future as ciphersuites
are being deprecated or restricted to certain protocols.

> Finally, I've been rethinking the issue of the interaction of the 
> ChangeCipherSpec and the handshake sequence numbers. In Prague I 
> suggested not changing this and just putting a note in the spec that 
> one had to be careful, but at this point I am thinking it might be 
> better to simple suck up the change and put a message sequence
> number in the CCS. This removes the need to consult the handshake
> state machine in order to deal with reordering, though not in order
> to determine whether the CCS is at the appropriate place in the
> handshake (in order to detect misbehaving or malicious behavior
> early).  The downside for this is that it's a difference from TLS,
> but it seems like fairly easy code--though I admit I haven't tried to
> code it up. I don't think either way represents a security issue, but
> doing it this way means that we won't need to be as careful in the
> future about having the state machine be completely deterministic
> prior to the CCS, which seems like the Right Thing. Comments?

Which use-case are you trying to solve? Could an implementation solve
it using another way (what being careful would mean?).

A change like that to changecipherspec is not that trivial as it
actually convert it from a signaling message to a handshake message
(e.g. in my implementation changecipherspec is not parsed by the
handshake layer).

regards,
Nikos