Subject: Re: [dns-privacy] New Version Notification for draft-dgr-dprive-dtls-and-tls-profiles-00.txt

From: sara <[email-masked]>
Date: Mon, 4 Jan 2016 09:34:08 +0000

Hi All, 

As discussed by the working group (in Yokohama and on the list) a new draft has been produced

https://tools.ietf.org/html/draft-dgr-dprive-dtls-and-tls-profiles-00 <https://tools.ietf.org/html/draft-dgr-dprive-dtls-and-tls-profiles-00> 

that describes usage profiles, authentication mechanisms and a (D)TLS profile that can be used for both DNS-over-TLS and DNS-over-DTLS:

- It discusses in detail the use of Strict and Opportunistic usage profiles for DNS-over-(D)TLS.

- It describes domain name based authentication mechanisms using both X.509 certificates and DANE as ways that a DNS server can prove its identity for authentication purposes. 

- It presents a (D)TLS profile which defines the configuration options and protocol extensions required to optimise connection establishment and session resumption.

- It additionally has guidance on counter measures to DNS traffic analysis and server capability probing by clients. 

We request review of this document and consideration for adoption by the working group.

Regards

Sara.

>> On 23 Dec 2015, at 16:12, [email-masked] wrote:
>> 
>> 
>> A new version of I-D, draft-dgr-dprive-dtls-and-tls-profiles-00.txt
>> has been successfully submitted by Sara Dickinson and posted to the
>> IETF repository.
>> 
>> Name:		draft-dgr-dprive-dtls-and-tls-profiles
>> Revision:	00
>> Title:		Authentication and (D)TLS Profile for DNS-over-TLS and DNS-over-DTLS
>> Document date:	2015-12-23
>> Group:		Individual Submission
>> Pages:		17
>> URL:            https://www.ietf.org/internet-drafts/draft-dgr-dprive-dtls-and-tls-profiles-00.txt
>> Status:         https://datatracker.ietf.org/doc/draft-dgr-dprive-dtls-and-tls-profiles/
>> Htmlized:       https://tools.ietf.org/html/draft-dgr-dprive-dtls-and-tls-profiles-00
>> 
>> 
>> Abstract:
>>   This document describes how a DNS client can use a domain name to
>>   authenticate a DNS server that uses Transport Layer Security (TLS)
>>   and Datagram TLS (DTLS).  Additionally, it defines (D)TLS profiles
>>   for DNS clients and servers implementing DNS-over-TLS and DNS-over-
>>   DTLS.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 5 Jan 2016 16:53:47 +0100

On Mon, Jan 04, 2016 at 09:34:08AM +0000,
 sara <[email-masked]> wrote 

> https://tools.ietf.org/html/draft-dgr-dprive-dtls-and-tls-profiles-00 <https://tools.ietf.org/html/draft-dgr-dprive-dtls-and-tls-profiles-00> 

I'm confused by section 8.2. It lacks details on how name resolution
is done. I guess the workflow is the following:

* DNS _service_ resolver name is fetched from the configuration

* DNS lookup is done against the default DNS resolver (probably
acquired from DHCP or RA), with no privacy, to find the DNS _host_
resolver name and then its IP address

* Private DNS resolution can now be done against the configured
privacy-aware resolver.

Am I correct? If so, the claim of the draft that you can have "a
DNSSEC validating DNS client configured in this way to do strict DNS
privacy" is doubtful: it is not strict because of the second step,
which has no privacy. May be not a big problem in practice but still
sufficient to avoid labelling it "strict". (Same thing for 9.2, DANE.)

It seems to me that the only way to have really Strict privacy is 8.1.

Also, Table 1 is a bit optimistic: against a passive attacker,
opportunistic privacy provides protection only if the server supports
TLS. Otherwise, unlike Strict, Opportunistic will fall back. (The text
in 4.2 is correct, when it speaks of "undetermined privacy guarantee",
it's just the table which exaggerates.)

Editorial : in section 4.2, there is a reference to "section Section
5".

---

From: Bob Harold <[email-masked]>
Date: Tue, 5 Jan 2016 14:30:27 -0500

On Mon, Jan 4, 2016 at 4:34 AM, sara <[email-masked]> wrote:

> https://tools.ietf.org/html/draft-dgr-dprive-dtls-and-tls-profiles-00
>
> that describes usage profiles, authentication mechanisms and a (D)TLS
> profile that can be used for both DNS-over-TLS and DNS-over-DTLS:
>
> - It describes domain name based authentication mechanisms using both
> X.509 certificates and DANE as ways that a DNS server can prove its
> identity for authentication purposes.
>
> - It presents a (D)TLS profile which defines the configuration options and
> protocol extensions required to optimise connection establishment and
> session resumption.
>
> - It additionally has guidance on counter measures to DNS traffic analysis
> and server capability probing by clients.
>
Apparently I don't understand certificates...

In section 7, an example SRV record is:
_domain-s._tcp.dns.example.com. SRV 0 1 853 dns1.example.com.

But is section 9 I see:
_domain-s.dns.example.com

Are those related?  I really don't understand why section 9 even suggests
adding
_domain-s.dns.example.com

I also don't understand why the Subject field is not valid to use. I
thought subjectAltName was optional, and only used if there were more than
one domain name in the cert.

-- 
Bob Harold

---

From: Shumon Huque <[email-masked]>
Date: Tue, 5 Jan 2016 21:40:42 -0500

> _domain-s.dns.example.com

Section 7 shows a DNS SRV record.

Section 9 shows a subject identity included in the certificate
corresponding to the SRV record owner name, specifically an SRV-ID (Subject
Alternative Name -> OtherName/SRVName type) - see RFC 4985 and RFC6125 for
details.

> one domain name in the cert.

Use of domain names in the subject field's Common Name are large deprecated
by current specs (even though they are commonly issued by public CAs). RFC
6125 for example says:

  o  Move away from including and checking strings that look like
      domain names in the subject's Common Name.

   o  Move toward including and checking DNS domain names via the
      subjectAlternativeName extension designed for that purpose:
      dNSName.

   o  Move toward including and checking even more specific
      subjectAlternativeName extensions where appropriate for using the
      protocol (e.g., uniformResourceIdentifier and the otherName form
      SRVName).

Shumon.

---

From: Shumon Huque <[email-masked]>
Date: Wed, 6 Jan 2016 12:21:48 -0500

On Tue, Jan 5, 2016 at 10:53 AM, Stephane Bortzmeyer <[email-masked]>
wrote:

> > https://tools.ietf.org/html/draft-dgr-dprive-dtls-and-tls-profiles-00 <
> https://tools.ietf.org/html/draft-dgr-dprive-dtls-and-tls-profiles-00>
>
> Am I correct?

Yes, I think this description is mostly correct. Except in the second step,
I
assume you meant that we lookup the DNS resolver name's IP address; we
do not need "to find the DNS _host_ resolver name" since that was obtained
already from static configuration in the prior step.

> If so, the claim of the draft that you can have "a

This depends on the definition of the phrase "Strict Privacy". If it can
include
some initial meta queries to (securely) obtain the address mapping of the
DNS over (D)TLS server that to which we subsequently establish an
authenticated & encrypted session, then this can still be considered
strict.

It could also be argued that 'strict' means no unprotected DNS queries
anywhere, in which case a new category would be needed. I am okay
with "Strict" having the meaning in my previous paragraph. We have to
consider practical deployability and usage issues. A 'no unprotected
DNS anywhere' policy may not be deployable in the general case, because
of a range of system bootstrapping issues and other environmental
issues (for example, a system may need to issue a few unprotected DNS
queries in order to gain access to the network beyond a captive portal
etc).

> it's just the table which exaggerates.)

Yes, I agree.

-- 
Shumon Huque

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 7 Jan 2016 10:48:17 +0100

On Wed, Jan 06, 2016 at 12:21:48PM -0500,
 Shumon Huque <[email-masked]> wrote 
 a message of 155 lines which said:

> I assume you meant that we lookup the DNS resolver name's IP
> address; we do not need "to find the DNS _host_ resolver name" since
> that was obtained already from static configuration in the prior
> step.

No. The static configuration has the _service_ name, not the
_host_name.

draft-dgr-dprive-dtls-and-tls-profiles-00, section 8.2, second
paragraph.

---

From: sara <[email-masked]>
Date: Thu, 7 Jan 2016 16:17:21 +0000

> On 6 Jan 2016, at 17:21, Shumon Huque <[email-masked]> wrote:
> 
> On Tue, Jan 5, 2016 at 10:53 AM, Stephane Bortzmeyer <[email-masked] <mailto:[email-masked]>> wrote:
> 

Stephane, 

Thanks for the review.

> * Private DNS resolution can now be done against the configured

Yes this is correct. We could break the example down as you have done to improve clarity if you like. 

> This depends on the definition of the phrase "Strict Privacy". If it can include

I agree with Shumon’s analysis here, and we did assume the first definition in writing this draft. But, agreed, we should discuss this in more detail.

But note that section 8.2 does state that your steps 1 and 2 (and DANE lookups) can be done opportunistically rather than with no privacy. 

> it's just the table which exaggerates.)

Ah, yes. Will improve this. 

Sara.