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

[Eric Rescorla <[e-mail]>]

On Fri, Jun 3, 2011 at 12:30 PM, Nikos Mavrogiannopoulos
<[e-mail]> wrote:
> 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.

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