Usage Profiles for DNS over TLS and DNS over DTLS
draft-ietf-dprive-dtls-and-tls-profiles-11

[Ballot comment]
Please make RFC 7918 and RFC 7924 Normative references, as they are mentioned in SHOULD level requirements.

I am agreeing with Ekr comments. I am also agreeing on first and last Mirja's comment.

Section on future DHCP extension is a bit "hand-wavy". Is any work on this planned? I see that Suresh raised a DISCUSS on this point, so I am happy for him to hold it.

[Ballot comment]
Here is Eric Vyncke's OPS DIR review:

From the abstract: This document discusses Usage Profiles, based on one or more authentication mechanisms, which can be used for DNS over Transport Layer Security (TLS) or Datagram TLS (DTLS).  This document also specifies new authentication mechanisms. DPRIVE (DNS Private exchange) aims at enhancing DNS privacy by encrypting the DNS traffic (DNSsec only provides authentication/integrity).

There are two profiles: strict and opportunistic. The latter allows normal DNS operations as a fallback, which is key for successful deployment.

This document in section 6  compares the SIX different authentication mechanisms and gives some guidelines with a lot of SHOULD and MAY and little MUST. Unsure whether it makes the implementers' task easy. Section 8 is more directive and more useful.

Section 7.3 is mainly about the legacy DHCP server for the legacy IPv4. No word about IPv6 and no word about RFC 8106 (DNS info for SLAAC).

Overall, there are no discussion about the performance (latency, load of clients/servers) of one authentication mechanism compared to the others, no discussion about resilience (i.e. if one server fails, for example in the PKIX cert chains) and I believe that performance and resilience to network error could be useful for the implementer/architect.

As a reader, I regret that this document combines two aspects: description of the profiles but also how to extend one TLS authentication method to DTLS... I would have preferred having two documents. But, this is mainly about readability.

[Ballot comment]
I'm balloting "yes", but I do have some comments:

Substantive:

5: "Clients using Opportunistic Privacy SHOULD try for the best case..."
When might it be reasonable _not_ to try for the best case? (That is, why not MUST)?

5.1: What's a reasonable granularity for the profile selection? The text suggests that decision is on a per-query basis; is that the intent? I assume you don't expect a user to make a decision for each query.

6.5: The statement that a client using OP "MAY" try to authenticate seems inconsistent with the "SHOULD try for the best case" statement in S5. (But seem my comment above about that.)

13.2: [I-D.ietf-dprive-dnsodtls] is referenced using 2119 keywords, so it should be a normative reference. (Note that this would be a downref.)

Editorial:

2: "MUST implement DNS-over-TLS [RFC7858] and MAY implement DNS- over-DTLS [I-D.ietf-dprive-dnsodtls]."
Unless these are new-to-this-draft requirements, please use descriptive (non-2119) language. (Especially in a definition).

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

Does that mean "SHOULD implement both strict and opportunistic privacy" or "If you implement opportunistic you SHOULD also implement strict?"

6.2: Should list item "2" be "ADN+IP", like in the table?

11: Is "SHOULD consider implementing" different than "SHOULD implement"? If so, please consider dropping the 2119 "SHOULD" when talking about what people think about.

[Ballot discuss]
I do have a concern regarding section 7.3 as it is not clear what really is being requested on the DHCP front here. While using an IP address or an FQDN are generally both possible choices while providing configuration options using DHCP, the use of FQDNs for acquiring trusted DNS servers seems problematic. We have spent a great deal of effort writing up some of the potential issues in Section 8 of RFC7227. It would be good if you can take a look and clarify what is required from a potential new DHCP option and how the failure modes are expected to be handled.

[Ballot comment]
The final paragraph of section 6.6 says "The system MUST alert by some means that the DNS is not private during such bootstrap." -- presumably, this means "client" where it says "system" (as opposed to any other part of the infrastructure) -- but I'm having a hard time envisioning how this gets practically implemented, given that the functionality described by this section is going to be implemented in DNS stub resolver libraries, which tend to be pretty far removed from any user interface. Given that this is a MUST-strength requirement, I think it would be very useful to describe what this alerting might look like for (a) interactive applications like a web browser; (b) commandline utilities like curl; and (c) background tasks like software update daemons. This would provide some context for the library implementors to provide the proper hooks to enable this "MUST" to be satisfied.

Section 11.1 mentions that it will describe techniques for thwarting DNS traffic analysis, including "monitoring of resolver-to-authoritative traffic". I see that there have been measures added to prevent authoritative servers from determining the identity of the client; but given the phrasing I cite above, I was expecting a description of how to prevent eavesdroppers who can see both incoming and outgoing traffic from the recursive resolver from correlating the encrypted packets I send to that resolver with the plaintext queries it emits for non-cached results. As far as I can tell, there are no described counter-measures against such an attack (aside from hoping that volume of traffic to the resolver is too great to perform such correlation with any real precision), right? If such measures have been defined, I imagine a citation would be warranted. If not, the above phrasing should probably be qualified; e.g., "monitoring of resolver-to-authoritative traffic alone."

Nits:
draft-ietf-dprive-dnsodtls has been published as RFC 8094
The draft header indicates that this document updates RFC7858, but the abstract doesn't seem to mention this, which it should.

[Ballot discuss]
(I just updated both my DISCUSS and my comment section.)

I would like to ballot YES on this document, but I would like to discuss the following:

Sorry for being DownRef police, but RFC 7918 is clearly Normative (because there is a SHOULD level requirement), but it is listed as Informative reference. It would be a DownRef once it is made Normative, unless the procedure from RFC 8067 is used. Is RFC 7918 a suitable DownRef? Is it widely implemented?

[Ballot comment]
I am agreeing with Ekr comments. I am also agreeing on first and last Mirja's comment.

Section on future DHCP extension is a bit "hand-wavy". Is any work on this planned?

[Ballot discuss]
I would like to ballot YES on this document, but I would like to discuss the following:

Sorry for being DownRef police, but RFC 7918 is clearly Normative (because there is a SHOULD level requirement), but it is listed as Informative reference. It would be a DownRef once it is made Normative, unless the procedure in RFC 8067 is used. Is RFC 7918 a suitable DownRef?

[Ballot comment]
My main comment is on this part related to profile selection I guess:

Section 5.1 says:
"A DNS client SHOULD select a particular Usage Profile when resolving
  a query."
but then section 6.5 says:
"This information can provide a basis for a DNS
  client to switch to (preferred) Strict Privacy where it is viable.“
I assume the later sentence is supposed to mean to switch for the next query to the same resolver? Actually regarding the sentence above in section 5.1., it is also not fully clear to me why you use profiles on a per query basis? However, to me the sentence in section 6.5 does not really make sense given that Opportunistic Privacy means that I want the best privacy possible but not fail if that not available. Why would I chance this policy? I guess you mean to says something like, if authentication worked once  to a certain resolver and it is therefore known that the server supports DNS-over-(D)TLS, one could consider to switch to Strict Privacy for future requests because the likelihood that an authentication failure is an attack is high. Not sure if that's true though. However, I think that this needs a separate discussion. In general it might be worth in this document to better distinguish the case where encryption or authentication is not even offered/available for any reason and where it fails (and therefore there might or might not be an (passive) attack).


Minor comments but related:
1) "A DNS client that implements DNS-over-(D)TLS SHOULD NOT default to
  the use of clear text (no privacy)."
I'm not sure I understand this sentence. What are the implications here? Does this mean that if you have implemented DNS-over-(D)TLS, you have to use it? Not sure that this is something that can or should be specified in an RFC.

2) section 6.5:
"In this case, whilst a client
  cannot know the reason for an authentication failure, from a privacy
  standpoint the client should consider an active attack in progress
  and proceed under that assumption. "
What does this mean? Does this lead to any meaningful actions, like logging? More advise would be helpful here.

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

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

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-dprive-dtls-and-tls-profiles-08.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: tjw.ietf@gmail.com, dprive-chairs@ietf.org, draft-ietf-dprive-dtls-and-tls-profiles@ietf.org, "Tim Wicinski" , dns-privacy@ietf.org, terry.manderson@icann.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Authentication and (D)TLS Profile for DNS-over-(D)TLS) to Proposed Standard


The IESG has received a request from the DNS PRIVate Exchange WG (dprive)
to consider the following document:
- 'Authentication and (D)TLS Profile for DNS-over-(D)TLS'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-03-02. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document discusses Usage Profiles, based on one or more
  authentication mechanisms, which can be used for DNS over Transport
  Layer Security (TLS) or Datagram TLS (DTLS).  This document also
  specifies new authentication mechanisms - it describes several ways a
  DNS client can use an authentication domain name to authenticate a
  DNS server.  Additionally, it defines (D)TLS profiles for DNS clients
  and servers implementing DNS-over-(D)TLS.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dprive-dtls-and-tls-profiles/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dprive-dtls-and-tls-profiles/ballot/


No IPR declarations have been submitted directly on this I-D.

1)
Document: draft-ietf-dprive-dtls-and-tls-profiles
RFC Requested:  Proposed Standard
RFC Indicated: Yes

Document Shepherd:  Tim Wicinski
Area Director:  Terry Manderson

This is the proper type of RFC as it is documenting the authentication
profiles for the existing mechanisms for a DNS client can authenticate to
a DNS server. It defines profiles for
the two existing mechanisms - DNS-over-TLS (RFC 7858)  and
DNS-over-Datagram TLS (DTLS). RFC 7858 is standards track, and we felt
that this one should be as well - it doesn't update RFC7858, but is to closely
related that PS seemed right.

2)

Technical Summary:
  This document discusses Usage Profiles, based on one or more
  authentication mechanisms, which can be used for DNS over Transport
  Layer Security (TLS) or Datagram TLS (DTLS).  This document also
  specifies new authentication mechanisms - it describes several ways a
  DNS client can use an authentication domain name to authenticate a
  DNS server.  Additionally, it defines (D)TLS profiles for DNS clients
  and servers implementing DNS-over-(D)TLS.

Working Group Summary:
  The working group spent much time working through all the different
  authentication mechanisms, primarily making sure that the DNS-over-TLS
  and DNS-over-DTLS profiles were accurate, which were held up
  waiting for the DNS-over-DTLS draft to be moved forward.

Document Quality:

Document is of good quality.  It has been through both normative review
as well as editorial review and the shepherd feels it is worthy of
publishing.

(3) The Document Shepherd did a throughly normative review as well as a
deep editorial review.  The shepherd feels this document is of good
quality.

(4) The shepherd has no concerns about the depth or breath of the
reviews.

(5) Since the document discussed authentication profiles, there was
outreach to the TLS working group as well as the security area for
completeness.  Additionally, one of the authors is heavily involved with
the TLS working groups, so the shepherd felt this was covered.
More review is always welcome

(6)
Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

(7) The authors have confirmed there are no known IPR disclosures.

(8) No, there is No IPR disclosures

(9) The working group is solidly behind this. There was a delay in the
WGLC process, as many did not state their acceptance to the mailing list.
There was a solid acceptance during the meeting at IETF96, but the
chairs always want the mailing list to be the place for all approvals.

(10) No, there has been no appeal

(11) All nits have been found and addressed.

(12)  No formal reviews needed.
criteria, such as the MIB Doctor, media type, and URI type reviews.

(13) All references have been identified as normative and/or informative

(14) No, There are no normative references to documents that are not
ready for advancement

(15) No, There are no downward normative references references

(16) No, Publication will not change the status of any RFCs

(17) No, there are No IANA considerations

(18) No, there are No IANA registries needing updated.