Re: [TLS] implementation of cookies in DTLS

[Eric Rescorla <[e-mail]>]

On Tue, Mar 15, 2011 at 2:59 AM, Nikos Mavrogiannopoulos
<[e-mail]> wrote:
> On Tue, Mar 15, 2011 at 12:37 AM, Eric Rescorla <[e-mail]> wrote:
>> I suspect either reflecting or the special case would work. I'm trying
>> to get all the other
>> changes in before the deadline so I'll leave it with =0 and the
>> special case and an
>> open issue marker and let's just resolve in Prague.
>
> I will not be there but I'd like to make these points:
> 1. Define precisely the behavior of initial pre-handshake before state
> is allocated. My opinion is that I don't like special cases such as
> use 0 always
> and do not case about re-use because they are more likely to introduce
> bugs and new attacks. Copying the client's numbers should solve the
> issue with no special cases and no state. Also I suppose that if
> handshake_seq=0 is used for HelloVerifyRequest then handshake_seq=1
> should be used for ServerHello and this should be clear as well to
> avoid having another special case.

Noted.  Let's see how that discussion shakes out in the meeting.


> 2. Drop requirement: 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.
> This will create incompatibilities when more than 1 DTLS protocols are
> implemented
> in a single client or server. It is not really possible for a server
> to do an emulation of
> the decisions it would do as if a state existed. What are the reasons for this
> requirement?

I don't understand why this is an issue: the server can remember what the
client offered (indeed, he must remember a whole pile of other stuff in order
to verify that it hasn't changed) by stuffing a digest into the cookie.

-Ekr