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 protected]>
wrote:

> Hello,
>
> On Sat, Jul 06, 2019 at 09:19:41AM -0700, [email protected] 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
>
> _______________________________________________
> dns-privacy mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

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

Reply via email to