Draft: draft-ietf-tls-dtls13

Commentary: writes We specify a ClientHello.legacyversion = { 254,253 } , but we seem to be inheriting the unmodified TLS 1.3 ServerHello , complete with ServerHello.legacyversion = 0x0303 . That seems problematic , since the legacy DTLS 1.2 ServerHello would use the expected { 254,253 } like the ClientHello . and later In DTLS 1.3 , the client indicates its version preferences in the " supportedversions " extension ( see Section 4.2.1 of [ TLS13 ] ) and the legacyversion field MUST be set to { 254 , 253 } , which was the version number for DTLS 1.2 . The version fields for DTLS 1.0 and DTLS 1.2 are 0xfeff and 0xfefd ( to match the wire versions ) but the version field for DTLS 1.3 is 0x0304 . It seems like reusing 0x0304 will make implementations more complex for little gain -- it 's common to want to , e.g. , compare ( D)TLS versions to see which are greater . OpenSSL does that with macros like : / DTLS version numbers are strange because they 're inverted . Except for DTLS1BADVER , which should be considered " lower " than the rest . / which would have to grow another case of indirection to handle this , whereas making TLS13VERSION and DTLS13VERSION have the same numerical value does n't seem to help the code at all . 
 I bet you have an opinion here . 
 I do n't feel very strongly . I wish we had used the same numbers from the beginning but , now that we 've used different ones , it may be easier to continue the trend . 
 Version information appears at two layers , namely at the record protocol and at the handshake protocol . Record Protocol We have two different types of header formats , namely one for plaintext and one for encrypted records . The latter has changed compared to DTLS 1.2 and does not carry version information anymore . We kept the plaintext version to ensure backwards compatibility with earlier versions of DTLS . We could put a new version number in there but we follow the spirit of TLS 1.3 and put the DTLS 1.2 version number in the legacyrecordversion field ( { 254 , 253 } ) . Handshake Protocol We wanted to keep alignment with TLS 1.3 and therefore the content of the supportedversions counts . Currently , we are using 0x0304 there for DTLS 1.3 . For the handshake protocol we again use the spirit of TLS 1.3 and put the DTLS 1.2 version into the legacyversion into the ClientHello ( which is { 254 , 253 } ) . For the ServerHello we use the TLS 1.3 ServerHello.legacy_version field ( which is 0x0303 ) for the case where the server decides to use DTLS 1.3 . One could argue that we should instead put { 254 , 253 } in there as well . The important aspect is that the version field in the record protocol and in the handshake protocol does not matter when two DTLS 1.3 peers talk to each other . They are irrelevant constants used in the code . For cTLS we are getting rid of them . For a dual - stack environment , however , it matters what is contained in the ClientHello and in the plaintext field of the record protocol ( because of backwards compability reasons ) . Maybe we could make it more explicit what goes where and what the design rational is but setting the values differently does not matter much at all . 
 FWIW I basically agree with Hannes ; my comment here was thinking about implementation complexity rather than " protocol correctness " . ( I guess technically using 0x0303 for ServerHello.legacy_version would arguably make the openssl implementation simpler than using 0xfefd , amusingly enough . ) I 'm not tied to any specific changes in this space , but wanted to consider if there were things we could do that would streamline implementation . 
 The posted PR is consistent with existing DTLS practice . I.e. , it uses the transformed version numbers throughout 
 Gee , I wish that I had seen this . This is not a good outcome from my perspective , or from the perspective of NSS . A better outcome would have been to keep the legacy cruft ( ClientHello.legacyversion ) and have clean version numbers in supportedversions . Still , it 's too late now I guess . 
 This works for me , thanks .
Paragraph (version A):
versions) but the version field for DTLS 1.3 is 0x0304.
Paragraph (version B):
versions).  The value 0xfefc is used to indicate DTLS 1.3.
Paragraph (version B):
The DTLS 1.3 ServerHello message is the same as the TLS 1.3
ServerHello message, except that the legacy_version field is set to
0xfefd, indicating DTLS 1.2.