Subject: [dns-privacy] Eric Rescorla's Discuss on draft-ietf-dprive-dtls-and-tls-profiles-09: (with DISCUSS and COMMENT)

From: Eric Rescorla <[email-masked]>
Date: Sat, 06 May 2017 13:31:12 -0700

Eric Rescorla has entered the following ballot position for
draft-ietf-dprive-dtls-and-tls-profiles-09: Discuss

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-dtls-and-tls-profiles/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

S 9 mandates RFC 7250:
   o  Raw public keys [RFC7250] which reduce the size of the
      ServerHello, and can be used by servers that cannot obtain
      certificates (e.g., DNS servers on private networks).

This needs to be updated to indicate that the client MUST NOT
offer 7250 unless it has a preconfigured SPKI, otherwise
you're going to have interop problems.

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

TECHNICAL
S 5.
      subsequently connect.  The rationale for this is that requiring
      Strict Privacy for such meta queries would introduce significant
      deployment obstacles.  This profile provides strong privacy
      guarantees to the client.  This Profile is discussed in detail in
      Section 6.6.

This point seems unclear. If you do these queries unprotected, then
you don't have strong privacy guarantees. I think you mean that
you get them via some trusted mechanism such as DHCP.

      widespread adoption of Strict Privacy.  It should be employed
when
      the DNS client might otherwise settle for cleartext; it provides
      the maximum protection available.

I don't think this statement is accurate. It provides the best
protection
that the attacker will allow.

Table 1 seems to have N and D paired, so maybe you can coalesce them?

S 6.4.
   A DNS client that is configured with both an authentication domain
   name and a SPKI pinset for a DNS server SHOULD match on both a valid
   credential for the authentication domain name and a valid SPKI
pinset
   (if both are available) when connecting to that DNS server.  The
   overall authentication result should only be considered successful
if
   both authentication mechanisms are successful.

You should cover the topic of user-defined trust anchors. Here's the
relevant text from 7469:

   For example, a UA may disable Pin Validation for Pinned Hosts whose
   validated certificate chain terminates at a user-defined trust
   anchor, rather than a trust anchor built-in to the UA (or underlying
   platform).
      
EDITORIAL
Do you want to cite TLS 1.3 at this point?

S 3.
   o  Any server identifier other than domain names, including IP
      address, organizational name, country of origin, etc.

addresses, names, for parallel structure with domain names

S 9.
   There are known attacks on (D)TLS, such as machine-in-the-middle and
   protocol downgrade.  These are general attacks on (D)TLS and not
   specific to DNS-over-TLS; please refer to the (D)TLS RFCs for
   discussion of these security issues.

This text seems pretty unhelpful. Given that you are specifying 1.2,
if you also require the relevant strong algorithms, then there should
not be downgrade or MITM attacks.

---

From: Sara Dickinson <[email-masked]>
Date: Mon, 8 May 2017 09:21:10 +0100

> On 6 May 2017, at 21:31, Eric Rescorla <[email-masked]> wrote:
> 

Many thanks for the review.

Agreed.

No, we mean they could be done either via Opportunistic lookups or DHCP (see table 2.)
The meta queries contain no information about what DNS lookups the client is doing other than what DNS Privacy server they are going to use to do their queries. But you are correct that the ‘strong privacy guarentees’ apply only to the subsequent queries to the Privacy server and the text should be updated to clarify that.  

> that the attacker will allow.

Agreed - will update. 

> Table 1 seems to have N and D paired, so maybe you can coalesce them?

That specific question was asked on the WG mailing list and the answer was ‘no, please keep both’:
https://www.ietf.org/mail-archive/web/dns-privacy/current/msg01541.html <https://www.ietf.org/mail-archive/web/dns-privacy/current/msg01541.html>
>   anchor, rather than a trust anchor built-in to the UA (or underlying

We purposely avoided adding any details on the SPKI mechanisms in this document because this document simply refers to RFC7585 which then directly references RFC7469. But if you think this is needed here also then I’ll add it.

> Do you want to cite TLS 1.3 at this point?

Early on we chose not to include a normative reference to the TLS 1.3 draft to avoid the dependancy on that becoming an RFC but are you suggesting we do that now or just include an informative reference?

Do you think Section 9 the right place to talk about TLS 1.3 in general or do you feel there are specific points to made elsewhere in the text? 

> addresses, names, for parallel structure with domain names

Ack.

> not be downgrade or MITM attacks.

How about moving the justification later in the section:

“ Clients and servers MUST adhere to the (D)TLS implementation
   recommendations and security considerations of [RFC7525] except with
   respect to (D)TLS version.

  Since encryption of DNS using (D)TLS is a green-field deployment DNS
   clients and servers MUST implement only (D)TLS 1.2 or later.

  These requirements ensure mitigation against known attacks on 
  (D)TLS, such as machine-in-the-middle and
  protocol downgrade.  These are general attacks on (D)TLS and not
  specific to DNS-over-TLS.”

Regards

Sara.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 8 May 2017 05:01:49 -0700

On Mon, May 8, 2017 at 1:21 AM, Sara Dickinson <[email-masked]> wrote:

> The meta queries contain no information about what DNS lookups the client
> is doing other than what DNS Privacy server they are going to use to do
> their queries. But you are correct that the ‘strong privacy guarentees’
> apply only to the subsequent queries to the Privacy server and the text
> should be updated to clarify that.
>

Well, per my previous comment, I think you need to focus on the entire
strategy.

I.e., if you determine whether to adopt a Strict policy based on
Opportunistic queries, then you are back to the active attack setting. I
don't have a problem with your design here, which seems to be about as good
as one can do; I'm just trying to make sure the description is accurate...

> https://www.ietf.org/mail-archive/web/dns-privacy/current/msg01541.html
>

OK. Perhaps add some text that theya re paired

S 6.4.
> We purposely avoided adding any details on the SPKI mechanisms in this
> document because this document simply refers to RFC7585 which then directly
> references RFC7469. But if you think this is needed here also then I’ll add
> it.
>

The concern I have is that this guidance seems to implicitly contradict the
guidance from 7469. So I think you should either just say that if you have
both you treat it like a 7469 pin, or say something like "successful, with
the possible exception of certificates which chain to local trust anchors,
as described in..." Or, alternately really prohibit this. Also, should ->
SHOULD.

> Early on we chose not to include a normative reference to the TLS 1.3
> draft to avoid the dependancy on that becoming an RFC but are you
> suggesting we do that now or just include an informative reference?
>

I would think at least an informative reference would be useful.

Do you think Section 9 the right place to talk about TLS 1.3 in general or
> do you feel there are specific points to made elsewhere in the text?
>

1.3 has pretty much the same properties here, so I think you might just
cite 1.3 and make it informative. I'm not sure what the right actual
mechanics are here, but surely such a thing is possible.

>   specific to DNS-over-TLS.”

My complaint is that this seems kinda FUDdy. If there are things that you
think people
ought to do other than those in 7525, you ought to say them.

-Ekr

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 9 May 2017 22:56:14 -0400

Hi,

Just a couple of comments inline.

On Mon, May 8, 2017 at 8:01 AM, Eric Rescorla <[email-masked]> wrote:
>> draft to avoid the dependancy on that becoming an RFC but are you suggesting
>> we do that now or just include an informative reference?
>
>
> 1.3 has pretty much the same properties here, so I think you might just cite
> 1.3 and make it informative. I'm not sure what the right actual mechanics
> are here, but surely such a thing is possible.
>

The draft already says TLS 1.2 or higher, so you do already allow for
TLS 1.3.  You could put an informative reference as TLS 1.3 being an
option.  TLS 1.2 hasn't been deprecated and the guidance with 7525 is
there already to prevent known problems.  An informative reference
shouldn't hold up this draft, but it's up to the WG if they want to
include it explicitly IMO.

> ought to do other than those in 7525, you ought to say them.

I agree with EKR.  The recommendation to follow 7525 is enough.

-- 

Best regards,
Kathleen

---

From: Sara Dickinson <[email-masked]>
Date: Thu, 11 May 2017 12:58:55 +0100

Hi Ekr (and Kathleen),

> On 8 May 2017, at 13:01, Eric Rescorla <[email-masked]> wrote:
> Well, per my previous comment, I think you need to focus on the entire strategy.
> 
> I.e., if you determine whether to adopt a Strict policy based on Opportunistic queries, then you are back to the active attack setting. I don't have a problem with your design here, which seems to be about as good as one can do; I'm just trying to make sure the description is accurate...

Oh, I think I see your point now:

- Strict without meta queries to an untrusted source (i.e. name and IP both configured or obtained from a ’trusted’ source) will connect directly to the correct the Privacy server
- Strict with meta queries to an untrusted source provides the opportunity for the attacker to return incorrect answers, directing the client to a bogus Privacy server which the client will not be able to authenticate and therefore the client will not proceed to perform queries. 

so the two approaches are different in terms of mitigating attacks. 

Even if the meta queries were secured with DNSSEC (as they were until a recent version of the draft) this doesn’t help because if the answers are bogus then again, the client won’t continue. 

> The concern I have is that this guidance seems to implicitly contradict the guidance from 7469. So I think you should either just say that if you have both you treat it like a 7469 pin, or say something like "successful, with the possible exception of certificates which chain to local trust anchors, as described in..." Or, alternately really prohibit this. Also, should -> SHOULD.

Got it. I think I would lean towards "if you have both you treat it like a 7469 pin” but would like to hear other views on this. 

> 1.3 has pretty much the same properties here, so I think you might just cite 1.3 and make it informative. I'm not sure what the right actual mechanics are here, but surely such a thing is possible.

An informative reference makes total sense - I’ll add that. 

> My complaint is that this seems kinda FUDdy.

OK - I’ll remove. 

Sara.