Subject: [dns-privacy] draft-ietf-dprive-dtls-and-tls-profiles: strict privacy

From: "Paul Hoffman" <[email-masked]>
Date: Sat, 22 Oct 2016 16:26:30 -0700

Greetings. The tone in Section 4 about strict privacy seems completely 
wrong to me. I recognize that there some users really want to be able to 
configure strict privacy for themselves, but the text in the section 
ignores the fact that if strict privacy cannot be achieved in a 
particular session, a user is likely to turn off DNS-over-TLS. The text 
here makes opportunistic privacy seem like a weak second cousin, not a 
legitimate choice for people who want to encrypt where possible. If a 
user sees "you can't use the Internet because of your setting for DNS 
over TLS", the result will be less overall privacy than if the document 
primarily emphasizes opportunistic privacy, and describes strict privacy 
only for those users who are willing to have no internet connectivity at 
some times.

There are many ways that strict privacy can fail. The most obvious one, 
which we still see repeatedly, is a name server that forgets to renew 
its certificate. There are many others, all of which can be controlled 
by an attacker: SRV chains that accidentally get changed, CNAME chains 
that change, temporary unavailability of OCSP or CRL information, and so 
on. Note that many of these attacks are not on-path between the user and 
the name server. An attacker who wants to force users to choose to not 
use DNS-over-TLS can block any of these to anger users enough to turn 
off DNS-over-TLS.

I propose that Section 4 be completely recast. Keep in all the stuff 
about opportunistic allowing on-path attackers to view and modify 
traffic, but start with the attitude that most users would prefer the 
chance of some encryption but always get Internet service, and that 
fewer users would want no internet service if there is anything wrong 
with the authentication. That is, emphasize opportunistic privacy 
because it is less fragile and less likely to be later turned off.

I'm not going to write up the full recast unless there is consensus in 
the WG to do so. Clearly, I'm not the one to judge that consensus.

Also: why is "hard failure" the fourth bullet describing Opportunistic 
Privacy? That would only apply to Strict Privacy, correct?

Even if the WG doesn't want to recast the section to emphasize (what I 
consider) the profile more people will want due to its resilience, I 
still would like to see the following sentence removed: "Since Strict 
Privacy provides the strongest privacy guarantees it is preferable to 
Opportunistic Privacy." It is only preferable to people who are willing 
to lose all Internet connectivity, not to everyone.

--Paul Hoffman

---

From: Sara Dickinson <[email-masked]>
Date: Thu, 27 Oct 2016 14:45:18 +0100

> On 23 Oct 2016, at 00:26, Paul Hoffman <[email-masked]> wrote:
> 
> Greetings. The tone in Section 4 about strict privacy seems completely wrong to me. I recognize that there some users really want to be able to configure strict privacy for themselves, but the text in the section ignores the fact that if strict privacy cannot be achieved in a particular session, a user is likely to turn off DNS-over-TLS. The text here makes opportunistic privacy seem like a weak second cousin, not a legitimate choice for people who want to encrypt where possible. If a user sees "you can't use the Internet because of your setting for DNS over TLS", the result will be less overall privacy than if the document primarily emphasizes opportunistic privacy, and describes strict privacy only for those users who are willing to have no internet connectivity at some times.

Hi Paul, 

We started but didn’t conclude a similar, smaller scale discussion during your review of the -03 version. Based on that discussion I proposed the following text for the end of section 4:

"Strict Privacy provides the strongest privacy guarantees and therefore SHOULD
always be implemented in DNS clients along with Opportunistic Privacy.

A DNS client that implements DNS-over-(D)TLS SHOULD NOT default to the use of
clear text (no privacy). 

The choice between the two profiles depends on a number of factors including
which is more important to the particular client:
*  DNS service at the cost of no privacy guarantee (Opportunistic) or
*  guaranteed privacy at the potential cost of no DNS service (Strict).

Additionally the two profiles require varying levels of configuration (or a
trusted relationship with a provider) and DNS server capabilities therefore DNS
clients will need to carefully select which profile to use based on their 
communication privacy needs. 

A DNS server that implements DNS-over-TLS SHOULD provide at least one credential
in order that those DNS clients that wish to do so are able to use Strict
Privacy (see Section 2).”

I didn’t get any further feedback on this so didn’t include the text in the next version (which I really should have). I’d like to think we could work on improving this text to paint the correct picture of the 2 classes of user and which profile is most suitable for them? 

> 
> Also: why is "hard failure" the fourth bullet describing Opportunistic Privacy? That would only apply to Strict Privacy, correct?

Not necessarily. From RFC7435: “Opportunistic security protocols may hard-fail with peers for which a
   security capability fails to function as advertised. “

Sara.

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 27 Oct 2016 08:18:11 -0700

On 27 Oct 2016, at 6:45, Sara Dickinson wrote:

>> Greetings. The tone in Section 4 about strict privacy seems 
>> completely wrong to me. I recognize that there some users really want 
>> to be able to configure strict privacy for themselves, but the text 
>> in the section ignores the fact that if strict privacy cannot be 
>> achieved in a particular session, a user is likely to turn off 
>> DNS-over-TLS. The text here makes opportunistic privacy seem like a 
>> weak second cousin, not a legitimate choice for people who want to 
>> encrypt where possible. If a user sees "you can't use the Internet 
>> because of your setting for DNS over TLS", the result will be less 
>> overall privacy than if the document primarily emphasizes 
>> opportunistic privacy, and describes strict privacy only for those 
>> users who are willing to have no internet connectivity at some times.
>
> Hi Paul,
>
> We started but didn’t conclude a similar, smaller scale discussion 
> during your review of the -03 version. Based on that discussion I 
> proposed the following text for the end of section 4:
>
> I didn’t get any further feedback on this so didn’t include the 
> text in the next version (which I really should have). I’d like to 
> think we could work on improving this text to paint the correct 
> picture of the 2 classes of user and which profile is most suitable 
> for them?

I apologize for not giving feedback at the time; I was waiting for other 
people to chime in and then forgot.

That text is really good. However, instead of at the end of Section 4, I 
would put it right after Table 1, replacing "Since Strict Privacy 
provides the strongest privacy guarantees it is preferable to 
Opportunistic Privacy".

>> Also: why is "hard failure" the fourth bullet describing 
>> Opportunistic Privacy? That would only apply to Strict Privacy, 
>> correct?
>

Yes, I saw that there, but it makes no sense in this document because we 
explicitly allow for both going to no TLS and not telling the user about 
whether TLS is in use. I think that bit in RFC 7435 only applies to 
systems where the user sees that TLS is in use. We really should take it 
out of this document; otherwise, we have to add in a lot more about 
users knowing about the use of TLS.

--Paul Hoffman

---

From: Sara Dickinson <[email-masked]>
Date: Thu, 27 Oct 2016 17:43:38 +0100

> I apologize for not giving feedback at the time; I was waiting for other people to chime in and then forgot.

My bad, I should have included the text regardless. 

> 
> That text is really good. However, instead of at the end of Section 4, I would put it right after Table 1, replacing "Since Strict Privacy provides the strongest privacy guarantees it is preferable to Opportunistic Privacy”.

Yes indeed - I meant at the end of section 4.2 which is exactly there. 

> Yes, I saw that there, but it makes no sense in this document because we explicitly allow for both going to no TLS and not telling the user about whether TLS is in use. I think that bit in RFC 7435 only applies to systems where the user sees that TLS is in use. We really should take it out of this document; otherwise, we have to add in a lot more about users knowing about the use of TLS.

So I’m not sure here. The aim here was to try to keep this section flexible in terms of the interpretation of OS but perhaps this needs discussion.

RFC 7435 says "An OS protocol first determines the capabilities of the peer with which it is attempting to communicate.  Peer capabilities may be discovered by out-of-band or in-band means.  (Out-of-band mechanisms include the use of DANE records….”
and then allows for the hard failure if the capability isn’t as described. So this seems to leave the door open for clients to choose to hard-fail in certain circumstances which seem relevant to this document (I don’t see any caveats about this only happening if users know what is going on). It seems overkill to completely override that here with something like "Opportunistic clients MUST fallback to clear text…” unless there is consensus that that is how it should work for DNS in all cases?

Sara.

---

From: Bob Harold <[email-masked]>
Date: Thu, 27 Oct 2016 14:03:20 -0400

On Thu, Oct 27, 2016 at 12:43 PM, Sara Dickinson <[email-masked]> wrote:

>
>
> I didn’t get any further feedback on this so didn’t include the text in
> the next version (which I really should have). I’d like to think we could
> work on improving this text to paint the correct picture of the 2 classes
> of user and which profile is most suitable for them?
>
>
> would put it right after Table 1, replacing "Since Strict Privacy provides
> the strongest privacy guarantees it is preferable to Opportunistic Privacy”.
>
>
> whether TLS is in use. I think that bit in RFC 7435 only applies to systems
> where the user sees that TLS is in use. We really should take it out of
> this document; otherwise, we have to add in a lot more about users knowing
> about the use of TLS.
>
>
> So I’m not sure here. The aim here was to try to keep this section
> flexible in terms of the interpretation of OS but perhaps this needs
> discussion.
>
> RFC 7435 says "An OS protocol first determines the capabilities of the
> peer with which it is attempting to communicate.  Peer capabilities may be
> discovered by out-of-band or in-band means.  (Out-of-band mechanisms
> include the use of DANE records….”
> and then allows for the hard failure if the capability isn’t as described.
> So this seems to leave the door open for clients to choose to hard-fail in
> certain circumstances which seem relevant to this document (I don’t see any
> caveats about this only happening if users know what is going on). It seems
> overkill to completely override that here with something like
> "Opportunistic clients MUST fallback to clear text…” unless there is
> consensus that that is how it should work for DNS in all cases?
>
> Sara.
>
>
It seems that there are levels of Opportunistic Security (OS), either
falling back to TLS to an un-authenticated server, or falling back to clear
text (no TLS).  We should make it clear that there are various levels, and
that there should be some way to choose what minimum level is allowed.

-- 
Bob Harold

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 27 Oct 2016 11:28:29 -0700

>> flexible in terms of the interpretation of OS but perhaps this needs

It seems like it does need discussion.

> that there should be some way to choose what minimum level is allowed.

I will admit that I thought there was just one bottom level of OS in our 
discussion, cleartext. If there are two (cleartext; no communication), 
the document needs more discussion in multiple places because it would 
be surprising to any implementer who didn't follow the long discussion 
during the end stages of RFC 7435.

Which users do we think would not want to negotiate weak TLS (such as 
DES-MD2) but would be willing to go to cleartext? For other than crypto 
experts (who are likely to only want Strict), how would weak TLS be 
worse than cleartext?

It feels like this is adding a layer of operational complexity for an 
audience who probably doesn't exist.

--Paul Hoffman

---

From: Sara Dickinson <[email-masked]>
Date: Fri, 28 Oct 2016 11:21:56 +0100

> On 27 Oct 2016, at 19:28, Paul Hoffman <[email-masked]> wrote:
> 
> I will admit that I thought there was just one bottom level of OS in our discussion, cleartext. If there are two (cleartext; no communication), the document needs more discussion in multiple places because it would be surprising to any implementer who didn't follow the long discussion during the end stages of RFC 7435.

As the draft stands it is clear about what Strict is and allows for all flavours of OS, essentially leaving it as an implementation choice. If, because of the nature of DNS, the feeling is it makes more sense that Opportunistic _always_ falls back to clear text in order to get service then I can see the value in that. It is just a question of spelling this out clearly in the draft. 

> Which users do we think would not want to negotiate weak TLS (such as DES-MD2) but would be willing to go to cleartext? For other than crypto experts (who are likely to only want Strict), how would weak TLS be worse than cleartext?

There was some discussion in Buenos Aires (I think) about an intermediate ‘Relaxed’ mode where a client is willing to use a (weakly) encrypted connection but not willing to fallback to clear text so as to have some protection against passive monitoring. But IIRC the consensus was ‘keep it simple, Strict or Opportunistic’.  

For me the other ‘intermediate’ case I was really thinking of in the hard-fail case for Opportunistic is when the client does have authentication information configured (as opposed to having none) but the authentication fails. Should there be scope for the client to decide in that case that something is wrong enough it doesn't want to continue? As you say, maybe this is complicating the picture too much. 

Sara.

---

From: Bob Harold <[email-masked]>
Date: Fri, 28 Oct 2016 11:27:04 -0400

On Fri, Oct 28, 2016 at 6:21 AM, Sara Dickinson <[email-masked]> wrote:

> discussion, cleartext. If there are two (cleartext; no communication), the
> document needs more discussion in multiple places because it would be
> surprising to any implementer who didn't follow the long discussion during
> the end stages of RFC 7435.
>
> As the draft stands it is clear about what Strict is and allows for all
> flavours of OS, essentially leaving it as an implementation choice. If,
> because of the nature of DNS, the feeling is it makes more sense that
> Opportunistic _always_ falls back to clear text in order to get service
> then I can see the value in that. It is just a question of spelling this
> out clearly in the draft.
>
> experts (who are likely to only want Strict), how would weak TLS be worse
> than cleartext?
>
> There was some discussion in Buenos Aires (I think) about an intermediate
> ‘Relaxed’ mode where a client is willing to use a (weakly) encrypted
> connection but not willing to fallback to clear text so as to have some
> protection against passive monitoring. But IIRC the consensus was ‘keep it
> simple, Strict or Opportunistic’.
>
> For me the other ‘intermediate’ case I was really thinking of in the
> hard-fail case for Opportunistic is when the client does have
> authentication information configured (as opposed to having none) but the
> authentication fails. Should there be scope for the client to decide in
> that case that something is wrong enough it doesn't want to continue? As
> you say, maybe this is complicating the picture too much.
>
> Sara.
>
>
In Section 5 on Opportunistic Privacy, I am not sure "MAY" is correct.  If
the user chooses Opportunistic, I would think the server MUST try to be
secure, in whatever ways are possible, but MAY fall back to less secure,
only if those fail.

-- 
Bob Harold

---

From: "Paul Hoffman" <[email-masked]>
Date: Fri, 28 Oct 2016 08:39:33 -0700

On 28 Oct 2016, at 3:21, Sara Dickinson wrote:

>> I will admit that I thought there was just one bottom level of OS in 
>> our discussion, cleartext. If there are two (cleartext; no 
>> communication), the document needs more discussion in multiple places 
>> because it would be surprising to any implementer who didn't follow 
>> the long discussion during the end stages of RFC 7435.
>
> As the draft stands it is clear about what Strict is and allows for 
> all flavours of OS, essentially leaving it as an implementation 
> choice. If, because of the nature of DNS, the feeling is it makes more 
> sense that Opportunistic _always_ falls back to clear text in order to 
> get service then I can see the value in that. It is just a question of 
> spelling this out clearly in the draft.

Right. However, the draft currently says in a few places that you choose 
opportunistic if you want to be sure you get DNS service. So you either 
have to remove those, or remove the possibility that OS will not go to 
cleartext.

>> DES-MD2) but would be willing to go to cleartext? For other than 
>> crypto experts (who are likely to only want Strict), how would weak 
>> TLS be worse than cleartext?
>
> There was some discussion in Buenos Aires (I think) about an 
> intermediate ‘Relaxed’ mode where a client is willing to use a 
> (weakly) encrypted connection but not willing to fallback to clear 
> text so as to have some protection against passive monitoring. But 
> IIRC the consensus was ‘keep it simple, Strict or Opportunistic’.

I don't remember the conversation, but I really don't remember anyone 
advocating for "more complicated". Strict, 
Opportunistic-only-to-good-crypto, and Opportunistic-to-cleartext is 
more complicated than Strict and Opportunistic-to-cleartext. Users don't 
know how to set "good crypto".

> For me the other ‘intermediate’ case I was really thinking of in 
> the hard-fail case for Opportunistic is when the client does have 
> authentication information configured (as opposed to having none) but 
> the authentication fails.

That's Strict, yes?

> Should there be scope for the client to decide in that case that 
> something is wrong enough it doesn't want to continue? As you say, 
> maybe this is complicating the picture too much.

We can make this as complicated as we want. My goal is to prevent people 
from turning it off when the Internet doesn't work and they find out 
it's because DNS-over-TLS was turned on.

--Paul Hoffman

---

From: "Paul Hoffman" <[email-masked]>
Date: Fri, 28 Oct 2016 08:40:38 -0700

> secure, in whatever ways are possible, but MAY fall back to less 

In TLS, it's not the server that tries to be secure, it's the client. 
The server offers a bunch of stuff, but only once. The client picks, but 
only once.

--Paul Hoffman

---

From: Sara Dickinson <[email-masked]>
Date: Fri, 28 Oct 2016 17:08:24 +0100

> On 28 Oct 2016, at 16:40, Paul Hoffman <[email-masked]> wrote:
> 

I think it is this text that Bob is referring to:

“Clients using Opportunistic Privacy SHOULD try for the
   best case but MAY fallback to intermediate cases and eventually the
   worst case scenario in order to obtain a response.  It therefore
   provides no privacy guarantee to the user and varying protection
   depending on what kind of connection is actually used.”

One reason I left this as a SHOULD not a MUST because forcing a client to try all available servers for a secure encrypted connection can introduce significant latency into the resolution process which is probably undesirable for Opportunistic. For example, the client has 5 recursive resolvers configured. Authentication fails on the first, but encryption is ok. MUST the client try everyone of the other server to try to get an authenticated & encrypted connection or can it just use the encrypted connection it already has set up, given that it is using Opportunistic Privacy anyway? Appendix A touches on this a little bit too in terms of probing for server capabilities. 

And yes, if we decide to go for keeping it simple then I think this should be  

“Clients using Opportunistic Privacy SHOULD try for the
   best case and SHOULD fallback to intermediate cases and eventually the
   worst case scenario in order to obtain a response. “

Sara.