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

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 03 Jun 2011 21:30:08 +0200

On 05/30/2011 05:38 PM, Eric Rescorla wrote:

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

My implementation of this HelloVerifyRequest was made without using or
allocating server state. That means it doesn't even know which (DTLS)
protocols are enabled or not. It could even be implemented in a
totally different subsystem (a firewall) in front of the server. Thus it
might not know information the server knows. For me this packet
should be as simple as possible. Using a fixed DTLS version would
satisfy this goal. I see no benefit from doing the DTLS version number
negotiation at this "stateless" point.

regards,
Nikos

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 3 Jun 2011 13:09:38 -0700

> negotiation at this "stateless" point.

I don't see a problem with the server echoing the client's version number
here. Does anyone disagree with making an explicit exemption in the spec
for that?

-Ekr

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 03 Jun 2011 23:16:54 +0200

> here. Does anyone disagree with making an explicit exemption in the spec

By reflecting the version back you lose the ability to use a different
format later on (under another version number). It might be better to
just fix it to a protocol number, e.g. DTLS 1.0, and if the format
changes then some other number is used.

regards,
Nikos

---

From: Sean Turner <[email-masked]>
Date: Thu, 09 Jun 2011 09:29:01 -0400

Does anybody else have thoughts about this?  I'd really like to be able 
to put this draft to bed.

spt

On 5/23/11 9:19 AM, Eric Rescorla wrote:
> 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
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Joe Salowey <[email-masked]>
Date: Tue, 14 Jun 2011 09:41:08 -0700

The open issue is with respect to the version number that Nikos raised.  Eric is working on text along the lines of Nikos' recommendation of fixing the version number.

Joe 
On Jun 9, 2011, at 6:29 AM, Sean Turner wrote:

> Does anybody else have thoughts about this?  I'd really like to be able to put this draft to bed.
> 
> spt
>