Subject: Re: [dane] Draft ietf-dane-srv-07

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 19 Aug 2014 10:33:16 -0600

Hej Olle, thanks for the feedback and sorry about the slow response
time. Comments inline.

On 7/24/14, 2:19 AM, Olle E. Johansson wrote:
> Hi!
>
> Sorry for not having followed the details of the discussion lately,
> so please excuse me if I'm too late with comments or ask about stuff
> discussed in a gazillion emails before.
>
>
> Section 3:
>
> I really like this here, but would like it to be expanded a bit to
> help implementors. The DNS SRV RFC is not easy to understand and in
> the IP world RFC 3263 has confused a lot of people. DNS SRV says that
> all candidates for a given priority should be attempted before one
> moves to the next priority. It doesn't say anything about order,
> which this document does when you say "SHOULD be performed in
> parallell". If one given priority have two hosts with two IPv4 and
> three IPv6 each - should all of them be tried in parallell?
>
> This is a big issue and may be too big an issue for this document to
> cover, especially with normative language.

I agree that normative language might not be appropriate. However, the 
authors of this spec do think that performing the DNS queries (not, as 
noted, the final application connection attempts) in parallel can help 
to expedite things significantly. Here is some alternate wording:

OLD

    To expedite connection to the intended service, where possible the
    queries described in the following sections SHOULD be performed in
    parallel (this is similar to the "happy eyeballs" approach for IPv4
    and IPv6 connections described in [RFC6555]).

NEW

    Developers of application clients that depend on DANE-SRV often
    would like to prepare as quickly as possible for making a connection
    to the intended service, thus reducing the wait time for end users.
    To make this possible, a DNS library might perform the queries
    described in the following sections in parallel, rather than waiting
    for one set of queries to be completed (say, all SRV queries) before
    performing additional queries (say, address queries and TLSA
    queries).

> Section 3.2
>
> Please change "A/AAAA" to "A and AAAA" to be very clear that it's not
> a choice if the client is dual stack.

Ack.

> In fact the DNS SRV rfc talks
> about "any address family" - now and in the future ;-)

We can always replace this spec when IPv12 is deployed. :-)

> Section 5:
>
> It would help me if you add a bullet like
>
> * Handling in the case of protocols using NAPTR for transport
> selection, like the Session Initiation Protocol

How is this?

    o  Use of SRV records with additional discovery technologies, such as
       the use of both SRV records and NAPTR records [RFC2915] for
       transport selection in the Session Initiation Protocol (SIP).

> That will help me in sipcore :-)

We're here for you!

> Section 6:
>
> I think it would help implementors to explain a bit more detail -
> that if you have multiple names in the cert, one could be the CN and
> the others Subject Alt Names.
>
> According to the SIP domain cert RFC the CN should be disregarded and
> NOT used if there are any SANs. I don't know the reasoning behind
> this. Anyone? Should we do that here too or just forget it?

I'd prefer to leave identity verification rules up to RFC 6125 or the 
application-specific equivalent. There's a reason why RFC 6125 ended up 
at 57 pages...

Peter

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 19 Aug 2014 16:41:10 +0000

On Tue, Aug 19, 2014 at 10:33:16AM -0600, Peter Saint-Andre wrote:

> application-specific equivalent. There's a reason why RFC 6125 ended up at
> 57 pages...

DANE with SRV (as also DANE with MX) is sufficiently different that
the 6125 rules can and should be revised.

    * The TLSA base domain is the preferred reference identifier

    * While treatment of wildcards, ... is application-specific per
      6125, the choice of reference identifier with DANE needs to
      recognize the fact that historically SRV lookups were not
      DNSSEC protected, and so applications (that cared about
      security, rather than merely went through the motions) needed
      to verify the input domain not the SRV host.

    * Therefore, for backwards-compatibility with UCC certs, ...
      Tony correctly recognized the need to allow either the SRV
      hostname (which is now secure and is generally the TLSA base
      domain) or the legacy input domain.  The OPS draft also
      recomments the CNAME expanded version of the input domain.

You can probably reference the OPS draft for some of this, and clone
the rest from the SMTP draft.

-- 
	Viktor.

---

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

On 7/24/14, 6:58 AM, Viktor Dukhovni wrote:
> On Thu, Jul 24, 2014 at 10:19:08AM +0200, Olle E. Johansson wrote:
>
>> Section 3:
>>
>> I really like this here, but would like it to be expanded a bit to help
>> implementors. The DNS SRV RFC is not easy to understand and in the IP
>> world RFC 3263 has confused a lot of people. DNS SRV says that all
>> candidates for a given priority should be attempted before one moves to
>> the next priority. It doesn't say anything about order, which this document
>> does when you say "SHOULD be performed in parallel".
>
> Note, the text at the top of Section 3:
>
> is encouraging parallel *DNS lookup*, not parallel connection
> attempts.  And in fact parallel connection attempts would be wrong
> unless all the weights are equal, and, as a blanket policy, questionable
> even then.
>
>> If one given priority have two hosts with two IPv4 and three IPv6 each -
>> should all of them be tried in parallell?
>
> The answer is NO, because the document does not suggest connection
> concurrency, and because even that is I thing a mistake.  When the
> weights are unequal, the client is supposed to employ some sort of
> RNG to choose candidate servers with a probability based on the
> weights.  If the client is correctly employing weighted selection,
> parallel address lookup is generally inappropriate, in most cases
> the first (randomly) chosen server will in fact be available and
> lookups for other server addresses are I believe wasteful.
>
> Thus parallel lookups are only useful when the first server does
> not respond and further lookups are required to find more servers,
> and could arguably have been performed in parallel with the first
> lookup.  However, after incurring a connection timeout with the
> first server, additional DNS lookup latency for the second server
> is not a major increment in the latency.

Definitions of "major" vary. In the HTTP world, something like SRV is 
actively shunned because of the latency it introduces.

> Also one needs TLSA lookups which should only follow the address
> lookups because the TLSA lookup should not be made when the address
> records are not secure.

This is true. Thus text like this might be better:

    Developers of application clients that depend on DANE-SRV often would
    like to prepare as quickly as possible for making a connection to the
    intended service, thus reducing the wait time for end users.  To make
    this possible, a DNS library might perform the SRV queries and
    address queries in parallel (because it is wrong to make TLSA queries
    if the address records are not secure, performing them in parallel
    with the SRV queries and address queries is not appropriate).

>  (Also when CNAMEs are supported on the
> RHS of SRV records, the TLSA base domain is not known until the
> original address record is CNAME expanded).

Yes, that usage makes my head hurt. However, that usage does not comply 
with RFC 2782 (which says that the Target MUST NOT be an alias), which 
is why we don't talk about it in the dane-srv specification.

> Bottom line I think the "parallel" language should be withdrawn.
>
>> This is a big issue and may be too big an issue for this document to cover,
>> especially with normative language.
>
> This document definitely cannot specify anything about connection
> concurrency.  I would like to suggest strongly it also should *not*
> specify lookup concurrency.

Pointing implementors (in a non-normative way) to the possible benefits 
of lookup concurrency does not seem actively harmful to me.

>> According to the SIP domain cert RFC the CN should be disregarded
>> and NOT used if there are any SANs. I don't know the
>> reasoning behind this. Anyone? Should we do that here too or just forget it?
>
> This is IIRC either from 5280, 6125 or both.  DNS names in the
> subject CN are deprecated, SANs are preferred, and trump the CN
> when both (at least one SAN of type DNS and a CN in the subject
> DN) are present.

Right. As I said, I'd prefer to avoid this contentious topic in the 
dane-srv specification.

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 19 Aug 2014 10:49:23 -0600

> the 6125 rules can and should be revised.

I have ~15 active Internet-Drafts to finish off before I start work on 
6125bis. ;-)

> the rest from the SMTP draft.

Noted!

Peter

---

From: James Cloos <[email-masked]>
Date: Tue, 19 Aug 2014 13:59:03 -0400

>> lookups because the TLSA lookup should not be made when the address

The TLSA lookup does not need to wait until the status of the address
lookup is known.  The adress status affects whether one should care
about and use the tlsa, not whether one can check for it.

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

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 19 Aug 2014 20:11:03 +0200

On 19 Aug 2014, at 18:33, Peter Saint-Andre <[email-masked]> wrote:

> I agree that normative language might not be appropriate. However, the authors of this spec do think that performing the DNS queries (not, as noted, the final application connection attempts) in parallel can help to expedite things significantly. Here is some alternate wording:
> 
> OLD
> 
Much better

>> a choice if the client is dual stack.
Ack
> We can always replace this spec when IPv12 is deployed. :-)
Deal.
>      transport selection in the Session Initiation Protocol (SIP).
Great.

>> That will help me in sipcore :-)
Thank you!
> I'd prefer to leave identity verification rules up to RFC 6125 or the application-specific equivalent. There's a reason why RFC 6125 ended up at 57 pages...

Right.

/O

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 19 Aug 2014 18:34:05 +0000

> I have ~15 active Internet-Drafts to finish off before I start work on

Sorry, I was unclear, I did not mean 6125bis, I meant that the SRV
draft can specify a refinement of the 6125 rules (the SMTP draft
does this).

-- 
	Viktor.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 19 Aug 2014 13:01:46 -0600

> about and use the tlsa, not whether one can check for it.

I think that's a more precise way to put it. Thus I propose the 
following revised text:

    Developers of application clients that depend on DANE-SRV often would
    like to prepare as quickly as possible for making a connection to the
    intended service, thus reducing the wait time for end users.  To make
    this possible, a DNS library might perform the SRV queries, address
    queries, and TLSA queries in parallel (although the TLSA records are
    not usable if the address records are not secure, performing the TLSA
    queries in parallel is not harmful from a security perspective).

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 19 Aug 2014 13:04:15 -0600

> draft can specify a refinement of the 6125 rules (the SMTP draft

Thanks. I will look at the dane-smtp spec more carefully with this in mind.

Peter

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 19 Aug 2014 19:46:08 +0000

On Tue, Aug 19, 2014 at 01:01:46PM -0600, Peter Saint-Andre wrote:

> I think that's a more precise way to put it. Thus I propose the following
> revised text:
> 

Almost right, but note that the reason to "supress" TLSA RRs when
address RRs are insecure is that TLSA RR lookups have been observed
to generate spurious lookup errors in that case (which one might
misconstrue to be an attack).

If TLSA RRs are actually returned, they are most likely to be also
"insecure" when the A records are insecure.  In fact any other
outcome would require a DLV configuration for say either
_tcp.imap.example.com or _143._tcp.imap.example.com to re-establish
trust below the "insecure" imap.example.com.  Such configurations
seem most unlikely.  

Also avoid "not usable", since that has special meaning in 6698.
So the thing to say is something along the lines that when the
A/AAAA results are "insecure" errors in TLSA lookup can be ignored,
but otherwise, any errors in TLSA lookup should be considered
equivalent to an active attack and cause the peer to be skipped.

-- 
	Viktor.

---

From: James Cloos <[email-masked]>
Date: Tue, 19 Aug 2014 18:43:01 -0400

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

PS> I think that's a more precise way to put it. Thus I propose the
PS> following revised text:

PS>    Developers of application clients that depend on DANE-SRV often would
PS>    like to prepare as quickly as possible for making a connection to the
PS>    intended service, thus reducing the wait time for end users.  To make
PS>    this possible, a DNS library might perform the SRV queries, address
PS>    queries, and TLSA queries in parallel (although the TLSA records are
PS>    not usable if the address records are not secure, performing the TLSA
PS>    queries in parallel is not harmful from a security perspective).

Looks good to me!

-JimC

---

From: Lawrence Conroy <[email-masked]>
Date: Wed, 20 Aug 2014 01:52:02 +0100

Hi there  Olle, folks
OK, whilst we're adding references, please don't put in a reference to an obsoleted RFC.
2915 was obsoleted by that fine collection, RFCs 3401-3504 -- ages ago.
SIP always was kinda different (allowing an informational RFC through that included MUSTs), so sipcore may not care, but ...

BTW, I found 3263 to be not too bad at all; it does lose it and drift into philosophy (or at least, not English) half way through, but the protocol use bits are fine, IMHO. The 2543 A record and guess approach was and is fugly -- 3263 with its NAPTRs & SRVs has to be a better way. With Dane, it's even better.

all the best,
  Lawrence

On 19 Aug 2014, at 19:11, Olle E. Johansson <[email-masked]> wrote:
>> <snip>
> <snip>

---

From: Lawrence Conroy <[email-masked]>
Date: Wed, 20 Aug 2014 01:58:52 +0100

> 2915 was obsoleted by that fine collection, RFCs 3401-3504 -- ages ago.

To which I edit:
2915 was obsoleted by that fine collection, RFCs 3401-3405 -- ages ago.
The DDDS set just seemed that long. (The core NAPTR ref is, BTW, 3403).
atb,  L
Repeat after me: sleep before mailing.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 25 Aug 2014 17:27:36 -0600

> equivalent to an active attack and cause the peer to be skipped.

How about this?

    (because the TLSA records can
    be ignored if the address records are not secure, performing the TLSA
    queries in parallel is not harmful from a security perspective).

Peter

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 25 Aug 2014 23:32:24 +0000

>    queries in parallel is not harmful from a security perspective).

The reason to skip (or at least ignore lookup errors with) TLSA
lookups when A/AAAA are "insecure" are operational, not security.
So perhaps:

   s/security perspective/operational perspective/

Otherwise, if it says what you want it to say, fine.  I am not sure
we the draft needs to teach implementors how to optimize the
implementation, but if you feel it is important (to encourage
adoption) go for it.

You could probably therefore phrase it a bit better than the
suggested substitution.

-- 
	Viktor.