Re: Fwd: Re: [dane] DANE-SRV, SNI functional equivalent and XMPP

On 5/18/15 3:26 PM, Dave Cridland wrote:
>
> On 18 May 2015 23:09, "Peter Saint-Andre - &yet" <[email protected]
> <mailto:[email protected]>> wrote:
>  >
>  > This thread started on the DANE WG list but I think it belongs here.
>  >
>  >
>  > -------- Forwarded Message --------
>  > Subject: Re: [dane] DANE-SRV, SNI functional equivalent and XMPP
>  > Date: Mon, 18 May 2015 15:03:54 -0700
>  > From: Peter Saint-Andre - &yet <[email protected]
> <mailto:[email protected]>>
>  > To: [email protected] <mailto:[email protected]>
>  >
>  > On 5/17/15 9:55 AM, Kim Alvefur wrote:
>  >>
>  >> Hello list!
>  >
>  >
>  > Hi Zash!
>  >
>  >> Georg Lukas noted that section 4.1 says, in the context of XMPP, to use
>  >> to='xmpp23.hosting.example.net <http://xmpp23.hosting.example.net>'
> in the stream header, as that is the
>  >> "functional equivalent" of SNI in XMPP.  However, that conflicts with
>  >> the current semantics of 'to' being the service domain name to the
>  >> server host name.  That will break many, if not all, deployed servers.
>  >> The server should know what certificate to use for the indicated domain
>  >> name.
>  >>
>  >> http://tools.ietf.org/html/draft-ietf-dane-srv-14#section-4.1
>  >
>  >
>  > Hmm.
>  >
>  > First, all draft-ietf-dane-srv says is that you don't need to use SNI in
>  > XMPP because we already have a way for the TLS client to specify which
>  > domain name it expects of the TLS server, i.e., the 'to' address of the
>  > initial stream header.
>  >
>
> Actually, it's a interesting problem. As I understand it, SNI is
> unencrypted in the handshake, so offers no value, but could easily cause
> major confusion if used, since it is not clear which might take precedence.

Good point.

> However, my understanding - possibly flawed - is that TLS version 1.3
> introduces encrypted handshakes, and then it might be useful to hide the
> server domains used.

I admit that I haven't been tracking the TLS 1.3 initiative, although I 
recall that being one of the goals. However, since TLS 1.3 isn't here 
yet, it doesn't help us with draft-ietf-xmpp-dna (although we might want 
to mention that this applies to TLS 1.2 and lower).

Peter

-- 
Peter Saint-Andre
https://andyet.com/