Subject: [dane] draft-ietf-dane-srv-02

From: "Olle E. Johansson" <[email-masked]>
Date: Sat, 6 Jul 2013 15:43:52 +0200

Hi!

While working on the SIP-dane draft, I'm trying to follow draft-ietf-dane-srv and add the missing parts for SIP.

I note that in section 6 the draft requires support for TLS SNI (RFC 6066). 

Why is this a requirement? I don't see the need to require SNI here. Supporting SNI makes life much easier
for everyone, but as I haven't seen many SIP implementations using it (mostly because the support 
hasn't been in the installed versions of OpenSSL/GnuTLS and ...hummm... TLS is not widely used).

Adding a requirement on this (a must level) is in my view a bit too harsh.

One could rephrase it a bit, to say "if a server is addressed using multiple names TLS SNI must
be supported".

Cheers,
/O

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 6 Jul 2013 07:56:28 -0700

> One could rephrase it a bit, to say "if a server is addressed using multiple names TLS SNI must

Support for SNI on the relying party side is needed because a relying party can't know ahead of time whether or not a server will have multiple names. Further, without this requirement, a server that has an operational reason to use multiple names would be constrained not to because of the lack of support for SNI in the systems it wants to communicate with.

--Paul Hoffman

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 6 Jul 2013 19:57:50 +0000

On Jul 6, 2013, at 6:43 AM, Olle E. Johansson <[email-masked]> wrote:

> Why is this a requirement? I don't see the need to require SNI
> here. Supporting SNI makes life much easier for everyone, but as I
> haven't seen many SIP implementations using it (mostly because the
> support hasn't been in the installed versions of OpenSSL/GnuTLS and
> ...hummm... TLS is not widely used).

Clients MUST support SNI.  Servers need not.  Take a look at the
latest revision of Wes Hardaker's and mine SMTP draft:

    $ git clone https://github.com/vdukhovni/ietf
    $ cd ietf; make

Then read the resulting:

    draft-dukhovni-dane-ops-01.html
    draft-dukhovni-smtp-opportunistic-tls-01.html

with your favour browser, or just read the source XML if you prefer.

This is gradually becoming a reasonably coherent description of
how to use DANE TLSA with an actual applicaton protocol.  It will
I hope prove a useful jumping off point for other protocol
specifications.  Please read it, all constructive comments (including
patches correcting any glaring mistakes) welcome.

-- 
	Viktor.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Sun, 7 Jul 2013 10:46:11 +0200

> patches correcting any glaring mistakes) welcome.

I will read. Notice a statement that sni on server side was required in
order to provide backwards compatibility. Since SIP use subjaltnames
and we just can add another for the SRV host, I don't think we need to
require SNI for SIP.

/O

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 16 Jul 2013 14:42:22 -0600

On 7/6/13 7:43 AM, Olle E. Johansson wrote:
> Hi!
> 
> While working on the SIP-dane draft, I'm trying to follow
> draft-ietf-dane-srv and add the missing parts for SIP.
> 
> One could rephrase it a bit, to say "if a server is addressed using
> multiple names TLS SNI must be supported".

I previously commented on this list that some technologies have an SNI
equivalent, so requiring SNI and only SNI seems overly restrictive.
The technology I'm familiar with here is XMPP, wherein the 'to'
address of the XML stream header is treated as an indication of the
domain at which the client wants to connect.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/