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

[Sara Dickinson <[e-mail]>]

> On 6 May 2017, at 21:31, Eric Rescorla <[e-mail]> wrote:
> 
> Eric Rescorla has entered the following ballot position for
> draft-ietf-dprive-dtls-and-tls-profiles-09: Discuss

Many thanks for the review.

> ----------------------------------------------------------------------
> 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.

Agreed.

> ----------------------------------------------------------------------
> 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.

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.  

> 
>      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.

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>
> 
> 
> 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).

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.

> 
> EDITORIAL
> 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? 

> 
> 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

Ack.

> 
> 
> 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.

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.