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

[Nikos Mavrogiannopoulos <[e-mail]>]

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