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

[Eric Rescorla <[e-mail]>]

On Mon, May 23, 2011 at 7:35 AM, Nikos Mavrogiannopoulos
<[e-mail]> wrote:
> 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.

I'm not sure I'm following this concern.

The effect of this restriction is to require the client to send the
same ClientHello
(except with the cookie that he sent initially). This maps to the TLS semantics
where there is only a single ClientHello message sent which is processed
immediately. IMO this makes analysis easier since it makes DTLS behave
more like TLS.

There's no need for the server to do any negotiation at this point,
it should simply generate a HelloVerifyRequest with the highest matching
version (regardless of cipher suite considerations) and then process the
ClientHello de novo [after checking for matching parameters.] Yes, this leaves
open the possibility that the handshake will eventually negotiate to some yet
lower TLS version, but that's what happens in one round trip with TLS. I
would be happy to add a note to the effect that a yet lower version might
be negotiated. Though note that it's arguable that RFC 5246 S 7.4.1.3
prohibits conditioning version on ciphersuite even for TLS "This field
will contain the lower of that suggested by the client
in the client hello and the highest supported by the server.  For this
version of the specification, the version is 3.3.  (See
Appendix E for details about backward compatibility.)"




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

It's less an implementation issue than a spec issue. Currently the
order of the handshake messages vis-a-vis the CCS is deterministic,
i.e., that you know in advance what set of handshake messages you
ought to have received before receiving the CCS. However, if future
specs were to break this invariant, then you would be left in a position
where you had the CCS but weren't sure if you were expecting another
handshake message, so couldn't necessarily process the CCS.


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

Yes, I realize this isn't great. IMO it was a mistake for the CCS not to be
a handshake message, but we can't really fix that.... we're left with
trying to determine the lesser of two evils.

Best,
-Ekr