Subject: [dns-privacy] Fwd: New Version Notification for draft-ghedini-dprive-early-data-01.txt

From: Alessandro Ghedini <[email-masked]>
Date: Sat, 6 Jul 2019 17:48:23 +0100

Hello,

On Sat, Jul 06, 2019 at 09:19:41AM -0700, [email-masked] wrote:
> A new version of I-D, draft-ghedini-dprive-early-data-01.txt
> has been successfully submitted by Alessandro Ghedini and posted to the
> IETF repository.
> 
> Name:		draft-ghedini-dprive-early-data
> Revision:	01
> Title:		Using Early Data in DNS over TLS
> Document date:	2019-07-06
> Group:		Individual Submission
> Pages:		5
> URL:            https://www.ietf.org/internet-drafts/draft-ghedini-dprive-early-data-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-ghedini-dprive-early-data/
> Htmlized:       https://tools.ietf.org/html/draft-ghedini-dprive-early-data-01
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ghedini-dprive-early-data
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ghedini-dprive-early-data-01
> 
> Abstract:
>    This document illustrates the risks of using TLS 1.3 early data with
>    DNS over TLS, and specifies behaviors that can be adopted by clients
>    and servers to reduce those risks.

I've been looking for information about using TLS 1.3 0-RTT with DoT, but all I
could find was a discussion from over a year ago on the mailing list:
https://mailarchive.ietf.org/arch/msg/dns-privacy/LKZeOAj7Y4fC-9hRcbX_4KVWu0Y

So I wrote this document to try and document potential risks as well as capture
requirements for DoT implementations deciding to add support for 0-RTT (RFC8446
in Appendix E.5 says that "Application protocols MUST NOT use 0-RTT data without
a profile that defines its use).

Most of the wording comes from RFC8470 and some content from the mailing list
discussion mentioned above, though there are still some things that need to be
filled in or expanded.

In this new revision I expanded some of the sections as well as included some
editorial fixes.

The draft is maintained on GitHub at:
https://github.com/ghedo/draft-ghedini-dprive-early-data

Would be interested to know what people think about this.

Cheers

---

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 10 Jul 2019 01:10:28 +0000

Just read it - very interesting! Is the bottom line essentially don't do DNS+TLS-1.3+0-RTT? Basically, since 1-RTT isn't a big performance problem, why take the risk of 0-RTT?

JL

On 7/6/19, 12:50 PM, "dns-privacy on behalf of Alessandro Ghedini" <[email-masked] on behalf of [email-masked]> wrote:

    Hello,

    

    

    Cheers
    
    _______________________________________________
    dns-privacy mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: Tom Pusateri <[email-masked]>
Date: Tue, 9 Jul 2019 22:15:27 -0400

This is relevant to the Push Notification draft we’re trying to wrap up.

In the last paragraph of section 4, it says:
   Not all types of DNS queries are safe to be sent as early data.
   Clients MUST NOT use early data to send DNS Updates ([RFC2136]) or
   Zone Transfers ([RFC5936]) messages.  Servers receiving any of those
   messages MUST reply with a "FormErr" response code.

There isn’t a reason or reference for this claim of not being safe. Can the authors expand on this?

Thanks,
Tom

> On Jul 9, 2019, at 9:10 PM, Livingood, Jason <[email-masked]> wrote:
>

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 9 Jul 2019 22:25:15 -0400

Thanks for writing this up.  Your recommendation makes sense to me, and I
think it will be useful in practice.

One thought: instead of rejecting unsafe 0-RTT data with FormErr, could we
tell servers to reject the early data at the TLS layer to force a
retransmission?  That seems like it might be simpler to implement on both
sides, and just as safe.

On Sat, Jul 6, 2019, 12:50 PM Alessandro Ghedini <[email-masked]>
wrote:

> > URL:
> https://www.ietf.org/internet-drafts/draft-ghedini-dprive-early-data-01.txt
> > Status:
> https://datatracker.ietf.org/doc/draft-ghedini-dprive-early-data/
> > Htmlized:
> https://tools.ietf.org/html/draft-ghedini-dprive-early-data-01
> > Htmlized:
> https://datatracker.ietf.org/doc/html/draft-ghedini-dprive-early-data
> > Diff:
> https://www.ietf.org/rfcdiff?url2=draft-ghedini-dprive-early-data-01
> >
> > Abstract:

---

From: Dan Wing <[email-masked]>
Date: Tue, 9 Jul 2019 20:24:28 -0700

> There isn’t a reason or reference for this claim of not being safe. Can the authors expand on this?

Thanks for writing this up, Allesandro.

Tom, both of those DNS messages are not queries -- they change the state of the server.  The concern is replay attacks, I expect.  Text should be updated to be clear on why, for sure.

Slightly later the text suggests a whitelist vs blacklist.  I think this needs to be in an IANA registry indicating which DNS messagese are allowed for early data.  Implementation guidance should encourage a whitelist on the server, IMHO.

-d

---

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 10 Jul 2019 11:21:58 +0000

I also read the thread at https://mailarchive.ietf.org/arch/msg/dns-privacy/p0SpGpLBAXZYJhgS3zXWwHBBlw0 and found it interesting background.

On 7/9/19, 10:15 PM, "Tom Pusateri" <[email-masked]> wrote:

    
    
    Thanks,
    Tom

    >    https://protect2.fireeye.com/url?k=7c610da3-20850368-7c612a17-000babff3540-3079629bacc8ac33&u=https://github.com/ghedo/draft-ghedini-dprive-early-data
    >

---

From: Alessandro Ghedini <[email-masked]>
Date: Wed, 17 Jul 2019 14:35:40 +0100

> Tom, both of those DNS messages are not queries -- they change the state of the server.  The concern is replay attacks, I expect.  Text should be updated to be clear on why, for sure.

Fair enough, created https://github.com/ghedo/draft-ghedini-dprive-early-data/issues/3
to track this.

> Slightly later the text suggests a whitelist vs blacklist.  I think this needs to be in an IANA registry indicating which DNS messagese are allowed for early data.  Implementation guidance should e…

I wonder though if a whole new registry is overkill, and we could maybe just add
a column to the existing RR types registry?

In any case I created https://github.com/ghedo/draft-ghedini-dprive-early-data/issues/2
to track this.

Cheers

---

From: Alessandro Ghedini <[email-masked]>
Date: Wed, 17 Jul 2019 14:44:44 +0100

> retransmission?  That seems like it might be simpler to implement on both

The problem is that the decision of whether you accept or reject early data
happens before the application had a chance of actually reading it, so you don't
know whether a specific DNS query can be allowed before deciding to reject all
of the early data. Also, there could potentially be multiple queries in the
early data.

HTTP solved this by defining a special HTTP status code that instructs the
client to retry only the affected request(s), so the server could, after
accepting early data at the TLS layer, execute some of the early data requests
but not all of them. Maybe we could do something similar with extended DNS
errors (draft-ietf-dnsop-extended-error)? Though I don't know how useful this
would be in practice.

Cheers

---

From: Christian Huitema <[email-masked]>
Date: Fri, 19 Jul 2019 08:47:05 -0700

>> retransmission?  That seems like it might be simpler to implement on both

Servers could also be programmed to not advertise support for early data
in the TLS 1.3 session resumption tickets. This will automatically
prevent the client from even trying 0-RTT.

> of the early data. Also, there could potentially be multiple queries in the

That's a real problem when the TLS layer has to support multiple
application,such as for a DoH service hosted over a general purpose HTTP
server. It is much less of a problem for DoT.

> errors (draft-ietf-dnsop-extended-error)? Though I don't know how useful this

The threat model here is an attacker that can observe the traffic
flowing from the resolver to the authoritative servers. I suppose that
the attack does not work if the response comes from cached data.

But generally, yes, if clients are concerned with privacy they should
not attempt to use 0-RTT. Note that this is not just an issue of replay
by attackers. You also have to be concerned with the "session resumption
ticket" acting as a super cookie, and allowing the server to link the
resumed session with the previous one, thus exposing more of the
client's "history".

-- Christian Huitema