On Mon, May 8, 2017 at 1:21 AM, Sara Dickinson <[email protected]> wrote:
> > On 6 May 2017, at 21:31, Eric Rescorla <[email protected]> wrote: > > Eric Rescorla has entered the following ballot position for > draft-ietf-dprive-dtls-and-tls-profiles-09: Discuss > > > Many thanks for the review. > > ---------------------------------------------------------------------- > 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. > > > Agreed. > > ---------------------------------------------------------------------- > 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... Table 1 seems to have N and D paired, so maybe you can coalesce them? > > > That specific question was asked on the WG mailing list and the answer was > ‘no, please keep both’: > https://www.ietf.org/mail-archive/web/dns-privacy/current/msg01541.html > OK. Perhaps add some text that theya re paired 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. > > > 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. > 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 > > > Ack. > > > > 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. > > > How about moving the justification later in the section: > > “ Clients and servers MUST adhere to the (D)TLS implementation > recommendations and security considerations of [RFC7525] except with > respect to (D)TLS version. > > Since encryption of DNS using (D)TLS is a green-field deployment DNS > clients and servers MUST implement only (D)TLS 1.2 or later. > > 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. If there are things that you think people ought to do other than those in 7525, you ought to say them. -Ekr
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
