Subject: [dns-privacy] More WGLC reviews for TLS Profiles draft?

From: Sara Dickinson <[email-masked]>
Date: Thu, 8 Dec 2016 09:51:51 +0000

Hi All, 

Just to follow up on Tim’s mail. Any reviews of https://datatracker.ietf.org/doc/draft-ietf-dprive-dtls-and-tls-profiles/ <https://datatracker.ietf.org/doc/draft-ietf-dprive-dtls-and-tls-profiles/> would be much appreciated to try to wind up the WGLC asap. 

Regards

Sara. 

> Begin forwarded message:
> 
> From: Tim Wicinski <[email-masked]>
> Subject: [dns-privacy] Thanks for input on padding-profile draft....now can we talk TLS Profiles?
> Date: 29 November 2016 17:54:21 GMT
> To: "[email-masked]" <[email-masked]>
> 
> 
> All
> 
> We are grateful for the feedback on edns-padding-profile document, The Chairs would like to get some more comments on the TLS Profiles draft, found here:
> 
> https://datatracker.ietf.org/doc/draft-ietf-dprive-dtls-and-tls-profiles/
> 
> There was some good discussion during the meeting in Seoul, but we don't have enough discussion on the mailing to move this draft forward.
> 
> thanks
> tim
> 
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: "Christian Huitema" <[email-masked]>
Date: Thu, 8 Dec 2016 17:18:34 -0800

On Thursday, December 8, 2016 1:52 AM, Sara Dickinson wrote:
> 
> Just to follow up on Tim’s mail. Any reviews of https://datatracker.ietf.org/doc/draft-ietf-dprive-dtls-and-tls-profiles/ would be much appreciated to try to wind up the WGLC asap. 

I just reviewed this draft. I think it is ready, and I would be happy if it was published as is. 

My only wish is for a bit more description of the interaction between policy and configuration. The selection of the strict or opportunistic profile is only one element in the configuration of the DNS client for privacy, the other element being obviously the choice of the DNS server. The strict mode, in particular, ought to depend on configuring a set of servers that the client will accept to trust -- but even the opportunistic mode depends on that to a degree. This is quite different from the current practice, in which DNS servers are configured by untrusted processes. It would be nice if we had a blow-by-blow example of how that's supposed to work. 

-- Christian Huitema

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 10 Dec 2016 08:52:05 +0000

On Thu, Dec 08, 2016 at 09:51:51AM +0000,
 Sara Dickinson <[email-masked]> wrote 
 a message of 138 lines which said:

> Just to follow up on Tim’s mail. Any reviews of
> https://datatracker.ietf.org/doc/draft-ietf-dprive-dtls-and-tls-profiles/ <https://datatracker.ietf.org/doc/draft-ietf-dprive-dtls-and-tls-profiles/> would be much appreciated to try to wind up the WGLC asap.

I've read draft-ietf-dprive-dtls-and-tls-profiles-07 and I've little
to add to what I said in
<https://mailarchive.ietf.org/arch/msg/dns-privacy/qKI3hnyCDywqYqCxFIyRDkYOvIA>
The points I raised there have been well addressed.

I'm still a bit concerned about the issue of detection (that there is
an attack). Detection for passive attacks is only possible if there is
a prior history, unlike the detection for active attacks, but I have
no concrete suggestion to improve table 1, while keeping it simple to
read.

So, it is OK for me, draft-ietf-dprive-dtls-and-tls-profiles-07 can be
published.

Editorial:

None found

---

From: "John R Levine" <[email-masked]>
Date: 10 Dec 2016 16:26:52 -0500

I read it, and I think it's OK to publish, but I found it very 
frustrating.  It describes a zillion options but it doesn't tell me what 
to do.  I realize that there's a fundamentally intractable problem when 
the info you want to bootstrap your secure DNS channel has to be looked up 
in the DNS, and also realize that since this is so new, we have no 
operational experience so the most we could do would be a BWSP.*

You might consider adding something about the info leakage tradeoffs
of various bootstrap schemes.  For example, if the client knows the
name of the cache it wants to use, and queries in the clear for SRV,
A, and TLSA, those will leak but as soon as it connects to port 853 of
the cache, anyone sniffing traffic will know that's the cache it's
using anyway, and anyone with passive DNS could recover the name.  Or if 
you distribute the name and DNSSEC chain out of band, that hardly leaks 
anything but has all the problems of manual key distribution.

Once we have experience, a real BCP describing what works in practice
would be useful, too.

Micronit in sec 6.5 third para, "at least on piece" -> "at least one piece"

R's,
John

* - Best Wildly Speculative Practice

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 13 Dec 2016 09:17:54 +0100

On Sat, Dec 10, 2016 at 04:26:52PM -0500,
 John R Levine <[email-masked]> wrote 
 a message of 30 lines which said:

> I realize that there's a fundamentally intractable problem when the
> info you want to bootstrap your secure DNS channel has to be looked
> up in the DNS [...]  You might consider adding something about the
> info leakage tradeoffs of various bootstrap schemes.  For example,
> if the client knows the name of the cache it wants to use, and
> queries in the clear for SRV, A, and TLSA, those will leak but as
> soon as it connects to port 853 of the cache, anyone sniffing
> traffic will know that's the cache it's using anyway,

This problem exists also for "step 2" (draft-bortzmeyer-dprive-step-2,
section 3.2). If anyone can write nice text about it, it would be
useful.

---

From: Sara Dickinson <[email-masked]>
Date: Tue, 13 Dec 2016 15:22:23 +0000

> On 9 Dec 2016, at 01:18, Christian Huitema <[email-masked]> wrote:
> 

Hi Christian, 

> I just reviewed this draft. I think it is ready, and I would be happy if it was published as is. 

Many thanks for the review. 

> My only wish is for a bit more description of the interaction between policy and configuration. The selection of the strict or opportunistic profile is only one element in the configuration of the…

IIRC this was discussed a bit in Buenos Aires… and I believe the consensus was to have an example such as that in section 7.2.2  for Strict but to leave any other policy discussion out of this document hence the following sentence was added to Section 4:

"A description of the variety of usage policies is out of scope of this document, but may be the subject of future work.”

It seems there is some appetite for a follow up document on operational practices so perhaps that is where this policy discussion should be?

Sara.

---

From: Sara Dickinson <[email-masked]>
Date: Tue, 13 Dec 2016 15:22:50 +0000

> On 10 Dec 2016, at 08:52, Stephane Bortzmeyer <[email-masked]> wrote:
> 

Hi Stephane, 

> The points I raised there have been well addressed.

Thanks for that. 

> a prior history, unlike the detection for active attacks,

I’m not sure it is true that detection requires prior history, it just makes any attack more obvious. In this text

  "However, if it is available and the user is informed that
   an unencrypted connection was used to connect to a server then the
   user should assume (detect) that the connection is subject to both
   active and passive attack since the DNS queries are sent in clear
   text.  This might be particularly useful if a new connection to a
   certain server is unencrypted when all previous connections were
   encrypted. "

I was trying to indicate that simply using clear text is essentially the same as an attack because the traffic _can_ be subject to passive eavesdropping. 

Would it help to replace the “N, D” labels in the table with just “N” and update the text to say “N == no protection, may be subject to attack”

Sara.

---

From: Sara Dickinson <[email-masked]>
Date: Tue, 13 Dec 2016 15:23:03 +0000

> On 10 Dec 2016, at 21:26, John R Levine <[email-masked]> wrote:

Hi John, 

Thanks for the review. 

> 
> I read it, and I think it's OK to publish, but I found it very frustrating.  It describes a zillion options but it doesn't tell me what to do.  I realize that there's a fundamentally intractable problem when the info you want to bootstrap your secure DNS channel has to be looked up in the DNS, and also realize that since this is so new, we have no operational experience so the most we could do would be a BWSP.*
> 
> using anyway, and anyone with passive DNS could recover the name.  Or if you distribute the name and DNSSEC chain out of band, that hardly leaks anything but has all the problems of manual key distribution.

I really like this idea - thanks.  I’ll work on adding this to the document. 

> Once we have experience, a real BCP describing what works in practice

Agreed. 

Sara.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 13 Dec 2016 16:45:00 +0100

On Tue, Dec 13, 2016 at 03:22:50PM +0000,
 Sara Dickinson <[email-masked]> wrote 
 a message of 51 lines which said:

> > I'm still a bit concerned about the issue of detection (that there
> > is an attack). Detection for passive attacks is only possible if
> > there is a prior history, unlike the detection for active attacks,

...

> I was trying to indicate that simply using clear text is essentially
> the same as an attack because the traffic _can_ be subject to
> passive eavesdropping.

OK (a bit far-fetched but OK).

> Would it help to replace the “N, D” labels in the table with just
> “N” and update the text to say “N == no protection, may be subject
> to attack”

IMHO, no, since, in some cases, there is really the possibility of a
detection, for instance if a server was doing encryption before and
now refuses, you may suspect an attack (or a downgrade of the
server...)