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

[Sara Dickinson <[e-mail]>]

Hi Ekr (and Kathleen),

> On 8 May 2017, at 13:01, Eric Rescorla <[e-mail]> wrote:
>> ----------------------------------------------------------------------
>> 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.
> 
> No, we mean they could be done either via Opportunistic lookups or DHCP (see table 2.)
> The meta queries contain no information about what DNS lookups the client is doing other than what DNS Privacy server they are going to use to do their queries. But you are correct that the ‘strong privacy guarentees’ apply only to the subsequent queries to the Privacy server and the text should be updated to clarify that.  
> 
> Well, per my previous comment, I think you need to focus on the entire strategy.
> 
> I.e., if you determine whether to adopt a Strict policy based on Opportunistic queries, then you are back to the active attack setting. I don't have a problem with your design here, which seems to be about as good as one can do; I'm just trying to make sure the description is accurate...

Oh, I think I see your point now:

- Strict without meta queries to an untrusted source (i.e. name and IP both configured or obtained from a ’trusted’ source) will connect directly to the correct the Privacy server
- Strict with meta queries to an untrusted source provides the opportunity for the attacker to return incorrect answers, directing the client to a bogus Privacy server which the client will not be able to authenticate and therefore the client will not proceed to perform queries. 

so the two approaches are different in terms of mitigating attacks. 

Even if the meta queries were secured with DNSSEC (as they were until a recent version of the draft) this doesn’t help because if the answers are bogus then again, the client won’t continue. 

> 
>> 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).
> 
> We purposely avoided adding any details on the SPKI mechanisms in this document because this document simply refers to RFC7585 which then directly references RFC7469. But if you think this is needed here also then I’ll add it.
> 
> The concern I have is that this guidance seems to implicitly contradict the guidance from 7469. So I think you should either just say that if you have both you treat it like a 7469 pin, or say something like "successful, with the possible exception of certificates which chain to local trust anchors, as described in..." Or, alternately really prohibit this. Also, should -> SHOULD.

Got it. I think I would lean towards "if you have both you treat it like a 7469 pin” but would like to hear other views on this. 

>> 
>> EDITORIAL
>> Do you want to cite TLS 1.3 at this point?
> 
> Early on we chose not to include a normative reference to the TLS 1.3 draft to avoid the dependancy on that becoming an RFC but are you suggesting we do that now or just include an informative reference?
> 
> I would think at least an informative reference would be useful.
> 
> 
> Do you think Section 9 the right place to talk about TLS 1.3 in general or do you feel there are specific points to made elsewhere in the text? 
> 
> 1.3 has pretty much the same properties here, so I think you might just cite 1.3 and make it informative. I'm not sure what the right actual mechanics are here, but surely such a thing is possible.

An informative reference makes total sense - I’ll add that. 

> 
>   These requirements ensure mitigation against 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.”
> 
> My complaint is that this seems kinda FUDdy.

OK - I’ll remove. 

Sara.