All, On the topic of moving 0-RTT text to the early data draft, I still agree with Christian’s position from a couple weeks ago. I don’t think separating that text makes the DoQ draft easier to read or implement and it could significantly delay the progress of DoQ. I think we have made good progress during WGLC via the Github issues to providing the right guidance within the DoQ draft.
I support work on a separate 0-RTT draft to cover the wider set of issues with early data including details regarding other transports. Regards Sara. > On 18 Oct 2021, at 21:58, Brian Haberman <[email protected]> wrote: > > Signed PGP part > Agreed that we need input from the WG on this... especially if there is > consensus that the DoQ draft needs to wait on the early-data draft. > > Regards, > Brian > > On 10/16/21 6:30 PM, Tim Wicinski wrote: >> This is a good point Ben. I'll catch up with Brian and discuss, but I'd >> also like to hear from the working group and DNS-over-QUIC authors where >> they feel this should live. >> tim >> On Fri, Oct 15, 2021 at 4:49 PM Ben Schwartz <bemasc= >> [email protected]> wrote: >>> On Fri, Oct 15, 2021 at 2:51 PM Christian Huitema <[email protected]> >>> wrote: >>> >>>> * Details on usage of 0-RTT with XFR QUERY, issue >>>> https://github.com/huitema/dnsoquic/issues/99 by Martin Thomson. The >>>> current text is wrong, because 0-RTT resumption includes carry over of >>>> the authentication negotiated in the previous connection. We may want to >>>> not consider XFR Queries as replayable, and ask servers to wait until >>>> the handshake is complete before processing them. >>>> >>>> * Details on the 0-RTT mitigation text, issue >>>> https://github.com/huitema/dnsoquic/issues/102 by Martin Thomson. The >>>> current text is based on the original analysis done by DKG years ago, >>>> which pointed out the risks of replaying 0-RTT packets at attacker >>>> chosen times. That attack is largely mitigated by the replay protection >>>> in TLS 1.3, which is mandatory to implement. 0-RTT packets can only be >>>> replayed within a narrow window, which is only wide enough to account >>>> for variations in clock skew and network transmission.Need to update the >>>> text and account for that. >>>> >>> >>> This seems like another good reason to move the 0-RTT discussion into the >>> 0-RTT draft. I've opened a copy-and-paste PR here: >>> https://github.com/ghedo/draft-ghedini-dprive-early-data/pull/4 >>> >>> I would appreciate clearer guidance from the chairs on where the 0-RTT >>> text should live. >>> _______________________________________________ >>> dns-privacy mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/dns-privacy >>> >> _______________________________________________ >> dns-privacy mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dns-privacy > > _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
