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

[Sara Dickinson <[e-mail]>]

> On 10 May 2017, at 00:28, Adam Roach <[e-mail]> wrote:
> ----------------------------------------------------------------------
> 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.

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. 

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

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. 

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

Yup - will update. 

> The draft header indicates that this document updates RFC7858, but the
> abstract doesn't seem to mention this, which it should.

It should - I will add that. 

Sara.