Re: [dns-privacy] New Version Notification for draft-zatda-dprive-xfr-using-dso-00.txt
Tom Pusateri wrote: > > In 7.1.1.1, there is mention of efficiently packing stream data into > TCP segments. This is also in the PUSH draft but I think it should be > removed from there and from here as well because once the data is > encoded in a TLS session, it’s much more difficult for the sender to > have control over the size of TCP segments sent. I think the right abstraction here is operating system write() or send() calls, since you can't normally control segmentation in detail except that short writes usually lead to short packets. e.g. (covering both TCP and TLS): Since SUBSCRIBE-XFR requests are sent over TCP, multiple SUBSCRIBE-XFR DSO request messages can be concatenated in a single write call to make efficient use of the underlying transport. ... but of course this applies to any DNS messages over TCP or TLS ... Tony. -- f.anthony.n.finchhttp://dotat.at/ Shannon: Southwest, veering west or northwest, 4 or 5, occasionally 6 at first. Moderate, occasionally slight at first in southeast. Occasional rain, fog patches. Moderate or good, occasionally very poor.___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] New Version Notification for draft-zatda-dprive-xfr-using-dso-00.txt
> On 9 Jul 2019, at 23:29, Tom Pusateri wrote: > > This is a great use of DSO and pub/sub. I support this work and I like the > new acronym XuD in the spirit of DoT and DoH, etc. Hi Tom, Thanks for the feedback > > Some minor comments: > > In the Abstract is NOTITY/SOA instead of NOTIFY/SOA. > > In the Terminology section, XuD is defined using DOS instead of DSO. Both fixed in the next version - thanks. > > In the Overview, you mention clients should only subscribe for zones they are > authorised to transfer. This needs a little more context. Who authorises a > client? How does a client know it is authorised? Yes - this does need more context. Perhaps it is better phrased that ’secondaries should only create XuD subscriptions on connections to severs that are expliclty configured as primaries for the zone in question’? This makes it independent of the authentication model. > > In 7.1, in a note, you mention TSIG can be used by the client to demonstrate > that it is authorised so maybe this is what is meant earlier in the overview > but it should be more explicit but also, it would be neat if SIG(0) > certificate verification could be used for authorisation as well to obviate > the need for out of band secret exchange. There is a full discussion of authentication methods in the 'DNS Zone Transfer-over-TLS’ (https://datatracker.ietf.org/doc/draft-hzpa-dprive-xfr-over-tls/) which is reference here but not reproduced. But a discussion of SIG(0) should be added there…. > > In 7.1.1.1, there is mention of efficiently packing stream data into TCP > segments. This is also in the PUSH draft but I think it should be removed > from there and from here as well because once the data is encoded in a TLS > session, it’s much more difficult for the sender to have control over the > size of TCP segments sent. I’ve actually had a couple of off list discussions that propose the TCP use case for this is a valid one and we should make TLS optional, in which case this should probably stay in this draft with that qualification? (I know PUSH requires TLS). > > In 7.3.1, you ask the question if the equivalent of a RECONFIRM message is > needed. The answer is no. This is specific to the way service discovery > currently works and it is not applicable in the XFR case. Thanks for that - I couldn’t see the use case for zone transfer. There are other cases of needing to ‘reset' the transfer in various ways which we’ll try to address in the next version. Thanks Sara. > > Thanks, > Tom > >> On Jul 9, 2019, at 5:03 AM, Sara Dickinson wrote: >> >> Hi All, >> >> A new draft has been submitted that outlines the basics of a DSO based >> mechanism for zone transfers requiring TLS. >> >> There is much more work to do on the details and potentially additional >> messaging to define but hopefully this includes information to get some >> initial feedback on this proposal. >> >> Best regards >> >> Sara. >> >>> On 8 Jul 2019, at 18:45, internet-dra...@ietf.org wrote: >>> >>> >>> A new version of I-D, draft-zatda-dprive-xfr-using-dso-00.txt >>> has been successfully submitted by Sara Dickinson and posted to the >>> IETF repository. >>> >>> Name:draft-zatda-dprive-xfr-using-dso >>> Revision:00 >>> Title:DNS Zone Transfer using DNS Stateful Operations >>> Document date:2019-07-08 >>> Group:Individual Submission >>> Pages:21 >>> URL: >>> https://www.ietf.org/internet-drafts/draft-zatda-dprive-xfr-using-dso-00.txt >>> Status: >>> https://datatracker.ietf.org/doc/draft-zatda-dprive-xfr-using-dso/ >>> Htmlized: >>> https://tools.ietf.org/html/draft-zatda-dprive-xfr-using-dso-00 >>> Htmlized: >>> https://datatracker.ietf.org/doc/html/draft-zatda-dprive-xfr-using-dso >>> >>> >>> Abstract: >>> DNS zone transfers are transmitted in clear text, which gives >>> attackers the opportunity to collect the content of a zone by >>> eavesdropping on network connections. This document specifies use of >>> DNS Stateful Operations to enable a subscribe/publish mechanism for >>> zone transfers reducing the over head introduced by NOTITY/SOA >>> interactions prior to zone transfer request. This additionally >>> prevents zone contents collection via passive monitoring of zone >>> transfers by restricting XFR using DSO to require TLS. >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >>> >> >> ___ >> dns-privacy mailing list >> dns-privacy@ietf.org >> https://www.ietf.org/mailman/listinfo/dns-privacy > ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [EXTERNAL] Re: New Version Notification for draft-ghedini-dprive-early-data-01.txt
I also read the thread at https://mailarchive.ietf.org/arch/msg/dns-privacy/p0SpGpLBAXZYJhgS3zXWwHBBlw0 and found it interesting background. On 7/9/19, 10:15 PM, "Tom Pusateri" 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, Tom > On Jul 9, 2019, at 9:10 PM, Livingood, Jason 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" wrote: > >Hello, > >On Sat, Jul 06, 2019 at 09:19:41AM -0700, internet-dra...@ietf.org 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://protect2.fireeye.com/url?k=7c610da3-20850368-7c612a17-000babff3540-3079629bacc8ac33=https://github.com/ghedo/draft-ghedini-dprive-early-data > >Would be interested to know what people think about this. > >Cheers > >___ >dns-privacy mailing list >dns-privacy@ietf.org >https://www.ietf.org/mailman/listinfo/dns-privacy > > > ___ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
