The client hello record format in DTLS RFC at https://www.rfc-editor.org/rfc/rfc4347#section-4 does not mention this. However, since SNI is mentioned in TLS extensions RFC at https://www.rfc-editor.org/rfc/rfc6066 and DTLS RFC seems to be silent on how to handle TLS extensions, I am not sure what is the official word on this. Any inputs appreciated
2
-
SNI is for HTTPS. But HTTPS (v1.1 at least) only runs on top of TCP. And not UDP, right? So I don't see how you'd use it. (Except with HTTP/2, SPDY, etc. on top of UDP maybe.)– StackzOfZtuffCommented Mar 16, 2015 at 8:47
-
SNI is not only for HTTPS. Though it is use as such. From ietf.org/rfc/rfc3546.txt ..."[TLS] does not provide a mechanism for a client to tell a server the name of the server it is contacting. It may be desirable for clients to provide this information to facilitate secure connections to servers that host multiple 'virtual' servers at a single underlying network address." Any application protocol on top of DTLS/UDP can still use SNI if it chooses as far as I understand.– doonCommented Mar 16, 2015 at 10:52
Add a comment
|
1 Answer
Applies, but was forgotten in spec.
Judging from the IETF mailing list it was forgotten inside the RFC document.
Relevant mail is the second in the thread:
Good point.
DTLS is intended to support extensions--and OpenSSL, at least, supports them in the same way as it does for TLS.
There probably should be a definition of ExtendedClientHello in 4346 and 6347, but it's exactly the PDU you would expect. I.e., the extensions come after the CompressionMethod.
-Ekr
Full thread
There is a nicely rendered thread on GMANE. And the individual posts are as follows:
[TLS] DTLS lacking TLS extensions ?, Martin Rex (Archived here.)
Re: [TLS] DTLS lacking TLS extensions ?, Eric Rescorla (Archived here.)
Re: [TLS] DTLS lacking TLS extensions ?, Martin Rex (Archived here.)
Re: [TLS] DTLS lacking TLS extensions ?, Marsh Ray (Archived here.)
answered Mar 16, 2015 at 11:33
