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

From: Alessandro Ghedini <[email-masked]>
Date: Tue, 25 Feb 2020 15:13:59 +0000

On Tue, Feb 25, 2020 at 06:24:20AM -0800, [email-masked] wrote:
> 
> 
> A new version of I-D, draft-ghedini-dprive-early-data-02.txt
> has been successfully submitted by Alessandro Ghedini and posted to the
> IETF repository.
> 
> Name:		draft-ghedini-dprive-early-data
> Revision:	02
> Title:		Using Early Data in DNS over TLS
> Document date:	2020-02-25
> Group:		Individual Submission
> Pages:		6
> URL:            https://www.ietf.org/internet-drafts/draft-ghedini-dprive-early-data-02.txt
> Status:         https://datatracker.ietf.org/doc/draft-ghedini-dprive-early-data/
> Htmlized:       https://tools.ietf.org/html/draft-ghedini-dprive-early-data-02
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ghedini-dprive-early-data
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ghedini-dprive-early-data-02
> 
> 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.

Long overdue update to the Early Data for DoT draft (sorry for the delay). This
incorporates changes suggested from past discussions and reviews.

Notably:

* Clarified why some DNS messages are not allowed in early data. All DNS

* Messages that don't use the Query opcode are now explicitly forbidden
  from being sent over early data.

* Defined a registry of RR types that can be sent over early data. This is
  likely to be incomplete right now. New entries can be easily added later, but
  for now I'd like some feedback on whether this is the right direction before
  going further.

As per the above changelog, the new draft strictly limits DNS messages allowed
in early data to ones that use the Query opcode AND RR types that are explcitly
listed in the new registry. But after doing that work, I'm now wondering if
allowing only query messages is actually enough, without the need to define the
RR types registry. Any thoughts? I don't really know what most of the RR types
currently defined do, so I might be missing something.

Also worth noting that the general wording and structure of the draft might need
some improvements (as Martin pointed out in his review some text could probably
be replaced by references to RFC 8446 and 8470) but after spending some time on
this I couldn't come up with much, so for now I'd like to get some feedback on
the changes and discussion point mentioned above.

CHeers

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 25 Feb 2020 15:54:35 +0000

Hiya,

I may well be just forgetting things, (in which case,
apologies), but is there something missing...

If an attacker replays a 0rtt query for an A record,
and the recursive acts on the query before the handshake
is complete by sending a cleartext query upstream and
if the attacker can see that upstream query, wouldn't
that be noteworthy?

If so, perhaps your draft ought not say that "a server
...MAY...delay the processing" but instead say something
stronger? E.g., perhaps that the query from early_data
MUST NOT be visibly-processed/forwarded until the h/s
has successfully completed?

Cheers,
S.

On 25/02/2020 15:13, Alessandro Ghedini wrote:
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 26 Feb 2020 11:21:42 -0700

> if the attacker can see that upstream query, wouldn't

Noteworthy, yes.  This amplifies an existing exposure.  That is, as long as a cleartext query from the recursive could be correlated with an encrypted query to the recursive, there is a problem.  This says that replays can be used - maybe - to turn one query into N.  If you rely on the correlation being from a large anonymity set, this can have a serious impact on the ability of an observer to correlate queries. This might be compounded by the fact that early data might contain multiple queries that can be cross-correlated.

Whether that motivates a blanket prohibition on use of early data prior to handshake completion depends greatly on other factors.  If we manage to ever get encryption toward authoritative servers, and even opportunistic encryption helps considerably in this case, then this particular problem is eliminated.  But I wouldn't rule out making the queries.

This only applies where the query cannot be answered from cache.  Of course that the potential for replay is likely closely tied to the potential for a cache miss, so we might not consider that to be relevant.