Draft: draft-ietf-tls-dtls13

Commentary: This is an inconsistency between the TLS 1.3 text ( which says " MUST " abort the handshake with an " unexpected_message " alert ) and the text in this draft , which indicates a SHOULD . 
 I do n't understand what this is trying to say . I think that it says that the client , having received a bad cookie will send its second ClientHello off into the void , only to have the handshake time out . Then , the client is expected to restart . This is probably right . The bad cookie indicates that something is badly wrong . Anything the server might send that would fix this would n't be authenticated and so might be exploited by an attack as a denial of service on the connection . However , I 'm not sure if any client actually implements this restart . 
 Probably not , but I think this is just editorial . If you had some client - server type app then you might expect a retry ( like Web clients do ) . Anyway , we should n't change the spec . 
 The text in DTLS 1.2 was a bit different , namely " If a server receives a ClientHello with an invalid cookie , it SHOULD treat it the same as a ClientHello with no cookie . This avoids race / deadlock conditions if the client somehow gets a bad cookie ( e.g. , because the server changes its cookie signing key ) . " I believe the DTLS 1.2 text was actually quite good . I suggest to re - use the DTLS 1.2 text again . The problem with the current text is that the  will have to find out about the failed request via a timeout . While not common , it is not ideal either . If the current text does , however , prevent certain problems I am happy to leave it as is . I noticed that we incorrectly reference text from Section 4.1.4 . of the TLS 1.3 RFC . In any case , I prepared a PR just in case : I also created a second PR to deal with the inconsistency with the TLS 1.3 spec , which I believe has to be addressed : 
 I do n't believe that the bad cookie is a situation that needs to be handled in a different way than is described . Any server doing this uses a key identifier in its cookie . So , like ekr , I do n't think that the design needs to be changed . I would prefer to say that the ClientHello with a bad cookie is simply discarded ( as Internet background noise , if you will ) . If the intent of the text ( prior to as proposed ) is to say that it 's now the client 's problem to fix , I agree with that . The question was about what the text meant , so an editorial fix would be fine . I would go so far as to say :
Paragraph (version A):
If a server receives a ClientHello with an invalid cookie, it MUST
NOT respond with a HelloRetryRequest.  Restarting the handshake from
scratch, without a cookie, allows the client to recover from a
situation where it obtained a cookie that cannot be verified by the
server.  As described in Section 4.1.4 of TLS13, clients SHOULD also
abort the handshake with an "unexpected_message" alert in response to
any second HelloRetryRequest which was sent in the same connection
(i.e., where the ClientHello was itself in response to a
HelloRetryRequest).
Paragraph (version B):
If a server receives a ClientHello with an invalid cookie, it MUST
NOT respond with a HelloRetryRequest.  Restarting the handshake from
scratch, without a cookie, allows the client to recover from a
situation where it obtained a cookie that cannot be verified by the
server.
Paragraph (version B):
As described in Section 4.1.4 of TLS13, clients MUST abort the
handshake with an "unexpected_message" alert in response to any
second HelloRetryRequest which was sent in the same connection (i.e.,
where the ClientHello was itself in response to a HelloRetryRequest).