Hi, Just a couple of comments inline.
On Mon, May 8, 2017 at 8:01 AM, Eric Rescorla <[email protected]> wrote: > > > 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. > The draft already says TLS 1.2 or higher, so you do already allow for TLS 1.3. You could put an informative reference as TLS 1.3 being an option. TLS 1.2 hasn't been deprecated and the guidance with 7525 is there already to prevent known problems. An informative reference shouldn't hold up this draft, but it's up to the WG if they want to include it explicitly IMO. > >> >> 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. I agree with EKR. The recommendation to follow 7525 is enough. > > -Ekr > -- Best regards, Kathleen _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
