Subject: [dane] dane-srv questions for the WG

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 10 Jun 2014 19:24:30 -0600

Matt Miller and I submitted a new version of draft-ietf-dane-srv today. 
We have a few questions for the WG...

1. In Section 4.1, we discuss how to proceed if there are no TLSA 
records, only SRV records. This section assumes that the presented 
certificate is a "traditional" PKIX cert. Therefore we do not take into 
account raw public keys as specified in draft-ietf-tls-oob-pubkey. Do 
folks here think we need to address, or at least mention, the raw keys case?

2. Also in Section 4.1, we say:

###

    SRV is secure:  The reference identifiers SHALL include both the
       service domain and the SRV target server host name (e.g., include
       both "im.example.com" and "xmpp23.hosting.example.net").  The
       target server host name is the preferred name for TLS SNI or its
       equivalent.

    In the latter case, the client will accept either identity to ensure
    compatibility with servers that support this specification as well as
    servers that do not support this specification.

###

Remember that the reference identifiers are what the client uses when 
determining if the certificate is acceptable (cf. RFC 6125). The 
reasoning here is that if the client allows only the target server host 
name as a reference identifier then it won't be able to connect to older 
servers that don't yet support dane-srv, whereas if it allows only the 
source domain as a reference identifier then it won't be able to connect 
to newer servers that support only dane-srv. For the sake of 
interoperability, supporting both seems like the best approach. Does 
that justify the SHALL here? And is this the best place in the document 
for this information?

Thanks!

Peter

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 11 Jun 2014 04:11:40 +0000

> Matt Miller and I submitted a new version of draft-ietf-dane-srv today.

Thanks.  A few comments:

Section 2:

The reference to "secure", "insecure", "bogus", "indeterminate"
was changed to refer to RFC 4033, from 4035, but in fact it is 4035
that gives the intended definition of "indeterminate" (failure
to determine, a lookup error).  See the SMTP draft, section 2.1.1

Section 3.1:

    If a particular response is "bogus" or "indeterminate" according
    to DNSSEC validation, the client MUST ignore that target server
    host name.

This glosses over two distinct cases:

    * The SRV RRset is "bogus", "indeterminate" (or some other
      lookup error, feel free to borrow/steal section 2.1.1 from
      the SMTP draft).  In this case NONE of the SRV server names,
      if any were actually obtained, can be used.

    * The SRV RRset is secure, but downstream lookups for A or TLSA
      records fail...

The quoted comment more properly applies to the second case, but
you've not yet reached that point in the discussion.  The immediately
preceding text is about the initial SRV lookup, and if that fails,
ALL the SRV records are bad, and the service is unreachable.
So it seems that the original text was more appropriate:

Section 4.1:

This section is confusing because it is not clear that the opening
paragraph established preconditions for the rest of the section.
The first paragraph should say something like:

    "In this section we consider the case that, ...  The case with
    TLSA usable/secure records is considered in the next section, ..."

> 1. In Section 4.1, we discuss how to proceed if there are no TLSA records,
> only SRV records. This section assumes that the presented certificate is a
> "traditional" PKIX cert. Therefore we do not take into account raw public
> keys as specified in draft-ietf-tls-oob-pubkey. Do folks here think we need
> to address, or at least mention, the raw keys case?

Without TLSA records any out of band authentication of "RPK" material
is not via DANE, it is not clear whether anything generally useful
can be said about this.  However, even without RPK, opportunistic
TLS clients may simply skip authenticating the server entirely (as
with SMTP), and so a general requirement to authenticate is too
strong.

Rather I think you should specify which reference identifiers to
use *IF* the client is using PKIX, without mandating the use of
PKIX.

> determining if the certificate is acceptable (cf. RFC 6125). The reasoning
> here is that if the client allows only the target server host name as a
> reference identifier then it won't be able to connect to older servers that
> don't yet support dane-srv, whereas if it allows only the source domain as a
> reference identifier then it won't be able to connect to newer servers that
> support only dane-srv. For the sake of interoperability, supporting both
> seems like the best approach. Does that justify the SHALL here? And is this
> the best place in the document for this information?

I think the requirement is justified, provided the client is doing
PKIX.  I have no concrete opinion about document organization.

The document still feels a bit "raw" overall, if you have cycles to
re-read it with care, and polish it further, it would likely help.

-- 
	Viktor.

---

From: James Cloos <[email-masked]>
Date: Wed, 11 Jun 2014 01:24:07 -0400

>>>>> "PS" == Peter Saint-Andre <[email-masked]> writes:

PS> For the sake of interoperability, supporting both [target server
PS> hostname and source domains as a reference identifier] seems like
PS> the best approach. Does that justify the SHALL here?

Specifying that clients SHALL consider both the source domain and the
target server hostname when the SRV RR is secure looks like an accept-
able compromise between the optimal case and the pre-dane legacy.

-JimC
--
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: Kim Alvefur <[email-masked]>
Date: Wed, 11 Jun 2014 17:21:22 +0200

> Matt Miller and I submitted a new version of draft-ietf-dane-srv today.

Why does the text it Section 3 say to do queries in parallel when
section 3.2 says that one has to do A/AAAA lookups and validation (which
depend on SRV) before deciding to do TLSA lookups?

And what does the security status of A/AAAA records matter if you have a
secure reference to the certificate you see?  Unless of course if you
get bogus, then aborting the connection to that target is sane.

>       target server host name is the preferred name for TLS SNI or its

In XMPP, sending to='xmpp123.hosting.example.net' instead of
to='example.com' does not seem sensible to me.  The server should know
which cert to present for each domain, or probably just shows the same
for all if it is a multi-tenant hosting service.

And I don't think one should look too hard at the name in a certificate
if you have a matching TLSA record.

--
Kim "Zash" Alvefur

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 11 Jun 2014 15:45:53 +0000

> depend on SRV) before deciding to do TLSA lookups?

It says "where possible".  As I see it the only sensible opportunity
for parallel lookup is to find the A or AAAA records of the subset
of the SRV hosts with the highest (untried) priority, then among
those that actually have an IP address, one can choose a randomized
server based on the weight, at which point I would only retrieve
TLSA records for that host.

Generally, all the SRV hosts are up and it is sufficient to try
one connection, so there is no benefit in performing multiple TLSA
lookups for clients that make long-lived infrequent connections.

In summary I think that while some clients may decide to parallelize
some DNS lookups, this is an implementation decision that is perhaps
out of scope for the DANE SRV specification.

> get bogus, then aborting the connection to that target is sane.

See Section 2.2.2 of the SMTP draft, which provides the rationale:

    http://vdukhovni.github.io/ietf/draft-ietf-dane-smtp-with-dane-10.html#rfc.section.2.2.2

> for all if it is a multi-tenant hosting service.

This suggestion breaks cross-domain hosting:

	_service.example.org. 	IN SRV 0 0 12345 server.example.net.

The server.example.net hosting provider can obtain certs for its
own name, managing certs from each hosted domain is a significant
burden.

> if you have a matching TLSA record.

You're not thinking about TA certificate usages PKIX-TA(0) and
DANE-TA(2) which absolutely require name checks.  Even PKIX-EE(1)
requires name checks as part of the PKIX validation.

-- 
	Viktor.

---

From: Kim Alvefur <[email-masked]>
Date: Wed, 11 Jun 2014 21:37:36 +0200

> out of scope for the DANE SRV specification.

That's what I was aiming for.

>     http://vdukhovni.github.io/ietf/draft-ietf-dane-smtp-with-dane-10.html#rfc.section.2.2.2

Perhaps a reference to that then?

> own name, managing certs from each hosted domain is a significant

Then how is server.example.net supposed to know that you want to talk to
example.org?  "its equivalent" is said to be the stream addressing
earlier which makes this weird.

> requires name checks as part of the PKIX validation.

Right, of course.

--
Kim "Zash" Alvefur

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 11 Jun 2014 19:44:16 +0000

> earlier which makes this weird.

In-band signalling.  "Host:" headers with HTTP, "RCPT TO:" with
SMTP, user login with IMAP, ...  Demultiplexing at the application
layer is rather common.

-- 
	Viktor.