Re: [dns-privacy] Stephen Farrell's Discuss on draft-ietf-dprive-dnsodtls-13: (with DISCUSS and COMMENT)

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

> -----Original Message-----
> From: Stephen Farrell [mailto:[e-mail]]
> Sent: Wednesday, December 14, 2016 1:13 PM
> To: Tirumaleswar Reddy (tireddy) <[e-mail]>; The IESG
> <[e-mail]>
> Cc: [e-mail]; [e-mail]; draft-ietf-dprive-
> [e-mail]; [e-mail]
> Subject: Re: [dns-privacy] Stephen Farrell's Discuss on draft-ietf-dprive-
> dnsodtls-13: (with DISCUSS and COMMENT)
> 
> 
> Hiya,
> 
> I think we're nearly set here - just two real points below
> and a couple of nits...
> 
> On 14/12/16 05:59, Tirumaleswar Reddy (tireddy) wrote:
> > Hi Stephen,
> >
> > Thanks for the review. Please see inline
> >
> >> -----Original Message----- From: dns-privacy
> >> [mailto:[e-mail]] On Behalf Of Stephen Farrell
> >> Sent: Tuesday, December 13, 2016 6:33 PM To: The IESG
> >> <[e-mail]> Cc: [e-mail]; [e-mail];
> >> draft-ietf-dprive- [e-mail]; [e-mail]
> >> Subject: [dns-privacy] Stephen Farrell's Discuss on
> >> draft-ietf-dprive-dnsodtls- 13: (with DISCUSS and COMMENT)
> >>
> >> Stephen Farrell has entered the following ballot position for
> >> draft-ietf-dprive-dnsodtls-13: Discuss
> >>
> >> When responding, please keep the subject line intact and reply to
> >> all email addresses included in the To and CC lines. (Feel free to
> >> cut this introductory paragraph, however.)
> >>
> >>
> >> Please refer to
> >> https://www.ietf.org/iesg/statement/discuss-criteria.html for more
> >> information about IESG DISCUSS and COMMENT positions.
> >>
> >>
> >> The document, along with other ballot positions, can be found
> >> here: https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsodtls/
> >>
> >>
> >>
> >> ----------------------------------------------------------------------
> >>
> >>
> DISCUSS:
> >> ----------------------------------------------------------------------
> >>
> >>
> >>
> >>
> >>
> I have two discuss points to chat about before I ballot yes for this:
> >>
> >> (1) I think it'd be good to make the nature of this RFC clear in
> >> the document, so that folks don't get confused and implement this
> >> now, when we think they ought be using TLS for stub to recursive
> >> privacy. I'd suggest maybe adding a note here (possibly an IESG
> >> note, or just more text before 1.1, whatever), that says something
> >> like: "This DTLS solution was considered by the DPRIVE working
> >> group as an option to use in case the TLS based approach specified
> >> in RFC7858 turns out to have some issues when deployed.  At the
> >> time of writing, it is expected that RFC7858 is what will be
> >> deployed, and so this specification is mainly intended as a
> >> backup." Note that while text like that may also end up in the
> >> profiles document, I still think it may be useful here as well.
> >
> > Yes, will add the above text to a new Section (named "Document
> > Status")
> 
> Great.
> 
> > and also to add the following additional text to this
> > section (to address the comment from Beniot):
> >
> > The following guidelines should be considered when deploying and
> > performance benchmarking DNS over DTLS:
> >
> > 1)DNS over DTLS should not be deployed standalone without DNS over
> > TLS. When DNS over DTLS is used and the DNS server's response exceeds
> > the EDNS0 value, the DNS server sets the TC (truncated) bit.  On
> > receiving a response with the TC bit set, the DNS client based on the
> > current usage profile [I-D.ietf-dprive-dtls-and-tls-profiles] may
> > fallback to DNS over TCP.
> 
> I thought that was already stated clearly enough, but no
> harm re-iterating it I guess.
> 
> >
> > 2) DNS over DTLS performance in comparison with DNS over TLS may be
> > better in lossy networks. DNS over DTLS can recover from packet loss
> > and reordering, and does not suffer from network head-of-line
> > blocking.
> >
> > 3) The number of round trips to send the first DNS query over DNS
> > over DTLS is less than the number of round trips to send the first
> > DNS query over TLS. If TCP Fast Open is used, it only works for
> > subsequent TCP connections between the DNS client and server (Section
> > 3 in RFC7413).
> >
> > 4) If DTLS 1.3 protocol [I-D.rescorla-tls-dtls13] is used for DNS
> > over DTLS, it provides critical latency improvements for connection
> > establishment over DTLS 1.2. If DNS servers are configured with
> > anycast addresses, and when the network configuration or routing
> > changes, a DNS-over-DTLS packet can be received by a server that does
> > not have the necessary cryptographic context. In this case, the DNS
> > client can use 0-RTT mode in which the DOTS client can send DNS
> 
> DOTS? Typo I guess.

Yes, will fix.

> 
> > request on its first flight, thus reducing handshake latency. However
> > with DNS over TLS, the DNS client will have to first establish a TCP
> > connection with the server and then use 0-RTT mode.
> 
> But 0RTT is replayable, which iirc is particularly dangerous
> for foo/DTLS/UDP with anycast and if the attacker can see
> the upstream queries from an anycast instance with an empty
> cachce at which the attacker has targetted a replayed query.
> So the text in (4) needs a bit of work I think. (Though it's
> possible I'm remembering this stuff badly;-)
> 
> >
> >>
> >> (2) Section 4: No mention of OCSP stapling? And come to think of
> >> it, how would non-stapled OCSP even work? And since I've now
> >> thought of it, how will OCSP work with RFC7858? Does this (and
> >> 7858) need to mandate stapling or no revocation checking via OCSP
> >> at all?  (Apologies for not asking about that when we were
> >> processing 7858;-)
> >
> > I think the right place to discuss this would be in
> > ietf-dprive-dtls-and-tls-profiles-07#section-8.1, it discusses both
> > PKIX Certificate and DANE based Authentication.
> 
> Maaaaybe. Be good to cover it there certainly but not sure
> if that's sufficient.
> 
> >
> > With regard to public key certificates, the certificate revocation
> > guidelines to use OSCP stapling discussed in
> > https://tools.ietf.org/html/rfc7525#section-6.5 should be followed by
> > the DNS client and server. Both this draft and RFC7858 already refer
> > to RFC7525 for secure use of (D)TLS.
> 
> The issue here is whether DPRIVE works with plain OCSP at all.
> 
> If one wants to send the query for the A/AAAA of the OCSP
> responder over (D)TLS there seems to be a bootstrapping issue
> that's at least tricky.
> 
> If one sends that DNS query in clear that leaks a little info
> (the name of the responder of the (D)TLS server cert of the
> recursive) and then later (in OCSP) one leaks the identity of
> the actual (D)TLS server, which is also not that big a deal
> except that having to send a cleartext DNS query for that
> seems to be sufficiently unexpected that it ought be documented.
> 
> Seems to me that OCSP stapling might be near mandatory for
> both 7858 and this unless we want to take the "hit" of the
> cleartext DNS query for the OCSP responder.

Agreed. I can add the following lines to Security considerations section:

The DNS client MUST use the TLS Certificate Status Request extension (Section 8 of [RFC6066]), commonly called "OCSP stapling" to check the revocation status of public key certificate of the DNS server. OCSP stapling, unlike OSCP, does not suffer from scale and privacy issues.

> Last point: I'm not sure how OCSP stapling affects packet
> sizes for this spec and whether it'd cause a possible fall
> back to TCP or not. Worth checking maybe?

I don't see a problem, DTLS handshake is capable of handling fragmentation and reassembly (see https://tools.ietf.org/html/rfc6347#section-4.2.3).

> 
> Cheers,
> S.
> 
> PS: The rest below is fine too:-)

Thanks, will update draft.

Cheers,
-Tiru

> 
> >
> >
> >
> >>
> >>
> >> ----------------------------------------------------------------------
> >>
> >>
> COMMENT:
> >> ----------------------------------------------------------------------
> >>
> >>
> >>
> >>
> >>
> - 3.3: What does "of the order of several seconds" mean?
> >> If you mean O(10s) then why not say that?
> >
> > NEW: For the server, to mitigate the risk of unintentional server
> > overload, it is RECOMMENDED that the default DNS-over-DTLS server
> > application-level idle time out be set to several seconds and not set
> > to less than a second, but no particular value is specified.
> >
> >>
> >> - 3.3: Is figure 1 really needed? There's no longer any meaningful
> >> reference to it from the text. (I forget if there once was.)
> >
> > I don't think the figure is required, will remove it.
> >
> > -Tiru
> >
> >>
> >> - To try answer Benoit's comment: I think that this is a part of
> >> the overall DPRIVE experiment, so it's a little hard to say exactly
> >> how this document alone constitutes a useful experiment. But see
> >> also my discuss point#1.
> >>
> >>
> >> _______________________________________________ dns-privacy
> mailing
> >> list [e-mail]
> >> https://www.ietf.org/mailman/listinfo/dns-privacy