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

[Stephen Farrell <[e-mail]>]

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.

> 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.

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?

Cheers,
S.

PS: The rest below is fine too:-)

> 
> 
> 
>> 
>> 
>> ----------------------------------------------------------------------
>>
>> 
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