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

From: Eric Rescorla <[email-masked]>
Date: Mon, 23 May 2011 06:19:04 -0700

Following up on Prague, here is the new text for the 2MSL and the
record sequence number issues:

MSL:
4.1.
   Note that because DTLS records may be reordered, a record from epoch
   1 may be received after epoch 2 has begun. In general,
   implementations SHOULD discard packets from earlier epochs, but if
   packet loss causes noticeable problems MAY choose to retain keying
   material from previous epochs for up to the default MSL specified for
   TCP [TCP] to allow for packet reordering. (Note: the intention here
   is that implementors use the current guidance from the IETF for MSL,
   not that they attempt to interrogate the MSL the system TCP stack is
   using.)  Until the handshake has completed, implementations MUST
   accept packets from the old epoch.

   ...

4.2.4.
   In addition, for at least twice the default MSL defined for [TCP],
   when in the FINISHED state, the node which transmits the last flight
   (the server in an ordinary handshake or the client in a resumed
   handshake) MUST respond to a retransmit of the peer's last flight
   with a retransmit of the last flight. This avoids deadlock conditions

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
   sequence number duplication in case of multiple HelloVerifyRequests,
   the server MUST use the record sequence number in the ClientHello as
   the record sequence number in the HelloVerifyRequest.

...

   When the second ClientHello is received, the server can verify that
   the Cookie is valid and that the client can receive packets at the
   given IP address.  In order to avoid sequence number duplication in
   case of multiple cookie exchanges, the server SHOULD use the record
   sequence number in the ClientHello as the record sequence number in
   its initial ServerHello. Subsequent ServerHellos will only be sent
   after the server has created state and MUST increment normally.

I believe this matches what I said in Prague, but any objections to
this in concept or the way I've written it up.

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?

-Ekr

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 23 May 2011 16:35:34 +0200

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.

> 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

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 30 May 2011 08:38:41 -0700

On Mon, May 23, 2011 at 7:35 AM, Nikos Mavrogiannopoulos
<[email-masked]> wrote:
> What is the rationale of this restriction?

 Given my points in
> 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.)"

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

> (e.g. in my implementation changecipherspec is not parsed by the

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