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

[Eric Rescorla <[e-mail]>]

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.