Hi All, As promised some time ago, here is my review of the current probing draft. I think the draft is in good shape and have the following general comments.
1) The DNS-over-QUIC draft has now passed IESG last call so one question is whether the document should be updated to treat DoT and DoQ equally (or even just reference DoQ)? Deployment of DoQ is still in the very early stages but the WG may want to consider this change now or in the near future. 2) I wonder if some sort of diagram would go a long way to conveying the basic guidance proposed here (and enable simplifying some of the detailed text)? It seems this could actually be 2 diagrams - there is one set of logic that applies to selecting the transport to use, and a second set of processing logic when receiving responses (based on what transport gets the response and what else is queued)? I’ll share my hacky attempts at this off-list with the authors to see if they think they it adds any value but it might allow readers to quickly grasp the overall guidance and also lead to more consistent implementation? 3) The issue of signalling… I agree there is still work to do to mange this. From this reading: - from a client perspective the concept of unilateral probing is pretty clear. There is a defined behavior for direct probing, which will be different from the behavior if 'external coordination' is available. - however servers can't know for sure how the client discovered them or how/if they are authenticating the connection. This document doesn't prescribe a way to know that a server is 'only' doing unilateral deployment and/or something else, hence the potential future issues with signalling. - given this draft is Informational and is designed to enable experiments I can't remember if there has already been discussion of using an 'alternative' ALPN for this initial deployment? By that I mean, use something like 'doq-p01’(DoQ probing 01) for these kind on connections (in the same way I-D tagged ALPNs are used during protocol development)? That way each side knows explicitly how to behave and statements like "An authoritative DNS server that wants to handle unilateral queries' would have clear meaning. Whilst this is taking liberties with ALPN and may have already been dismissed as an option, it does solve a number of problems in the short term and enable negotiation and evolution. Just asking :-) 4) Would it be worth adding an additional section or appendix trying to model the likelihood of queries being encrypted for a given parameter choice vs authoritative server query interval? Assuming successful connections, it seems that for servers queried infrequently (interval is longer than the ‘persistence' parameter) their initial queries after this period will be cleartext so the choice of that parameter compared to the average query interval is quite key and likely to be the main parameter tuned? This might allow the fixed numbers given in 4.1 to be replaced by numbers relative to the average query internal for a given auth (and the resolvers desired level of encrypted connections/re-probing actions). Minor comments: Section 1.2: Have you considered using a shorthand like DoE (DNS-over-Encrypted-transport) instead of 'encrypted transport'? I think it might make the text read more clearly. Section 3.2: If discussion of possible auth mechanisms remains, then in the second bullet point referencing DANE I presume the text in parenthesis is indicating use of the DNSSEC Chain extension? If so then a reference should probably be added. Section 4.3 (and 4.5.1) Clients may also want to also track support for 0-RTT data as with DoQ servers may return a 'Too early' EDE code if they choose not to support it. Section 4.3: There might also be cases where the handshake succeeds but where every request on the connection times out. It might be worth adding additional state relating to that or changing 'completed' to be a successful connection attempt (handshake) followed by a query that didn't timeout. In Stubby we backoff off from servers where the number of timeouts on recent connections exceeds a certain threshold even when the handshakes succeed. Section 4.5: "The recursive resolver must know to decide whether to initially send a query over Do53, or over any of the supported encrypted transports (DoT or DoQ)." Reads a bit strangely to me. Can this text be clarified a little? "should use the following guidance as a basis for deciding whether to" Section 4.5.1: I believe 'T -E-completed' is the lifetime of the connection, not the idle time? If so, this is probably worth spelling out as other mechanisms e.g. edns0-tcp-keepalive are based around idle times. This is linked to the 'persistence' parameter which might be better renamed to something like e.g. ‘reuse-interval'? I'm more familiar with thinking of persistence in this context as re-using single connections for multiple queries (RFC7766) as opposed to remembering a successfully probed capability. 4.5.8.3 - As written it only applies to DoT (DoQ uses 0 for all MessageIDs). Perhaps just reference RFC7766 and the DoQ draft here? Nits: Section 4.1 s/authoritative resolver/authoritative server/ Section 4.5 s/whether the IP address X is capable of corresponding on the relevant transport/whether the IP address X is capable of communicating on the relevant transport/ Section 4.5.1. uses T, but only T0 is defined prior to that. Section 4.5.3: s/If any E-session[X] is in the established,/If any E-session[X] is in the established state,/ Section 4.5.8: s/should consider the following guidance:/should consider the guidance in the following sections./ Sections 4.5.2 and 4.5.9 are describing very similar things but do not use consistent language or ordering. Perhaps they can be aligned better? Regards Sara. > On 7 Mar 2022, at 17:54, [email protected] wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the DNS PRIVate Exchange WG of the IETF. > > Title : Unilateral Opportunistic Deployment of Encrypted > Recursive-to-Authoritative DNS > Authors : Daniel Kahn Gillmor > Joey Salazar > Filename : draft-ietf-dprive-unilateral-probing-00.txt > Pages : 23 > Date : 2022-03-07 > > Abstract: > This draft sets out steps that DNS servers (recursive resolvers and > authoritative servers) can take unilaterally (without any > coordination with other peers) to defend DNS query privacy against a > passive network monitor. The steps in this draft can be defeated by > an active attacker, but should be simpler and less risky to deploy > than more powerful defenses. The draft also introduces (but does not > try to specify) the semantics of signalling that would permit defense > against an active attacker. > > The goal of this draft is to simplify and speed deployment of > opportunistic encrypted transport in the recursive-to-authoritative > hop of the DNS ecosystem. With wider easy deployment of the > underlying transport on an opportunistic basis, we hope to facilitate > the future specification of stronger cryptographic protections > against more powerful attacks. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dprive-unilateral-probing/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-dprive-unilateral-probing-00.html > > > Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts > > > _______________________________________________ > dns-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
