Subject: [dane] AD review of draft-ietf-dane-srv-12

From: Stephen Farrell <[email-masked]>
Date: Thu, 02 Apr 2015 01:16:06 +0100

Hiya,

I have just one question I'd like to ask before starting IETF LC.

Appendix B: I'm not sure there's really going to be IETF
consensus that it's better to have a TLS server cert for the
hostname and not the service name. If you can point at where
it's recorded that the WG reached that consensus that may save
us time later. But we'll see I guess - I think there's a
reasonable case for both sides of that argument.  While this
comment is about an appendix I suspect that if the wg change
it's mind here, it'd also change other bits of the draft.

Note that as soon as I get a reasonable answer I'll move on
here - though I think having an easily accessible recent answer
may be quite useful.

Thanks,
Stephen.

PS: some more nits below, feel free to treat these as IETF
LC comments.

nits:

- intro: 2nd bullet: I think including an explicit definition
of "target domain" in section 2 would be good even if it's
defined elsewhere too.

- intro: last bullet: I don't get that sorry.

- section 7: The first sentence doesn't fill one with
confidence. It reads as if speculation. Maybe s/often would
like/ought/ would help.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 2 Apr 2015 01:21:33 +0000

On Thu, Apr 02, 2015 at 01:16:06AM +0100, Stephen Farrell wrote:

> hostname and not the service name.

The rationale in appendix B of SRV leaves what I think is the most
important reason for preferring the server hostname:

    * That's what clients MUST send in the SNI extension!

DNSSEC/DANE authenticate the "redirect" from the service domain to
the target host (which may well in a hosting provider domain) and
the TLSA record promising TLS support and providing the authentication
material is associated with *that* name and not the service domain.

	; hosted domain zone
	_imap._tcp.example.com IN SRV 0 0 143 mail.example.net.

	; hosting provider zone
	_143._tcp.mail.example.net. IN TLSA 2 0 1 <digest>

The party promising TLS support is the provider, not the hosted
domain.  And that's whose certificate the TLSA record is expected
to match.

Support for the service domain in the certificate is a concession
to interoperability with legacy or mixed deployments, where some
clients are still doing non-DANE PKIX.  Though per Alexey's most
recent UTA draft, they should some day primarily be looking for
srvNAME altnames, rather than domain names in the certificate.

> If you can point at where
> us time later.

It is fundamental to the DANE TLSA model, that the certificate is
associated with the TLSA base domain.  There really is no other
way to do it, without breaking the indirection, and forcing hosted
clients to publish TLSA RRs for the provider's servers, which
totally stinks because the coordination is unworkable.

> While this

No change of mind is likely here, I for one, would oppose this
rather strongly.

-- 
	Viktor.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 02 Apr 2015 12:53:05 +0100

Hi Viktor,

Meta-question: was this something the wg discussed or did
they just follow your lead? If the former, that's grand and
I'll stop when shown the archive URL for the thread (I do
think I recall similar discussion, but not sure). If not,
then let's use this thread to check - so if someone disagrees
with Viktor and hasn't sent mail on this previously (if it
was discussed already please don't re-raise stuff) it'd be
good to hear about it now.

The reason I'm asking is the obvious one - this could be
a surprise - if the user agent for some protocol shows
foo.example.com (or has that in a configuration) but via
DNSSEC/DANE/SRV we end up with a TLS session with
bar.example.com and if we say that that is ok, then we're
causing potential developer/deployer/user surprise, and also
setting an upper bound for the level of TLS security that is
only as good as domain-validated. That is a defensible
position (esp for the DANE wg!) but might surprise some
application developers etc.

One other question: you mentioned SNI below. Is that very
relevant here, given we're not talking about the web (that
won't use SRV) and afaik most use of SNI is for the web.
So, for which non-web applications is SNI sufficiently
important to justify this (potential) level of developer
surprise?

Thanks,
S.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 2 Apr 2015 16:49:34 +0000

On Thu, Apr 02, 2015 at 12:53:05PM +0100, Stephen Farrell wrote:

> they just follow your lead?

When I joined the WG in ~Mar 15, text along these lines was already
in the Tony Finch drafts srv and smtp drafts.  So I was not a party
to any WG discussion of that decision, but it is obviously the
*only* way to deal with DNSSEC redirection (be it SRV or MX).

What I was a party to was subsequent discussion of CNAME indirection
that is captured in the "ops" draft (WGLC soon, right!).  I believe
we got consensus for that.  And again, if the TLSA base domain is
the expanded CNAME, then that's the primary reference identifier
(used in SNI, ...) but for mixed/legacy environments the original
name is to be also be supported.

> DNSSEC/DANE/SRV

You can add CNAME to the list. :-)

> we end up with a TLS session with
> only as good as domain-validated.

DANE is stronger than DV, but makes no pretense to be EV.

> That is a defensible

I don't think there'll be many surprises, the application will
often be the one passing the reference identifiers to the TLS
library.

At least in OpenSSL (where I'm involved in designing the DANE
support) the TLS library is not going to be doing the TLSA lookups.
Rather the application will call use some DNSSEC library to obtain
the service specification records (see DANE vocabulary) and find
the associated TLSA RRs.  It will then hand these (TLSA base domain,
RRs, and additional names to accept) off the the TLS library as
verification input parameters.

> won't use SRV) and afaik most use of SNI is for the web.

SNI is a TLS mechanism.  It is not a web mechanism.  Any time a
server handles multiple domains, SNI is potentially useful.  We've
worked hard (in the ops draft) to make it less necessary to use
SNI, precisely by specifying that the primary reference identifier
must be the expanded name (except when CNAME expansion is not
secure).

> important to justify this (potential) level of developer

No surprise, on the contrary, as an SMTP developer (e.g.) I *expect*
that the reference identifer is the MX hostname, we've been waiting
for DNSSEC to make this possible for many years now.  Lots of
domains have shared backup MX hosts, which can't possibly have
certificates for all the domains, but can field a certificate
for their own name.

Better yet, with DANE-EE(3) the name and expiration of the certificate
are entirely irrelevant, making multi-tenancy even easier.

[ 
    With DANE-EE(3) Postfix will happily accept certificates in
    which the Subject DN and Issuer DN are empty RDN sequences,
    there are no subject alternative names (it's just a fancy key
    container), and the expiration time precedes the inception
    time, but I've been asked to not speak of such PKIX-violating
    apostasy, and I've been good about that. :-)  I'll just make
    a retroactive exception for April 1 below.
]

-- 
	Viktor.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 12795556661879960995 (0xb192f2fd7ebcf5a3)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: 
        Validity
            Not Before: Apr  2 16:46:41 2015 GMT
            Not After : Apr  1 16:46:41 2015 GMT
        Subject: 
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:c6:7c:a9:d1:67:e8:16:9e:c8:94:04:a8:8c:ca:
                    4f:d1:5c:d0:cf:1f:a8:6d:46:84:29:72:5d:26:fc:
                    e3:0d:14:08:2a:cc:27:8b:ad:ef:68:80:68:8a:b2:
                    be:10:df:c1:1e:26:b4:3d:94:1b:d2:2b:d8:41:05:
                    46:93:26:d5:f4:10:a5:48:e4:d3:ae:e1:78:34:43:
                    2b:13:33:3f:1a:7c:72:7f:e6:a9:24:e6:5e:c0:e6:
                    42:ad:d5:4e:e4:95:6c:91:b8:83:66:7e:76:6f:64:
                    e6:bd:c9:f1:ff:34:89:08:bc:7b:10:bf:63:a2:8c:
                    62:0a:0a:14:69:71:e1:24:de:e1:ce:22:2f:fe:14:
                    dd:cf:0d:99:b7:9e:8a:62:2d:5c:29:06:d6:7e:95:
                    ef:d0:8c:0f:e7:23:e8:34:2d:af:37:d6:05:bc:83:
                    72:00:d5:18:64:38:44:f4:61:39:9c:8b:2d:b9:b7:
                    04:57:16:cb:79:5a:8e:61:94:fa:2e:82:9e:0d:23:
                    bc:23:d8:42:01:ee:3c:53:6f:c7:13:0c:46:03:7c:
                    93:97:9d:50:af:af:8a:e9:e5:42:b4:46:fa:89:9c:
                    e9:b8:24:b9:6a:44:e9:31:50:87:1d:9f:b8:07:9a:
                    98:a8:0d:ca:ca:41:d3:d2:f1:d0:a5:d6:7f:76:b8:
                    54:7f
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                B5:76:28:80:32:B8:9D:82:75:94:AE:20:9E:DF:A0:B7:BA:53:D9:55
            X509v3 Authority Key Identifier: 
                keyid:B5:76:28:80:32:B8:9D:82:75:94:AE:20:9E:DF:A0:B7:BA:53:D9:55

            X509v3 Basic Constraints: 
                CA:TRUE
    Signature Algorithm: sha1WithRSAEncryption
         c0:1d:17:0d:74:c0:bd:38:a1:dc:ed:b1:86:0d:81:ad:74:58:
         20:c3:31:9f:80:94:4d:47:28:10:14:bf:04:30:4b:bf:dc:91:
         af:d7:73:05:f4:3f:af:0f:fe:87:12:88:17:07:68:2a:51:31:
         f6:b9:c6:10:3b:84:87:bd:f6:b1:dc:8d:02:e9:87:c8:cf:54:
         b4:8d:bf:17:8c:e1:e1:95:4a:a8:b0:1e:75:36:e8:b5:c0:e9:
         7e:52:c9:7b:62:69:55:0a:b0:0e:d6:e9:b5:a1:ea:c5:22:e1:
         bc:c4:73:ec:7d:cd:26:ab:12:7a:1f:4f:7d:1d:52:25:6f:69:
         f4:ea:79:91:10:68:73:a5:67:15:87:a4:e9:85:e4:1a:bd:12:
         17:70:cc:83:d7:23:d8:19:79:94:38:c9:44:92:61:16:3f:e5:
         07:a7:8c:6d:4e:b7:8b:d1:7f:d4:14:de:02:94:7e:2f:6f:66:
         2a:04:eb:dd:2a:58:c2:bd:c7:10:e9:e7:2d:f7:18:78:4a:54:
         f5:8a:75:6f:56:71:3b:be:28:07:f6:31:78:91:1c:40:0b:f8:
         64:2c:ca:99:e7:da:70:25:15:be:af:77:1d:d7:2b:67:f8:01:
         7c:ab:08:e8:4c:60:7c:92:d1:d1:80:14:57:bc:14:a8:10:a1:
         a3:70:44:0f
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

---

From: ⌘ Matt Miller <[email-masked]>
Date: Thu, 2 Apr 2015 14:54:37 -0600

At least for XMPP, using the target server host name was discussed in
several forums over the course of many (> 5) years; I'm having trouble
finding specific threads because the discussion started so long ago.
The best I can do without a lot of archeology is point you at Section
1 of [POSH] and Section 6 of [XMPP-DNA] for the rationale.  Both
sections resulted from much discussion on mailing lists, in physical
meetings, and XMPP community gatherings.  I believe Olle Johansson can
point you to nearly identical discussions around SIP.

TLDR -- multi-tenant hosting providers (outside of HTTPS providers)
can't get a "good" cert for the service name, but can for their target
server host name.  Instead of forcing users to understand an "accept
anyway" box that their brains are being wired to ignore anyway, we try
to prove the delegation and let the hosting provider use a cert they
can actually get.

- -- 
- - m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

[POSH] "PKIX Obtained over Secure HTTP"
< https://tools.ietf.org/html/draft-ietf-xmpp-posh >

[XMPP-DNA] "Domain Name Associations (DNA) in the Extensible Messaging
and Presence Protocol (XMPP)"
< https://tools.ietf.org/html/draft-ietf-xmpp-dna >

On 4/2/15 10:49 AM, Viktor Dukhovni wrote:
>> Meta-question: was this something the wg discussed or did they
>> just follow your lead?
> 
> When I joined the WG in ~Mar 15, text along these lines was
> already in the Tony Finch drafts srv and smtp drafts.  So I was not
> a party to any WG discussion of that decision, but it is obviously
> the *only* way to deal with DNSSEC redirection (be it SRV or MX).
> 
> What I was a party to was subsequent discussion of CNAME
> indirection that is captured in the "ops" draft (WGLC soon,
> right!).  I believe we got consensus for that.  And again, if the
> TLSA base domain is the expanded CNAME, then that's the primary
> reference identifier (used in SNI, ...) but for mixed/legacy
> environments the original name is to be also be supported.
> 
>> The reason I'm asking is the obvious one - this could be a
>> surprise - if the user agent for some protocol shows 
>> we end up with a TLS session with bar.example.com and if we say
>> that that is ok, then we're causing potential
>> developer/deployer/user surprise, and also setting an upper bound
>> for the level of TLS security that is only as good as
>> domain-validated.
> 
>> That is a defensible position (esp for the DANE wg!) but might
>> surprise some application developers etc.
> 
> support) the TLS library is not going to be doing the TLSA
> lookups. Rather the application will call use some DNSSEC library
> to obtain the service specification records (see DANE vocabulary)
> and find the associated TLSA RRs.  It will then hand these (TLSA
> base domain, RRs, and additional names to accept) off the the TLS
> library as verification input parameters.
> 
>> relevant here, given we're not talking about the web (that won't
>> use SRV) and afaik most use of SNI is for the web.
> 
>> So, for which non-web applications is SNI sufficiently important
>> to justify this (potential) level of developer surprise?
> 
> No surprise, on the contrary, as an SMTP developer (e.g.) I
> *expect* that the reference identifer is the MX hostname, we've
> been waiting for DNSSEC to make this possible for many years now.
> Lots of domains have shared backup MX hosts, which can't possibly
> have certificates for all the domains, but can field a certificate 
> for their own name.
> 
> Better yet, with DANE-EE(3) the name and expiration of the
> certificate are entirely irrelevant, making multi-tenancy even
> easier.
> 
> [ With DANE-EE(3) Postfix will happily accept certificates in which
> the Subject DN and Issuer DN are empty RDN sequences, there are no
> subject alternative names (it's just a fancy key container), and
> the expiration time precedes the inception time, but I've been
> asked to not speak of such PKIX-violating apostasy, and I've been
> good about that. :-)  I'll just make a retroactive exception for
> April 1 below. ]
>

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Thu, 02 Apr 2015 15:06:51 -0600

On 4/2/15 2:54 PM, ⌘ Matt Miller wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>

I did a bit of archeology. In the XMPP community these assumptions go 
back to at least 2009:

http://www.ietf.org/archive/id/draft-hildebrand-dna-00.txt

See for instance Section 6.2 there.

I have not been able to trace it farther than that.

Peter

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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 03 Apr 2015 12:20:45 +0100

Thanks Peter and Matt. Those (and Viktor's arugments) are
good enough for me. I'll kick off the IETF LC later today.

Cheers,
S.