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: > On Tue, Feb 25, 2020 at 06:24:20AM -0800, [email protected] 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 > > _______________________________________________ > dns-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy >
0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
