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

From: "Stephen Farrell" <[email-masked]>
Date: Tue, 13 Dec 2016 05:03:16 -0800

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.

(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;-)

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- 3.3: What does "of the order of several seconds" mean?
If you mean O(10s) then why not say that? 

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

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

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 14 Dec 2016 05:59:50 +0000

Hi Stephen,

Thanks for the review. Please see inline

> -----Original Message-----
> From: dns-privacy [mailto:[email-masked]] On Behalf Of
> Stephen Farrell
> Sent: Tuesday, December 13, 2016 6:33 PM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; draft-ietf-dprive-
> [email-masked]; [email-masked]
> Subject: [dns-privacy] Stephen Farrell's Discuss on draft-ietf-dprive-dnsodtls-
> 13: (with DISCUSS and COMMENT)
> 
> 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.)
> 
> 
> 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") 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.

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

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

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. 

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 14 Dec 2016 07:43:28 +0000

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:
>> -----Original Message----- From: dns-privacy
>> [mailto:[email-masked]] On Behalf Of Stephen Farrell 
>> Sent: Tuesday, December 13, 2016 6:33 PM To: The IESG
>> <[email-masked]> Cc: [email-masked]; [email-masked];
>> draft-ietf-dprive- [email-masked]; [email-masked] 
>> Subject: [dns-privacy] Stephen Farrell's Discuss on
>> draft-ietf-dprive-dnsodtls- 13: (with DISCUSS and COMMENT)
>> 
>> 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/
>> 
>> 
>> 
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):
> 
> 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:-)

> 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.)
> 
>> - 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 [email-masked]

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 14 Dec 2016 11:05:18 +0100

On Wed, Dec 14, 2016 at 07:43:28AM +0000,
 Stephen Farrell <[email-masked]> wrote 

> > Yes, will add the above text to a new Section (named "Document

I think it is not really necessary, the status Experimental of
draft-ietf-dprive-dnsodtls-13 seemed enough to me.

> > > (2) Section 4: No mention of OCSP stapling?

> > ietf-dprive-dtls-and-tls-profiles-07#section-8.1,

I fully agree with this opinion.

> Maaaaybe. Be good to cover it there certainly but not sure if that's
> sufficient.

What is missing? draft-ietf-dprive-dtls-and-tls-profiles-07 rightly
avoids to reinvent the wheel and refers to RFC 5280 and RFC 6125. I
don't think it is up to the DPRIVE working group to improve/change
PKIX.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 14 Dec 2016 13:50:58 +0000

> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Wednesday, December 14, 2016 1:13 PM
> To: Tirumaleswar Reddy (tireddy) <[email-masked]>; The IESG
> <[email-masked]>
> Subject: Re: [dns-privacy] Stephen Farrell's Discuss on draft-ietf-dprive-
> dnsodtls-13: (with DISCUSS and COMMENT)
> 
> 
> Hiya,
> 

Yes, will fix.

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

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

> PS: The rest below is fine too:-)

Thanks, will update draft.

Cheers,
-Tiru

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 14 Dec 2016 15:00:11 +0100

On Wed, Dec 14, 2016 at 01:50:58PM +0000,
 Tirumaleswar Reddy (tireddy) <[email-masked]> wrote 
 a message of 238 lines which said:

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

I'm not happy.

1) This is not specific to DTLS and it should not be in a
DTLS-specific document.

2) We use TLS/DTLS for encrypting DNS precisely to save us reinventing
a security protocol. If we start to override TLS rules, we get into
dangerous waters.

Mentioning the scale/privacy issues of OCSP is OK, but a MUST???

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 14 Dec 2016 14:00:48 +0000

On 14/12/16 13:50, Tirumaleswar Reddy (tireddy) wrote:
> I don't see a problem, DTLS handshake is capable of handling
> fragmentation and reassembly

Of course it is, silly of me to forget:-)

I think we're sorted now, assuming that the wg are ok
with the suggested changes, (I am).

S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 14 Dec 2016 14:05:54 +0000

Our mails overlapped and contradicted one another:-)

Might be better to let chair/shepherd figure out next
step?

In the meantime though one thing below.

> 1) This is not specific to DTLS and it should not be in a

True that this isn't specific to DTLS. I don't agree that
means this mustn't be in this document, necessarily, but
there're a few ways that can be handled.

> a security protocol. If we start to override TLS rules, we get into

I don't see this as overriding TLS or BCP195. I think
there just is a special case here when a stub wants
to check revocation status for a port 853 (D)TLS session.
In all other cases, we assume the TLS client can just
resolve an A/AAAA for an OCSP responder but that's not
quite enough here.

> Mentioning the scale/privacy issues of OCSP is OK, but a MUST???

I think the MUST that Tiru suggested could work, but is
not the only possible option.

Cheers,
S.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 15 Dec 2016 01:37:59 +0000

> Sent: Wednesday, December 14, 2016 7:36 PM
> To: Stephane Bortzmeyer <[email-masked]>; Tirumaleswar Reddy (tireddy)
> <[email-masked]>
> Cc: [email-masked]; [email-masked]; The IESG <[email-masked]>; draft-
> [email-masked]; [email-masked]
> Might be better to let chair/shepherd figure out next step?
> 
> > On Wed, Dec 14, 2016 at 01:50:58PM +0000,  Tirumaleswar Reddy
> > (tireddy) <[email-masked]> wrote  a message of 238 lines which
> > said:
> >
> >> the revocation status of public key certificate of the DNS server.
> >> OCSP stapling, unlike OSCP, does not suffer from scale and privacy
> >> issues.
> >
> > I'm not happy.
> >
> True that this isn't specific to DTLS. I don't agree that means this mustn't be in
> this document, necessarily, but there're a few ways that can be handled.
> 
> >
> I don't see this as overriding TLS or BCP195. I think there just is a special case
> here when a stub wants to check revocation status for a port 853 (D)TLS
> session.
> In all other cases, we assume the TLS client can just resolve an A/AAAA for an
> OCSP responder but that's not quite enough here.
> 
> I think the MUST that Tiru suggested could work, but is not the only possible
> option.

How about downgrade to SHOULD from MUST ?
(If DANE TLSA resource record is used then both OCSP and OCSP stapling is not required).

-Tiru

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 15 Dec 2016 05:15:20 +0000

Hi Stephen,

> possible I'm remembering this stuff badly;-)

Good point, will add the following additional text to [4]:

DNS query sent using 0-RTT key might be replayed by an attacker and if the anycast instance 
does not have the resource record cached, and the triggered recursive process of going through the authoritative DNS hierarchy can be used by the attacker to determine the encrypted DNS query resulting in privacy leak through DNS.

-Tiru

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 15 Dec 2016 08:21:04 +0000

Hiya,

On 15/12/16 05:15, Tirumaleswar Reddy (tireddy) wrote:
>> 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;-)
> 
> DNS query sent using 0-RTT key might be replayed by an attacker and
> if the anycast instance does not have the resource record cached, and
> the triggered recursive process of going through the authoritative
> DNS hierarchy can be used by the attacker to determine the encrypted
> DNS query resulting in privacy leak through DNS.

Doesn't the above end up meaning: "don't use 0RTT with DNS/DTLS1.3"?

I think this may have been raised on the dprive or tls wg lists a
year or so ago when we were trying to figure out the consequences
of 0RTT. Would be worthwhile checking that to ensure any text put
in here is consistent with that analysis.

S.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 15 Dec 2016 08:32:45 +0000

> Sent: Thursday, December 15, 2016 1:51 PM

Yes :)

> in here is consistent with that analysis.

In DPRIVE WG, TLS 1.3 was discussed but not the attack you pointed out. 
I will remove the text related to this mode and will start a discussion in the WG on usage of 0-RTT mode.

-Tiru

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 16 Dec 2016 02:52:21 +0000

Revised draft https://tools.ietf.org/html/draft-ietf-dprive-dnsodtls-14 addresses DISCUSS points and comments received during ISEG review. 

Please have a look.

Cheers,
-Tiru

> From: Tirumaleswar Reddy (tireddy)
> Sent: Thursday, December 15, 2016 2:03 PM
> To: 'Stephen Farrell' <[email-masked]>; The IESG <[email-masked]>
> Subject: RE: [dns-privacy] Stephen Farrell's Discuss on draft-ietf-dprive-
> > > if the anycast instance does not have the resource record cached,
> > > and the triggered recursive process of going through the
> > > authoritative DNS hierarchy can be used by the attacker to determine
> > > the encrypted DNS query resulting in privacy leak through DNS.
> >
> > I think this may have been raised on the dprive or tls wg lists a year
> > or so ago when we were trying to figure out the consequences of 0RTT.
> > Would be worthwhile checking that to ensure any text put in here is
> > consistent with that analysis.
>