Re: [dns-privacy] New Version Notification for draft-bretelle-dprive-dot-for-insecure-delegations-01.txt
> >> This proposal actually reminds me a lot of idea I had that actually > >> used DS records instead of new record type. > >> > >> AFAIK: > >> - DNSsec ignores any such record (unknown algorithm) > >> -> No interference with DNSsec. > >> - CDS does not ignore such records. > >> -> Automated synchnonization. > >> - Lives on parent side of delegation. > >> -> No post-hoc authentication. There's a problem with CDS and unknown algorithms. RFC 7344 section 4.1 third bullet requires the parent to verify that the delegation will not be broken by new DS RRset. This means the parent needs to check that it is able to validate every algorithm, otherwise it could open up a downgrade attack. Note that this validation is not just checking that the DS records have matching DNSKEY records; the parent must also validate that at least one matching key has signed the DNSKEY RRset (because that's what normal validators will need to be able to do). So unknown algorithm hacks will not work with CDS as things currently are. Tony. -- f.anthony.n.finchhttp://dotat.at/ Great Orme Head to the Mull of Galloway: Variable 3 or 4, becoming southwest 4 or 5. Smooth or slight. Fair. Good. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] New Version Notification for draft-bretelle-dprive-dot-for-insecure-delegations-01.txt
Hello, On 24 Mar 2019, at 18:45, manu tman wrote: This proposal actually reminds me a lot of idea I had that actually used DS records instead of new record type. AFAIK: - DNSsec ignores any such record (unknown algorithm) -> No interference with DNSsec. - CDS does not ignore such records. -> Automated synchnonization. - Lives on parent side of delegation. -> No post-hoc authentication. I heard this idea twice today, and it sounds interesting. From what I gather from Paul Wouters is that not all registrars may accept unknown algorithms as well as they would validate that the DS is valid by checking the presence of the DNSKEY in the child. This would seem to be the biggest hurdle. Signalling & anchoring DoT in DS was suggested to me by a friend some time ago as well. Yesterday, Pieter Lexis and I ran some experiments with this (before catching up to this thread!). Looking up weird-ds1.7bits.nl/TXT (weird algorithm) and weird-ds2.7bits.nl/TXT (weird digest type) should return insecure on your favourite validator. Google DNS (8.8.8.8) and Knot Resolver disagree. A Knot resolver has informally confirmed this as a bug. I’m sure we can convince Google of the same, so on the validator side, deployment seems feasible. Registrars/registries are a different problem - but that problem is not entirely dissimilar from the slow rate of adoption of new algorithms (ECDSA, Ed25519) that we’ve seen in some registries. It is also a problem that can, over time, be fixed. Personally I like the DS signalling idea a lot, but I do see the ‘cloud provider’ problem angle. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] New Version Notification for draft-bretelle-dprive-dot-for-insecure-delegations-01.txt
On Sun, Mar 24, 2019 at 06:45:31PM +0100, manu tman wrote: > Thanks Ilari, > > > > This proposal actually reminds me a lot of idea I had that actually > > used DS records instead of new record type. > > > > AFAIK: > > - DNSsec ignores any such record (unknown algorithm) > > -> No interference with DNSsec. > > - CDS does not ignore such records. > > -> Automated synchnonization. > > - Lives on parent side of delegation. > > -> No post-hoc authentication. > > > > > I heard this idea twice today, and it sounds interesting. > >From what I gather from Paul Wouters is that not all registrars may accept > unknown algorithms as well as they would validate that the DS is valid by > checking the presence of the DNSKEY in the child. > This would seem to be the biggest hurdle. Well, a new RRtype definitely would not work with unmodified nameservers, since it has magic properties (it is on parent side of zone cut without being glue). > > The problem that idea ran into was actually the same: If DNS is > > outsourced to some external provoder (which is actually very > > common), then key rotations need two parties to coordinate, which > > is a nasty problem. > > > > If CDS works, then it should be fine right? Well, unless there are multiple provoders used at once, which happens sometimes. Or self-hosted DNS with cloud secondary. > > And then there is issue that not all nameservers for zone might have > > DoT support, and in that case, one would have to discover which ones > > do. And NS records might not be signed, so one can not rely on those. > > > > yeah, this would be a problem, even more if using multiple providers. On > the other hand, the NS selection heuristic should probably prefer a DoT > nameserver over one that does not support it when possible. DNS is not exactly delay-tolerant, so one wants to minimize timeouts and probing (unless said probing can be parallelized). > > One hack upon hack would be to have second key type be indirect > > reference, which would then be looked up using new RRtype at the > > target name. This would allow "cloud" case to work without annoying > > coordination problems. > > > > I am not sure I am fully grasping this fully. Mind sharing a bit more? Something of style: example.org. IN DS 0 137 2 example.org. IN DS 0 137 42 example.org. IN DS 0 137 42 ns1.cloud1.example. IN IDK 2 ns3.cloud2.example. IN IDK 2 ns3.cloud2.example. IN IDK 2 This gives four keys, presumably first is for self-hosted, the second is for first cloud provoder, and last two are for second cloud provoder that is rolling over its keys. -Ilari ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] New Version Notification for draft-bretelle-dprive-dot-for-insecure-delegations-01.txt
Thanks Ilari, > This proposal actually reminds me a lot of idea I had that actually > used DS records instead of new record type. > > AFAIK: > - DNSsec ignores any such record (unknown algorithm) > -> No interference with DNSsec. > - CDS does not ignore such records. > -> Automated synchnonization. > - Lives on parent side of delegation. > -> No post-hoc authentication. > > I heard this idea twice today, and it sounds interesting. >From what I gather from Paul Wouters is that not all registrars may accept unknown algorithms as well as they would validate that the DS is valid by checking the presence of the DNSKEY in the child. This would seem to be the biggest hurdle. > The problem that idea ran into was actually the same: If DNS is > outsourced to some external provoder (which is actually very > common), then key rotations need two parties to coordinate, which > is a nasty problem. > If CDS works, then it should be fine right? > > And then there is issue that not all nameservers for zone might have > DoT support, and in that case, one would have to discover which ones > do. And NS records might not be signed, so one can not rely on those. > yeah, this would be a problem, even more if using multiple providers. On the other hand, the NS selection heuristic should probably prefer a DoT nameserver over one that does not support it when possible. > > The unreliability of NS pretty much means that unless all nameservers > support DoT, one has to duplicate nameservers into signed records. And > that might be multiple repetitions, which are not compressable, since > DS is not magic that way (even if it is magic due to where it lives). > Also, writing the nameserver name into DS record is not exactly > pleasant (as the field is hex-encoded). > Yeah, NS is very much all or nothing and does not allow for ramping up nameservers individually. > > One hack upon hack would be to have second key type be indirect > reference, which would then be looked up using new RRtype at the > target name. This would allow "cloud" case to work without annoying > coordination problems. > I am not sure I am fully grasping this fully. Mind sharing a bit more? Thanks Manu > > > > > > -Ilari > ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] New Version Notification for draft-bretelle-dprive-dot-for-insecure-delegations-01.txt
On Sat, Mar 23, 2019 at 12:58:46AM +, Reed, Jon wrote: > I’m glad to see this proposal, I find it personally preferable to the > dnscurve-esque proposal with the base32-encoded NS names. In both > cases, however, the examples assume that the nameservers are in > bailiwick for the zone. This is not going to be true for any side > using a cloud authoritative DNS provider, which is fine. > > However, I also think it should be possible for cloud providers to > offer DoT transparently, without customers needing to opt-in. > (I’m open to rebuttals to that, but I don’t see any obvious > drawbacks.) I’d like to see the ability to scale either of these > proposals to cloud services, but I’m not quite sure how that would > work. > > Consider the following delegation from the gTLD servers: > > example.com 3600 IN NS ns1.clouddnsprovider.com > example.com 3600 IN NS ns2.clouddnsprovider.com > > Now, under the clouddnsprovider.com zone, the provider can create the > necessary DSPKI or base32-encoded NS records for > “clouddnsprovider.com” in the gTLDs. But under my reading of this > proposal, that means DOT would only be used to look up names under > “clouddnsprovider.com”, not “example.com”. But, the recursive > _knows_ that ns1.clouddnsprovider.com is capable of doing DoT > (assuming TLS negotiation was successful). Therefore, I think it > should be able to use DoT to lookup names under example.com (or > indeed, under any domain which has the same (ns name, address) tuple. > I’d like to see this use case explicitly addressed in the text of the > draft. This proposal actually reminds me a lot of idea I had that actually used DS records instead of new record type. AFAIK: - DNSsec ignores any such record (unknown algorithm) -> No interference with DNSsec. - CDS does not ignore such records. -> Automated synchnonization. - Lives on parent side of delegation. -> No post-hoc authentication. The problem that idea ran into was actually the same: If DNS is outsourced to some external provoder (which is actually very common), then key rotations need two parties to coordinate, which is a nasty problem. And then there is issue that not all nameservers for zone might have DoT support, and in that case, one would have to discover which ones do. And NS records might not be signed, so one can not rely on those. The unreliability of NS pretty much means that unless all nameservers support DoT, one has to duplicate nameservers into signed records. And that might be multiple repetitions, which are not compressable, since DS is not magic that way (even if it is magic due to where it lives). Also, writing the nameserver name into DS record is not exactly pleasant (as the field is hex-encoded). One hack upon hack would be to have second key type be indirect reference, which would then be looked up using new RRtype at the target name. This would allow "cloud" case to work without annoying coordination problems. -Ilari ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] New Version Notification for draft-bretelle-dprive-dot-for-insecure-delegations-01.txt
Hi Jon,
> However, I also think it should be possible for cloud providers to offer
> DoT transparently, without customers needing to opt-in. (I’m open to
> rebuttals to that, but I don’t see any obvious drawbacks.) I’d like to
> see the ability to scale either of these proposals to cloud services, but
> I’m not quite sure how that would work.
>
I think there may be business decisions as to whether or not this will
should transparent to the user vs being able to easily opt them in. I would
wish for this to be transparent and automatically enable wherever possible,
but people in that side of the business (which I am not in) may have
different opinions, I would like to hear those.
>
> Consider the following delegation from the gTLD servers:
>
>
>
> example.com 3600 IN NS ns1.clouddnsprovider.com
>
> example.com 3600 IN NS ns2.clouddnsprovider.com
>
>
>
> Now, under the clouddnsprovider.com zone, the provider can create the
> necessary DSPKI or base32-encoded NS records for “clouddnsprovider.com”
> in the gTLDs. But under my reading of this proposal, that means DOT would
> only be used to look up names under “clouddnsprovider.com”, not “
> example.com”. But, the recursive _*knows*_ that ns1.clouddnsprovider.com
> is capable of doing DoT (assuming TLS negotiation was successful).
> Therefore, I think it should be able to use DoT to lookup names under
> example.com (or indeed, under any domain which has the same (ns name,
> address) tuple.I’d like to see this use case explicitly addressed in
> the text of the draft.
>
As is, the SPKI would be used to validate the servers ns{1,2}.
cloudprovider.com but there is definitely a disconnect when it is out of
bailiwick. We should be able to articulate something for that case though.
I am at the IETF till EOW. Let’s meet and brainstorm how that could work
out for this scenario.
Manu
>
>
> Unfortunately, I’ll only be able to attend the first 10-15 minutes of
> DPRIVE before I have to leave for the airport, but I’d be happy to discuss
> this further in a side-meeting or ad-hoc.
>
>
>
> Thanks,
>
>
>
> Jon
>
>
>
>
>
> --
>
> Jon Reed
>
> Senior Performance Engineer
>
> Nameservers Service Performance
>
>
>
>
>
>
>
> *From: *manu tman
> *Date: *Monday, March 11, 2019 at 12:52 PM
> *To: *"dns-privacy@ietf.org"
> *Subject: *[dns-privacy] New Version Notification for
> draft-bretelle-dprive-dot-for-insecure-delegations-01.txt
>
>
>
>
>
> During earlier discussion (post virtual meeting), there were a mixture of
> feeling as to where SPKI may be published, here is one proposal bump
> (through the rush of time) to publish it in the parent zone.
>
>
>
>
>
> Manu
>
>
>
> ———
>
>
>
>
>
> A new version of I-D,
> draft-bretelle-dprive-dot-for-insecure-delegations-01.txt
>
> has been successfully submitted by Emmanuel Bretelle and posted to the
>
> IETF repository.
>
>
>
> Name: draft-bretelle-dprive-dot-for-insecure-delegations
>
> Revision: 01
>
> Title: DNS-over-TLS for insecure delegations
>
> Document date: 2019-03-11
>
> Group: Individual Submission
>
> Pages: 7
>
> URL:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_internet-2Ddrafts_draft-2Dbretelle-2Ddprive-2Ddot-2Dfor-2Dinsecure-2Ddelegations-2D01.txt=DwICaQ=5VD0RTtNlTh3ycd41b3MUw=aRgHK985qD76PXQaxDKSjA=6YEGDy0nuzoKlGCjHJ86Ys_n2UOt0iXWrohw3MEa6zI=PTJU2WP56vNJ3OnZN8sxwflDDPzJTP2kbMe7zyinhT8=
>
> Status:
> https://urldefense.proofpoint..com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dbretelle-2Ddprive-2Ddot-2Dfor-2Dinsecure-2Ddelegations_=DwICaQ=5VD0RTtNlTh3ycd41b3MUw=aRgHK985qD76PXQaxDKSjA=6YEGDy0nuzoKlGCjHJ86Ys_n2UOt0iXWrohw3MEa6zI=SSXjldGIOCQ8_CAJnci1qab0INy6UiD75Fu71efQyW4=
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dbretelle-2Ddprive-2Ddot-2Dfor-2Dinsecure-2Ddelegations_=DwICaQ=5VD0RTtNlTh3ycd41b3MUw=aRgHK985qD76PXQaxDKSjA=6YEGDy0nuzoKlGCjHJ86Ys_n2UOt0iXWrohw3MEa6zI=SSXjldGIOCQ8_CAJnci1qab0INy6UiD75Fu71efQyW4=>
>
>
>
> Htmlized:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbretelle-2Ddprive-2Ddot-2Dfor-2Dinsecure-2Ddelegations-2D01=DwICaQ=5VD0RTtNlTh3ycd41b3MUw=aRgHK985qD76PXQaxDKSjA=6YEGDy0nuzoKlGCjHJ86Ys_n2UOt0iXWrohw3MEa6zI=gwClruoLv-Mu6Sxl37_kCyxOu6Vx5QBV1ppRA0_m5aw=
>
> Htmlized:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dbretelle-2Ddprive-2Ddot-2Dfor-2Dinsecure-2Ddelegations=DwICaQ=5VD0RTtNlTh3ycd41b3MUw=aRgHK985qD76PXQaxDKSjA=6YEGDy0nuzoKlGCjHJ86Ys_n2UOt0iXWrohw3MEa6zI=MyhcqxSfzLUA2UhuM22MPzog5cLn6OxC_EwQPH7Qe6Y=
>
>
Re: [dns-privacy] New Version Notification for draft-bretelle-dprive-dot-for-insecure-delegations-01.txt
I’m glad to see this proposal, I find it personally preferable to the dnscurve-esque proposal with the base32-encoded NS names. In both cases, however, the examples assume that the nameservers are in bailiwick for the zone. This is not going to be true for any side using a cloud authoritative DNS provider, which is fine. However, I also think it should be possible for cloud providers to offer DoT transparently, without customers needing to opt-in. (I’m open to rebuttals to that, but I don’t see any obvious drawbacks.) I’d like to see the ability to scale either of these proposals to cloud services, but I’m not quite sure how that would work. Consider the following delegation from the gTLD servers: example.com 3600 IN NS ns1.clouddnsprovider.com example.com 3600 IN NS ns2.clouddnsprovider.com Now, under the clouddnsprovider.com zone, the provider can create the necessary DSPKI or base32-encoded NS records for “clouddnsprovider.com” in the gTLDs. But under my reading of this proposal, that means DOT would only be used to look up names under “clouddnsprovider.com”, not “example.com”. But, the recursive _knows_ that ns1.clouddnsprovider.com is capable of doing DoT (assuming TLS negotiation was successful). Therefore, I think it should be able to use DoT to lookup names under example.com (or indeed, under any domain which has the same (ns name, address) tuple.I’d like to see this use case explicitly addressed in the text of the draft. Unfortunately, I’ll only be able to attend the first 10-15 minutes of DPRIVE before I have to leave for the airport, but I’d be happy to discuss this further in a side-meeting or ad-hoc. Thanks, Jon -- Jon Reed Senior Performance Engineer Nameservers Service Performance From: manu tman Date: Monday, March 11, 2019 at 12:52 PM To: "dns-privacy@ietf.org" Subject: [dns-privacy] New Version Notification for draft-bretelle-dprive-dot-for-insecure-delegations-01.txt During earlier discussion (post virtual meeting), there were a mixture of feeling as to where SPKI may be published, here is one proposal bump (through the rush of time) to publish it in the parent zone. Manu ——— A new version of I-D, draft-bretelle-dprive-dot-for-insecure-delegations-01.txt has been successfully submitted by Emmanuel Bretelle and posted to the IETF repository. Name: draft-bretelle-dprive-dot-for-insecure-delegations Revision: 01 Title: DNS-over-TLS for insecure delegations Document date: 2019-03-11 Group: Individual Submission Pages: 7 URL: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_internet-2Ddrafts_draft-2Dbretelle-2Ddprive-2Ddot-2Dfor-2Dinsecure-2Ddelegations-2D01.txt=DwICaQ=5VD0RTtNlTh3ycd41b3MUw=aRgHK985qD76PXQaxDKSjA=6YEGDy0nuzoKlGCjHJ86Ys_n2UOt0iXWrohw3MEa6zI=PTJU2WP56vNJ3OnZN8sxwflDDPzJTP2kbMe7zyinhT8= Status: https://urldefense.proofpoint..com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dbretelle-2Ddprive-2Ddot-2Dfor-2Dinsecure-2Ddelegations_=DwICaQ=5VD0RTtNlTh3ycd41b3MUw=aRgHK985qD76PXQaxDKSjA=6YEGDy0nuzoKlGCjHJ86Ys_n2UOt0iXWrohw3MEa6zI=SSXjldGIOCQ8_CAJnci1qab0INy6UiD75Fu71efQyW4=<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dbretelle-2Ddprive-2Ddot-2Dfor-2Dinsecure-2Ddelegations_=DwICaQ=5VD0RTtNlTh3ycd41b3MUw=aRgHK985qD76PXQaxDKSjA=6YEGDy0nuzoKlGCjHJ86Ys_n2UOt0iXWrohw3MEa6zI=SSXjldGIOCQ8_CAJnci1qab0INy6UiD75Fu71efQyW4=> Htmlized: https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbretelle-2Ddprive-2Ddot-2Dfor-2Dinsecure-2Ddelegations-2D01=DwICaQ=5VD0RTtNlTh3ycd41b3MUw=aRgHK985qD76PXQaxDKSjA=6YEGDy0nuzoKlGCjHJ86Ys_n2UOt0iXWrohw3MEa6zI=gwClruoLv-Mu6Sxl37_kCyxOu6Vx5QBV1ppRA0_m5aw= Htmlized: https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dbretelle-2Ddprive-2Ddot-2Dfor-2Dinsecure-2Ddelegations=DwICaQ=5VD0RTtNlTh3ycd41b3MUw=aRgHK985qD76PXQaxDKSjA=6YEGDy0nuzoKlGCjHJ86Ys_n2UOt0iXWrohw3MEa6zI=MyhcqxSfzLUA2UhuM22MPzog5cLn6OxC_EwQPH7Qe6Y= Diff: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dbretelle-2Ddprive-2Ddot-2Dfor-2Dinsecure-2Ddelegations-2D01=DwICaQ=5VD0RTtNlTh3ycd41b3MUw=aRgHK985qD76PXQaxDKSjA=6YEGDy0nuzoKlGCjHJ86Ys_n2UOt0iXWrohw3MEa6zI=aXUkzkp72a1sBvkWpiF9xYstuFWDnXcVoJTRRtLN2tA= Abstract: This document describes an alternative mechanism to DANE ([RFC6698]) in order to authenticate a DNS-over-TLS (DoT [RFC7858]) authoritative server by not making DNSSEC a hard requirement, making DoT server authentication available for insecure delegations. 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<https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org_=DwMFaQ=96ZbZZcaMF4w0F4jpN6LZg=_xTHEvws93UZ7jl9jhO7Pg=Wd41zdFrBer8CbvE8IcsmswCHFw9t1jpnqp_Gc9ifmk=4W3NnQBFNBwU4tl-AbrJMTVq
[dns-privacy] New Version Notification for draft-bretelle-dprive-dot-for-insecure-delegations-01.txt
During earlier discussion (post virtual meeting), there were a mixture of feeling as to where SPKI may be published, here is one proposal bump (through the rush of time) to publish it in the parent zone. Manu ——— A new version of I-D, draft-bretelle-dprive-dot-for-insecure-delegations-01.txt has been successfully submitted by Emmanuel Bretelle and posted to the IETF repository. Name: draft-bretelle-dprive-dot-for-insecure-delegations Revision: 01 Title: DNS-over-TLS for insecure delegations Document date: 2019-03-11 Group: Individual Submission Pages: 7 URL: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_internet-2Ddrafts_draft-2Dbretelle-2Ddprive-2Ddot-2Dfor-2Dinsecure-2Ddelegations-2D01.txt=DwICaQ=5VD0RTtNlTh3ycd41b3MUw=aRgHK985qD76PXQaxDKSjA=6YEGDy0nuzoKlGCjHJ86Ys_n2UOt0iXWrohw3MEa6zI=PTJU2WP56vNJ3OnZN8sxwflDDPzJTP2kbMe7zyinhT8= Status: https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dbretelle-2Ddprive-2Ddot-2Dfor-2Dinsecure-2Ddelegations_=DwICaQ=5VD0RTtNlTh3ycd41b3MUw=aRgHK985qD76PXQaxDKSjA=6YEGDy0nuzoKlGCjHJ86Ys_n2UOt0iXWrohw3MEa6zI=SSXjldGIOCQ8_CAJnci1qab0INy6UiD75Fu71efQyW4= Htmlized: https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbretelle-2Ddprive-2Ddot-2Dfor-2Dinsecure-2Ddelegations-2D01=DwICaQ=5VD0RTtNlTh3ycd41b3MUw=aRgHK985qD76PXQaxDKSjA=6YEGDy0nuzoKlGCjHJ86Ys_n2UOt0iXWrohw3MEa6zI=gwClruoLv-Mu6Sxl37_kCyxOu6Vx5QBV1ppRA0_m5aw= Htmlized: https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dbretelle-2Ddprive-2Ddot-2Dfor-2Dinsecure-2Ddelegations=DwICaQ=5VD0RTtNlTh3ycd41b3MUw=aRgHK985qD76PXQaxDKSjA=6YEGDy0nuzoKlGCjHJ86Ys_n2UOt0iXWrohw3MEa6zI=MyhcqxSfzLUA2UhuM22MPzog5cLn6OxC_EwQPH7Qe6Y= Diff: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dbretelle-2Ddprive-2Ddot-2Dfor-2Dinsecure-2Ddelegations-2D01=DwICaQ=5VD0RTtNlTh3ycd41b3MUw=aRgHK985qD76PXQaxDKSjA=6YEGDy0nuzoKlGCjHJ86Ys_n2UOt0iXWrohw3MEa6zI=aXUkzkp72a1sBvkWpiF9xYstuFWDnXcVoJTRRtLN2tA= Abstract: This document describes an alternative mechanism to DANE ([RFC6698]) in order to authenticate a DNS-over-TLS (DoT [RFC7858]) authoritative server by not making DNSSEC a hard requirement, making DoT server authentication available for insecure delegations. 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
