Hi Sara-- Thanks for this thoughtful and detailed review! I'm trying to do it justice, but i haven't gotten through it all yet. It's triggered a bunch of changes in the editor's copy, but I've also focused on the easy stuff first because i'm lazy :P
If anyone wants to offer concrete suggestions for textual changes for the parts i haven't yet addressed, i'd welcome those suggestions! Notes below, inline, for things that i haven't tackled yet: On Thu 2022-04-07 16:47:02 +0100, Sara Dickinson wrote: > 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)? This is a great idea. Thanks for sharing your flowchart sketch, Sara! I think a flowchart typically represents a branching-yet-linear workflow, where the choice points and observations are all initiated by the primary actor. In this case, we have a lot of events that can happen asynchronously from outside the primary actor, so a flowchart kind of struggles to represent it. i've spent the last day puzzling this over, and of the ideas i've stumbled onto, the one i like the most is a state transition diagram for a single <client IP, server IP> tuple given one encrypted transport and Do53. It'd be more accurate to cover state of *both* encrypted transports for the <client IP, server IP> tuple (that is, to observe the subtle interactions between multiple encrypted transports and Do53), but that diagram seems like it might be more complicated and less clarifying. Any suggestions for a better kind of visualization? I've opened https://gitlab.com/dkg/dprive-unilateral-probing/-/issues/20 to track this. > 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 :-) This is an interesting question: the proposal to play games with ALPN hasn't yet been raised to my knowledge. Due to ALPN's transport in the clear for a normal TLS handshake, i'd be reluctant to endorse that use here. I don't think we want a network observer to know which encrypted transports are opportunistic and which are due to signalled information. I'm also trying to get my head around what such an indicator would be useful for. Presumably the authoritative server would behave differently based on that indicator, but i'm having a hard time imagining what the authoritative server should do differently. Is it just for statistics/accounting? Can you explain what you think the purpose of such an indicator would be? As a related side note, in the editor's copy i've touched briefly on the "reporting" aspects that would be useful for an operator deciding whether to signal: https://dkg.gitlab.io/dprive-unilateral-probing/#name-signalling-mechanism-proper Maybe the need for such an indicator would depend on the semantics and syntax of the signal that is ultimately selected? if so, perhaps that additional indicator belongs in whatever future signalling work we do, rather than in this document > 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). I welcome proposed text for an appendix like this. Some things that such a section would probably want to cover: - specific statistics that an implementation might want to aggregate for reporting - strategies for prefetching/etc that would increase the percentage of opportunistically-encrypted traffic I've opened https://gitlab.com/dkg/dprive-unilateral-probing/-/issues/21 to track this. > 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. I think this would make it sound like "DoE" is a specific protocol. And it makes it harder to talk about "one of the encrypted transports" or "a different encrypted transport" ("one of the DoEs" or "a different DoE" both seem weird to me). I don't personally mind "encrypted transport" much, but i'm open to suggestions for other terms for describing the concept without . > 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. These are really useful suggestions that i haven't dealt with yet. I've noted them as: https://gitlab.com/dkg/dprive-unilateral-probing/-/issues/18 > 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. I don't think the described measurement is the connection lifetime: if the connection is still in the established state, then we don't even look at that metric. But if the connection was closed cleanly by either side, we're measuring back to the start of the connection, rather than the last time the connection was successfully initiated, rather than the last time it was successfully used. I think the right way to fix this is to try to record the last successful use. Maybe we should change the definition of `E-completed` to be last successful use, and tweak "Receiving a response over encrypted transport" to update it. I've recorded this as an outstanding concern at: https://gitlab.com/dkg/dprive-unilateral-probing/-/issues/19 > 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? I haven't gotten to this, but i noted it as: https://gitlab.com/dkg/dprive-unilateral-probing/-/issues/17 Thanks again for the review, this is really useful! --dkg
signature.asc
Description: PGP signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
