Re: [dns-privacy] New Version Notification for draft-ghedini-dprive-early-data-01.txt

[Dan Wing <[e-mail]>]

On Jul 9, 2019, at 7:15 PM, Tom Pusateri <[e-mail]> wrote:
> This is relevant to the Push Notification draft we’re trying to wrap up.
> 
> In the last paragraph of section 4, it says:
>   Not all types of DNS queries are safe to be sent as early data.
>   Clients MUST NOT use early data to send DNS Updates ([RFC2136]) or
>   Zone Transfers ([RFC5936]) messages.  Servers receiving any of those
>   messages MUST reply with a "FormErr" response code.
> 
> There isn’t a reason or reference for this claim of not being safe. Can the authors expand on this?

Thanks for writing this up, Allesandro.

Tom, both of those DNS messages are not queries -- they change the state of the server.  The concern is replay attacks, I expect.  Text should be updated to be clear on why, for sure.

Slightly later the text suggests a whitelist vs blacklist.  I think this needs to be in an IANA registry indicating which DNS messagese are allowed for early data.  Implementation guidance should encourage a whitelist on the server, IMHO.

-d


> Thanks,
> Tom
> 
> 
>> On Jul 9, 2019, at 9:10 PM, Livingood, Jason <[e-mail]> wrote:
>> 
>> Just read it - very interesting! Is the bottom line essentially don't do DNS+TLS-1.3+0-RTT? Basically, since 1-RTT isn't a big performance problem, why take the risk of 0-RTT?
>> 
>> JL
>> 
>> On 7/6/19, 12:50 PM, "dns-privacy on behalf of Alessandro Ghedini" <[e-mail] on behalf of [e-mail]> wrote:
>> 
>>   Hello,
>> 
>>   On Sat, Jul 06, 2019 at 09:19:41AM -0700, [e-mail] 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
>>   [e-mail]
>>   https://www.ietf.org/mailman/listinfo/dns-privacy
>> 
>> 
>> _______________________________________________
>> dns-privacy mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dns-privacy
> 
> _______________________________________________
> dns-privacy mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dns-privacy