> On 5 Aug 2016, at 03:47, Tirumaleswar Reddy (tireddy) <tire...@cisco.com> > wrote: > > Hi Sara, > > Thanks for the review. Please see inline
Hi Tiru, Thanks for the detailed response. >> >> With regard to the separate https://tools.ietf.org/html/draft-wing-dprive- >> profile-and-msg-flows-01 I’ll re-iterate my question from the Yokohama WG: >> Is there anything DNS specific in the draft? I don’t recall anything >> particularly >> DNS specific. I definitely see value in a draft comparing message flows >> between TLS and DTLS in general, but my feeling is it might be better >> progressed though another working group with more (D)TLS experts - TLS or >> UTA ? > > I don't think other WG will care enough for this draft, maybe the chairs can > request reviewers from the above WG’s. I’d be interested to know what others think about this. > >> then also drop >> the suggested acronym "(DNSoD, pronounced "dee-eon-sod”)”. In draft-ietf- >> dprive-dtls-and-tls-profiles we use DNS-over-(D)TLS throughout so calling >> this >> mechanism simply DNS-over-DTLS feels more consistent. > > The acronym was added as it sounded easy to pronounce. I haven’t ever heard that acronym used - I’ve only heard people talk about DNS-over-DTLS :-) If the acronym is retained then I think in a pass is needed though the document to improve consistency because at the moment both DNSoD and DNS-over-DTLS are used in different sections to (I think) mean the same thing. >> 1. Introduction: >> >> - Second bullet point, last paragraph: I think it is currently correct that >> TCP >> Fast open is not yet ubiquitous but given the recent significant deployment >> efforts I’m not sure that will remain true for long. Also, TFO is now >> available >> on Windows, Linux, OS X and (server side) FreeBSD. > > Removed the second line in the last paragraph. I think the reference to TFO is still relevant and shouldn’t be completely removed, how about something like: “ DTLS session resumption consumes 1 round trip whereas TLS session resumption can start only after TCP handshake is complete. However TCP Fast Open [ RFC7413] can eliminate 1-RTT in the latter case. “ >> >> - I’d also like to see some statement about how many concurrent DTLS >> sessions a client should establish to a particular DNS Server (just one?). > > Yes, one DTLS session is sufficient. Its already discussed in Section 3.3 > <snip>To reduce client and server workload, clients SHOULD re-use the DTLS > session. A single DTLS session can be used to send multiple DNS requests and > receive multiple DNS responses.</snip> But this doesn’t explicitly say a client SHOULD only use one session. How about considering adding a section based on 6.2.2 of RFC7766 (https://tools.ietf.org/html/rfc7766#section-6.2.2) to cover this? >> 3.3 Established Sessions >> >> - Is there anything additional here that can be said about expected session >> lifetimes or idle timeouts? Is it expected that clients keep session open >> indefinitely until some sort of error is encountered or can some sort of >> reasonable idle timeout be suggested? Is there any expectation about whether >> the client or server typically terminates a session? > > Yes, updated draft. > NEW: > In between normal DNS traffic while the communication to the DNS server is > quiescent, You could re-use/reference the definition of an idle DNS-over-TCP session as defined in RFC7766 here for clarity and consistency? > the DNS client may want to probe the server to ensure it has maintained > cryptographic state. Such probes can also keep alive firewall or NAT > bindings. This probing reduces the frequency of needing a new handshake when > a DNS query needs to be resolved, improving the user experience at the cost > of bandwidth and processing time. I’m not clear what kind of ‘probing’ you are suggesting here? A dummy DNS message or some sort of keepalive mechanism - can you expand please? >> -- Question: What does a server do if the client doesn’t send an EDNS0 >> option? > > The maximum DNS response size of 512 bytes plus DTLS overhead will be well > within the Path MTU. Sorry - I meant that adding a sentence on this to the draft might be helpful to remove ambiguity. >> -- I do think there is a DTLS Usage Profile specific point to make related >> to this, >> which is that if a client gets a truncated answer over DTLS it could choose >> to >> fallback to UDP/TCP instead of TLS _if_ it were using an Opportunistic >> profile >> which would result in a kind of ‘hybrid’ security. > > In Opportunistic profile, if server sends truncated response then > DNS client should first try TLS and if the TLS handshake fails then fallback > to TCP. > >> I don’t really see any >> advantage in that if TLS is available, but the last sentence is unclear on >> this >> possibility, suggesting only TLS can be used - which is correct for Strict >> Privacy >> but perhaps not (at least technically) for Opportunistic. This feel worthy of >> some discussion. > > Added following line: > If DNS-over-TLS connection fails and the client is using Opportunistic > Privacy profile then the client can fallback to DNS-over-TCP. On re-reading this and the profiles draft (draft-ietf-dprive-dtls-and-tls-profiles), this seems rather specific. I’m leaning towards keeping the discussion protocol neutral, as we did in the profiles draft... but I’d like to see some more feedback on this... There is, of course, a small subset of DNS responses that are too large to be sent using DTLS, but could be send plain text over UDP given the same MTU. The TC bit in this scenario simply signals to the client that the response is too large for DTLS, but of course this signalling can’t convey any more detailed information. Again, it is a bit of a corner case but a question in my mind is how detailed this draft should be in specifying the fallback mechanisms? One approach would be something like: “Upon receiving a response with the TC bit set and wanting to receive the entire response, the client behaviour is governed by the current Usage profile [draft-ietf-dprive-dtls-and-tls-profiles]. For Strict Privacy the client MUST only send a new DNS request for the same resource record over an encrypted transport (e.g. DNS-over-TLS [RFC7858]). Clients using Opportunistic Privacy SHOULD try for the best case (an encrypted and authenticated transport) but MAY fallback to intermediate cases and eventually the worst case scenario (clear text) in order to obtain a response” This is then almost identical to the text in section 4.2 of the profiles draft but allows clients flexibility. > DNS client can setup both DNSoD and DNS-over-TLS connections in parallel, to > reduce the latency to send DNS queries over DNS-over-TLS if the DNS response > is truncated over the DNSoD and the client needs the entire response. Ah, ‘parallel connections’ is a new idea and warrants discussion. It also seems to be spilling over into the area of preference between the protocols, which I think I would argue is out of scope for this document. Additionally it occurs to me that using DNS-over-DTLS and then just using ‘one-shot’ TLS for truncated messages is really paying a price (more so than falling back to TCP from UDP). So perhaps it makes more sense to use the above rather neutral text and defer this discussion to another document that can include implementation and deployment experience? > >> - “For servers with no connection history…” I think this sentence can also be >> removed since it is more fully covered in the draft-ietf-dprive-dtls-and-tls- >> profiles draft. > > I don’t think it's discussed in profile draft, please check. I read this as just another description of selecting behaviour depending on the Usage Profile (called I think Privacy Profile here) where b) is Opportunistic and c) is Strict. I don’t think is says anything new above that unless I have mis-read or misunderstood? > >> >> - “Once a DNSoD client has established >> a security association with a particular DNS server, and outstanding >> normal DNS queries with that server (if any) have been received, the >> DNSoD client MUST ignore any subsequent normal DNS responses from >> that server, as all subsequent responses should be encrypted.” >> I think this text is a hangover from the earlier draft when port 53 was >> used. > > No, the above line explains that if the DNS client is using DNSoD it must not > accept plain text DNS responses arriving on any port. > Added more details to clarify. Can you send the updated text please - a few more thoughts occur to me here but perhaps they are addressed in the new text? Sara.
_______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
