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

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 24 Jul 2014 10:19:08 +0200

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.

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. 
In fact the DNS SRV rfc talks about "any address family" - now and in the future ;-)

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

That will help me in sipcore :-)

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?

Sorry I couldn't be in Toronto :-(

/O

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 24 Jul 2014 12:58:27 +0000

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:

   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]).

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.

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.  (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).

Bottom line I think the "parallel" language should be withdrawn.

> 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.

> 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

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.

-- 
	Viktor.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 25 Jul 2014 09:42:11 +0200

> Bottom line I think the "parallel" language should be withdrawn.
Or rewritten to make it olle-compatible ;-)

> specify lookup concurrency.
+1

The reference to Happy Eyeballs, which is all about connection attempts,
mislead me I guess. I think we may add "the handling of network connection
attempts is not defined in this document".
> when both (at least one SAN of type DNS and a CN in the subject

Then we need to clarify this again.

Thanks for your response, Viktor!

/O

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 24 Jul 2014 12:43:21 +0000

-- 
	Viktor.