DNS over Datagram Transport Layer Security (DTLS)
draft-ietf-dprive-dnsodtls-15

Note added 'This DTLS solution was considered by the DPRIVE working group as a potential option to use in case that the TLS based approach specified in RFC7858 is shown to have detrimental deployment issues.  At the time of writing, it was expected that RFC7858 will be deployed, and so this specification is primarily intended as a backup and has therefore been designated as experimental. This solution should not be deployed in the wild while in this experimental state as an RFC, however experimentation is encouraged.'

[Ballot comment]
Update: Looks like the address for Dan Wing needs to be updated.

-1: Is TCP head of line blocking considered a problem between the client and cacheing resolver? Otherwise, between that and the potential to use TCP fast open, the motivation for not just using TLS seems weak (which may not be a problem for an experimental RFC.)

- 3.1: "DNS clients and servers MUST NOT use port 853 to transport cleartext
  DNS messages. "
Am I correct to assume that this requirement is really about clients and servers that do not implement this spec? While I see the point, how would such a client or server even know about the restriction?

[Ballot comment]
-1: Is TCP head of line blocking considered a problem between the client and cacheing resolver? Otherwise, between that and the potential to use TCP fast open, the motivation for not just using TLS seems weak (which may not be a problem for an experimental RFC.)

- 3.1: "DNS clients and servers MUST NOT use port 853 to transport cleartext
  DNS messages. "
Am I correct to assume that this requirement is really about clients and servers that do not implement this spec? While I see the point, how would such a client or server even know about the restriction?

[Ballot discuss]


I have two discuss points to chat about before I ballot
yes for this:

(1) I think it'd be good to make the nature of this RFC
clear in the document, so that folks don't get confused and
implement this now, when we think they ought be using TLS
for stub to recursive privacy. I'd suggest maybe adding a
note here (possibly an IESG note, or just more text before
1.1, whatever), that says something like: "This DTLS
solution was considered by the DPRIVE working group as an
option to use in case the TLS based approach specified in
RFC7858 turns out to have some issues when deployed.  At
the time of writing, it is expected that RFC7858 is what
will be deployed, and so this specification is mainly
intended as a backup." Note that while text like that may
also end up in the profiles document, I still think it may
be useful here as well.

(2) Section 4: No mention of OCSP stapling? And come to
think of it, how would non-stapled OCSP even work? And
since I've now thought of it, how will OCSP work with
RFC7858? Does this (and 7858) need to mandate stapling or
no revocation checking via OCSP at all?  (Apologies for not
asking about that when we were processing 7858;-)

[Ballot comment]


- 3.3: What does "of the order of several seconds" mean?
If you mean O(10s) then why not say that?

- 3.3: Is figure 1 really needed? There's no longer any
meaningful reference to it from the text. (I forget if
there once was.)

- To try answer Benoit's comment: I think that this is a part
of the overall DPRIVE experiment, so it's a little hard to
say exactly how this document alone constitutes a useful
experiment. But see also my discuss point#1.

[Ballot comment]
Under which conditions do we know that this experiment will be successful?
Anything worth nothing?
As an example of a similar RFC, see https://tools.ietf.org/html/rfc7360#section-1.3

[Ballot comment]
Regarding the shepherd write-up: There is no requirement for an implementation section. There is a recommendation to have one, to track implementations efforts during the draft's live-time, but such a section is usually removed on publication as RFC as this information easily out-dates. There is another recommendation to have a section explaining the goals and/or next steps after the end of a (successful) experiment. I personally don't think this is required here, given that I understand the experiment is to figure out if this will be adopted (given there is stable reference).

One small question on the text in the draft:
"For the client, state should be destroyed when
  disconnecting from the network (e.g., associated IP interface is
  brought down). "
Does this mean all state including state used for session resumption?

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

The IANA Services Operator has reviewed draft-ietf-dprive-dnsodtls-12.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, draft-ietf-dprive-dnsodtls@ietf.org, dprive-chairs@ietf.org, dns-privacy@ietf.org, "Tim Wicinski" , terry.manderson@icann.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Specification for DNS over Datagram Transport Layer Security (DTLS)) to Experimental RFC


The IESG has received a request from the DNS PRIVate Exchange WG (dprive)
to consider the following document:
- 'Specification for DNS over Datagram Transport Layer Security (DTLS)'
  as Experimental RFC

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 2016-11-16. 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


  DNS queries and responses are visible to network elements on the path
  between the DNS client and its server.  These queries and responses
  can contain privacy-sensitive information which is valuable to
  protect.

  This document proposes the use of Datagram Transport Layer Security
  (DTLS) for DNS, to protect against passive listeners and certain
  active attacks.  As latency is critical for DNS, this proposal also
  discusses mechanisms to reduce DTLS round trips and reduce DTLS
  handshake size.  The proposed mechanism runs over port 853.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsodtls/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsodtls/ballot/


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

1. Summary

Document Shepherd:  Tim Wicinski
Area Director:      Terry Manderson

Document Type:      Experimental

This document proposes the use of Datagram Transport Layer Security
(DTLS) for DNS, to protect against passive listeners and certain
active attacks.  As latency is critical for DNS, this proposal also
discusses mechanisms to reduce DTLS round trips and reduce DTLS
handshake size.

The working group chose Experimental over Proposed Standard because
the authors have indicated they are not willing to attempt
implemntating this, nor have they attempted to find anyone to
implement this.

While the working group confirmed publication, this document
shepherd (and working group co-chair) is conflicted.  The lack of
implementation anytime in the near future means this will get
published but never actually used. While the working group does not
see this as a problem, I feel it sets a bad precedent.

2. Review and Consensus

The document was reviewed very heavily by the working group, and c
compared to the previous document DNS-over TLS
    https://datatracker.ietf.org/doc/rfc7858/

The working group made several requests which the authors performed.
The biggest one was the removal of the Authenication profiles and
placed in a separate document  draft-ietf-dprive-dtls-and-tls-
profiles  which is currently working through the working group and
is slated for last call.

The consensus was positive on adopting and publishing this draft,
and the working group did not have many comments about the lack of

3. Intellectual Property

The authors stated that their direct, personal knowledge of any IPR
related to this document has already been disclosed.

4. Other Points

There are no downward references in this document.

Currently, the document lists ietf-dprive-dtls-and-tls-profiles as
an Informative Reference, but lists it as a MUST in section 3.2.
Because of this, the shepherd feels this could be listed as a
normative reference, though the document is Experimental.

There is currently no Implementation Section, as needed for
Experimental drafts.  The authors have stated they will not attempt
any implementations.

IANA Considerations:
    There are no IANA Considerations

Checklist:

- Does the shepherd stand behind the document and think the document
is ready for publication?

X - Is the correct RFC type indicated in the title page header?

X - Is the abstract both brief and sufficient, and does it stand
alone as a brief summary?

X - Is the intent of the document accurately and adequately
explained in the introduction?

X - Have all required formal reviews (MIB Doctor, Media Type, URI,
etc.) been requested and/or completed?

X - Has the shepherd performed automated checks -- idnits

X - Has each author stated that their direct, personal knowledge of
any IPR related to this document has already been disclosed, in
conformance with BCPs 78 and 79?

X - Have all references within this document been identified as
either normative or informative, and does the shepherd agree with
how they have been classified?

X - Are all normative references made to documents that are ready
for advancement and are otherwise in a clear state?

X - If publication of this document changes the status of any
existing RFCs, are those RFCs listed on the title page header, and
are the changes listed in the abstract and discussed (explained, not
just mentioned) in the introduction?

X - If this is a "bis" document, have all of the errata been
considered?