[TLS] Final (hopefully) issues with DTLS 1.2

[Eric Rescorla <[e-mail]>]

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