Subject: [dns-privacy] Ben Campbell's Yes on draft-ietf-dprive-dns-over-tls-07: (with COMMENT)

From: "Ben Campbell" <[email-masked]>
Date: Mon, 14 Mar 2016 20:58:59 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-dprive-dns-over-tls-07: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dprive-dns-over-tls/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm balloting yes, but I do have a few comments/questions:

- 3.1, third paragraph:
This seems to put normative requirements on clients and servers that do
not implement this draft. If that is really needed, then perhaps this
needs to update the appropriate base spec(s)?

- 3.2, last paragraph:
That's a bit of an odd use of SHOULD. I suggest s/SHOULD/can

- 3.3:
This section seems more about DNS over TCP in general. Is it specific to
TLS? Are the 2119 keywords in this section new requirements, or do they
describe existing requirements from 5966/7766? (If the latter, please
consider stating them with descriptive language rather than normative
language.)

- 4 and subsections:
There seems to be a notable absence of a profile that requires server
authentication but does not require pinning. I assume there's a good
reason for that which is obvious to people with stronger TLS and/or DNS
backgrounds than mine. But it might be helpful to say why.

Do (or should) the profiles have anything to say about clear-text
fallback if a client cannot connect to the server's DNS-over-TLS port, or
the TLS handshake fails? I infer that such fallback should not occur with
the pinned profile, but what about the opportunistic profile?

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 15 Mar 2016 15:14:48 +0100

On Mon, Mar 14, 2016 at 08:58:59PM -0700,
 Ben Campbell <[email-masked]> wrote 

> needs to update the appropriate base spec(s)?

Old (not implementing this draft) DNS clients and servers will not use
port 853 at all so this paragraph means nothing to them. (That's one
of the reasons to use a dedicated port, instead of the original method
of "upgrade to TLS" on port 53.)

> authentication but does not require pinning.

The way I see it, the profiles in
draft-ietf-dprive-dtls-and-tls-profiles-00, another DPRIVE work item,
are not defined by the techniques they use but by the security
properties they have. That's why the profile in
draft-ietf-dprive-dtls-and-tls-profiles-00, section 6, for instance,
says "domain name - authentified by X.509 or DANE - or pin".

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 15 Mar 2016 15:23:40 +0100

On Mon, Mar 14, 2016 at 08:58:59PM -0700,
 Ben Campbell <[email-masked]> wrote 
 a message of 54 lines which said:

> There seems to be a notable absence of a profile that requires
> server authentication but does not require pinning. I assume there's
> a good reason for that which is obvious to people with stronger TLS
> and/or DNS backgrounds than mine. But it might be helpful to say
> why.

I don't have a clear response here. Re-reading
draft-ietf-dprive-dns-over-tls-07, I find that the profile in 4.2 is
defined by a technique (pinning) not by its privacy properties. Is it
a good idea?

> fallback if a client cannot connect to the server's DNS-over-TLS
> port, or the TLS handshake fails? I infer that such fallback should
> not occur with the pinned profile, but what about the opportunistic
> profile?

I don't want to reopen discussions on
draft-ietf-dprive-dns-over-tls-07 but may be we can improve it for
draft-ietf-dprive-dtls-and-tls-profiles-00: its definition in section
5 does not address this issue. May be have two opportunistic
profiles, one with fallback to clear text if necessary and another
without?

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 15 Mar 2016 09:42:09 -0500

> of "upgrade to TLS" on port 53.)

Does this mean old servers cannot be configured to use 853 as an 
alternative port? (Then why have the normative language in the first 
place.)

> says "domain name - authentified by X.509 or DANE - or pin".

Normally it would seem to me that the choice between authenticating and 
not authenticating changes the security properties in at least some 
situations. I can imagine configuring a host to use Google's DNS service 
because I did not want my ISP to see my DNS traffic, but not going to 
the trouble of pinning the certificate.

OTOH, It just occurred to me that I don't recall the draft talking about 
what name validation. (Maybe I missed or forgot it; I don't have the 
text in front of at the moment.) Depending on the choices there, (and 
assuming there's not much choice for DNS servers), I can see how 
non-pinned authentication might not add much.

Ben.

---

From: Sara Dickinson <[email-masked]>
Date: Wed, 16 Mar 2016 17:10:07 +0000

> On 15 Mar 2016, at 14:23, Stephane Bortzmeyer <[email-masked]> wrote:
> 

Hi Stephane/Ben, 

Note that the discussion in draft-ietf-dprive-dtls-and-tls-profiles-00 section 4.2 quotes RFC7435 directly which states that Opportunistic Security is described as

“... the use of cleartext as the baseline communication
         security policy, with encryption and authentication negotiated
         and applied to the communication when available.”

So at the moment that draft describes 2 profiles, a Strict one which requires authentication (or failure), or an Opportunistic one as described above. The use case for an ‘in-between’ profile that requires encryption but not authentication is debatable since it only provides limited protection from attacks.

Sara.