Subject: [dns-privacy] Adam Roach's No Objection on draft-ietf-dprive-dtls-and-tls-profiles-09: (with COMMENT)

From: Adam Roach <[email-masked]>
Date: Tue, 09 May 2017 16:28:03 -0700

Adam Roach has entered the following ballot position for
draft-ietf-dprive-dtls-and-tls-profiles-09: No Objection

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/

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

---

From: Sara Dickinson <[email-masked]>
Date: Thu, 11 May 2017 13:10:04 +0100

> On 10 May 2017, at 00:28, Adam Roach <[email-masked]> wrote:

This paragraph was actually lifted almost directly from section 4.2 of RFC7858, which says
"The user MUST be alerted whenever possible that the DNS is not private during such bootstrap.” 

In the working group there was push back against attempting to specify any further level of detail with the feeling that that was out of scope for this draft to attempt UI design. However if there are now specific ideas on how to do this then we should consider including them. 

> is too great to perform such correlation with any real precision), right?

The EDNS0 Padding option (RFC7830) described in the first bullet point here is the only counter measure available to defeat monitoring traffic either side of the recursive by hiding the encrypted message size. 

Actually there has been further work on padding recently in https://datatracker.ietf.org/doc/draft-ietf-dprive-padding-policy/ <https://datatracker.ietf.org/doc/draft-ietf-dprive-padding-policy/> and also research by dkg (https://datatracker.ietf.org/doc/draft-ietf-dprive-padding-policy/ <https://datatracker.ietf.org/doc/draft-ietf-dprive-padding-policy/>) which is planned to be incorporated into the padding policy draft. 

So it certainly seems correct to add a reference to the padding policy draft here. 

> draft-ietf-dprive-dnsodtls has been published as RFC 8094

Yup - will update. 

> abstract doesn't seem to mention this, which it should.

It should - I will add that. 

Sara.