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
