[DNSOP] Re: [dtn] An Interplanetary DNS Model
Hi Scott,
FTR .arpa is not "reverse DNS", only the in-addr.arpa and ipv6.arpa is.
.arpa now stands for Address and Routing Parameter Area, and there are
more subdomains than just these two mentioned above.
Ondrej
--
Ondřej Surý (He/Him)
ond...@isc.org
My working hours and your working hours may be different. Please do not feel
obligated to reply outside your normal working hours.
> On 22. 7. 2024, at 14:25, Scott Johnson wrote:
>
> Hi Bryce,
>
> Interesting. This is the second reply which wishes to use reverse DNS in
> this fashion, the first being from Rick Taylor. The thing is, reverse DNS is
> not exactly a user facing function. One goal of this effort is to allow
> interoperability across worlds with a similar user experience, based on
> similar concepts and primitives.
>
> If you were to ask around the office, most folks working with you understand
> how to access a URL with a domain name. Similarly, most will never have
> heard of reverse DNS, and what it is used for. I am sure you see the issue
> here.
>
> I agree that reverse DNS mappings could be a useful part of the BP naming
> ecosystem, just as dedicated RRTYPEs will be. What is unclear is how this
> will make for an understood and familiar experience for the off-world
> internet user?
>
> Thanks,
> ScottJ
>
> On Mon, 22 Jul 2024, Nordgren, Bryce - FS, MT wrote:
>
>> Just spitballing, but instead of a new TLD, what about
>> "{earth,moon,mars}.sol.arpa" as your suffix?
>> This seems like it's right in the wheelhouse of the "Address Resolution
>> Parameter Area"...
>> https://en.wikipedia.org/wiki/.arpa
>> Forest Service Shield
>> Bryce Nordgren, FRIT
>> Physical Scientist
>> Forest Service
>> Missoula Fire Science Lab
>> p: 406-829-6955
>> c: 406-396-4147
>> bryce.l.nordg...@usda.gov
>> 5775 Hwy 10 W
>> Missoula, MT 59808
>> www.fs.fed.us
>> USDA Logo Forest Service Twitter USDA Facebook
>> Caring for the land and serving people
>>
>>
>> ___
>> From: Scott Johnson
>> Sent: Monday, July 22, 2024 3:00 AM
>> To: d...@ietf.org ; dnsop@ietf.org
>> Cc: ipnsig...@googlegroups.com ;
>> awg-ipn...@googlegroups.com
>> Subject: [dtn] An Interplanetary DNS Model
>> Hi Everyone,
>> Sorry for the 4-way cross posting, but I wanted to reach all of those
>> parties who may have interest.
>> I have published an internet-draft version of a document I have been
>> privately publishing, in order that the community may understand, pick
>> apart, improve, and fill in the blanks. This is in response to
>> community
>> interest and related efforts, in order that we best arrive at a
>> standardized practice and architecture for Interplanetary Internet
>> communications. I welcome and look forward to comments which could
>> help
>> us reach this laudable goal. I am not sure of the exact venue for WG
>> adoption, given the scope of the concepts. As such will I refrain from
>> asking for WG adoption at this time, pending discussion from the DTN
>> and
>> DNS communities.
>> Please find the draft here:
>> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
>> tracker.ietf.org%2Fdoc%2Fdraft-johnson-interplanetary-dns%2F&data=05%
>> 7C02%7Cbryce.l.nordgren%40usda.gov%7Ca6aa16d3a3434c34031208dcaa2d44ba
>> %7Ced5b36e701ee4ebc867ee03cfa0d4697%7C1%7C0%7C638572358631001081%7CUn
>> known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
>> WwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=BTPmN%2B7FDxrLZPRDDZZoD6YNKHG1d5
>> ROtFlDjqZg1Vs%3D&reserved=0
>> I would also be interested in revisiting Marc Blanchet's smtp and http
>> over BP related drafts in the light of the above document, to see if
>> adaptation can be made to make these efforts dovetail together.
>> Thanks to all,
>> Scott Johnson
>> Spacely Packets, LCC
>> ___
>> dtn mailing list -- d...@ietf.org
>> To unsubscribe send an email to dtn-le...@ietf.org
>> This electronic message contains information generated by the USDA
>> solely for the intended recipients. Any unauthorized interception of
>> this message or the use or disclosure of the information it contains
>> may violate the law and subject the violator to civil or criminal
>> penalties. If you believe you have received this message in error,
>> please notify the sender and delete the email immediately.
> ___
> DNSOP mailing list -- dnsop@ietf.org
> To unsubscribe send an email to dnsop-le...@ietf.org
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: I-D Action: draft-zhang-dnsop-ns-selection-00.txt
This is a nit, but an important one. The draft uses IP addresses that are not from the EXAMPLE-NET (and friends). Also I would suggest to use example IPv6 addresses () in the draft instead of the Legacy IP addresses (A) (e.g. RFC 3849). Please don't do that, 100.1.1.1 belongs to Verizon Business and 200.1.1.1 is Corporacion Andina de Fomento. Thanks, Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 2. 7. 2024, at 23:47, Davey Song wrote: > > Hi folks, > > I noticed the momentum on DNS load balancing and NS selection topics. Our > co-authors have just compiled a draft summarizing the research findings and > best practices in this field, and made some recommendations for developers on > secure and robust NS selection algorithms. Comments are welcome. > > Davey > -- Forwarded message - > From: > Date: Wed, Jul 3, 2024 at 2:19 PM > Subject: I-D Action: draft-zhang-dnsop-ns-selection-00.txt > To: > > > Internet-Draft draft-zhang-dnsop-ns-selection-00.txt is now available. > >Title: Secure Nameserver Selection Algorithm for DNS Resolvers >Authors: Fenglu Zhang > Baojun Liu > Linjian Song > Shumon Huque >Name:draft-zhang-dnsop-ns-selection-00.txt >Pages: 18 >Dates: 2024-07-02 > > Abstract: > >Nameserver selection algorithms employed by DNS resolvers are not >currently standardized in the DNS protocol, and this has lead to >variation in the methods being used by implementations in the field. >Recent research has shown that some of these implementations suffer >from significant security vulnerabilities. This document provides an >in-depth analysis of nameserver selection utilized by mainstream DNS >software and summarizes uncovered vulnerabilities. Furthermore, it >provides recommendations to defend against these security and >availability risks. Designers and operators of recursive resolvers >can adopt these recommendations to improve the security and stability >of the DNS. > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-zhang-dnsop-ns-selection/ > > There is also an HTMLized version available at: > https://datatracker.ietf.org/doc/html/draft-zhang-dnsop-ns-selection-00 > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > > > ___ > I-D-Announce mailing list -- i-d-annou...@ietf.org > To unsubscribe send an email to i-d-announce-le...@ietf.org > ___ > DNSOP mailing list -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: Stateless Hash-Based Signatures in Merkle Tree Ladder Mode (SLH-DSA-MTL) for DNSSEC
To be perfectly clear: I think this is a major flaw in the proposal that needs to be addressed and not something to be just discussed in the “section” of the draft before the implementors start even looking at the possibility of implementing the MTL mode. I’ve raised this immediately when the MTL mode was first presented to the implementors during IETF in Prague, I’ve sent you this feedback on 24.05.2024 in a personal email to the Verisign researchers. I don’t feel heard as the only feedback I got was whether ISC would join hackathon to implement the MTL mode in BIND 9. My view is that an ability to attacker to make the resolver do expensive work is total red flag. Attackers can contain a fleet of domains, each with own DNSSEC keys. What about an on-path attacker - that’s suddenly an attack that can cause DoS for all the domains and users as the resources will be exhausted to fetch the large keys. What about an off-path attacker, can an attacker cause the new fetch? Repeatedly? A resistance against the repeated key refetching needs to be built into the protocol, and I am not convinced that just putting limits on frequency is going to be enough. There are variants to this - can an attacker make the resolver to download and validate many keys through chained queries through different domain names each with own key with zero TTL? Repeatedly? I would like to have a path to PQC for DNSSEC, but my experience with implementing DNS and defending it against attackers (and clever researchers alike) tells me that we are not there yet with this proposal. Convince me that I am wrong. Ondrej -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 15. 7. 2024, at 17:49, Harvey, Joseph > wrote: > Hello Ondřej > > Thank you for taking the time to review the documents and provide feedback. > You make a very interesting observation that a malicious server operator > could force a validating resolver to always fetch the larger full signature > to validate (or try to validate in the case of bad signatures) the signatures. > > Our submitted draft is a work in progress, and we agree that there should be > discussion in the draft on this and other potential scenarios, risks, and > mitigations. We will add a section to the draft for that purpose including > discussion around this issue. > > We will keep you posted on the future updates and welcome any other feedback > you may have as this draft evolves. > > Regards, >Joe Harvey > > > > -Original Message- >> From: Ondřej Surý mailto:ond...@isc.org>> >> Sent: Wednesday, July 10, 2024 9:43 AM >> To: dnsop@ietf.org <mailto:dnsop@ietf.org> >> Subject: [EXTERNAL] [DNSOP] Stateless Hash-Based Signatures in Merkle Tree >> Ladder Mode (SLH-DSA-MTL) for DNSSEC >> >> Caution: This email originated from outside the organization. Do not click >> links >> or open attachments unless you recognize the sender and know the content is >> safe. >> >> Hi, >> >> since draft-fregly-dnsop-slh-dsa-mtl-dnssec-02 and draft-harvey-cfrg-mtl- >> mode-03 have been published now, I would like to discuss something I noticed >> when this was first brought to my attention during IETF in Prague. >> >> The Section 6.2 says: >> >>> As described in 9.2 of [I-D.harvey-cfrg-mtl-mode], when a verifier >>> receives a condensed signature, the verifier determines whether any of >>> the MTLs it has previously verified includes a rung that is compatible >>> with the authentication path in the condensed signature. If not, then the >> verifier requests a new signed ladder. >> [...] >>> Accordingly, a resolver SHOULD first query a name server without the >>> mtl-mode-full option, and then, if needed, re-issue the query with the >>> mtl-mode-full option. Since responses to queries with the >>> mtl-mode-full option are expected to be large, it is RECOMMENDED that >>> queries with the mtl-mode-full option be issued over transports (e.g., >>> TCP, >> TLS, QUIC) that support large responses without truncation and/or >> fragmentation. >> >> I have pointed out that a malicious zone operator can return a different run >> effectively making the resolver request a new signed ladder every time. This >> effectively removes any benefit that the resolvers gain from using the MTL >> mode. >> >> Again, if I am understanding the protocol correctly, it should be even >> possible >> to pre-generate the different answers and just mess with the resolver by >> invalidating the previous
[DNSOP] Re: draft-fujiwara-dnsop-dns-upper-limit-values
> On 10. 7. 2024, at 15:36, Yorgos Thessalonikefs wrote: > > In general having limits in an RFC that people can point to goes a long way > than developers trying to argue with users; for example on what a sensible > length of a CNAME chain is. I agree with this rationale, but I would rather frame any document more like “if you are doing this things might not work” rather than saying “these are hard limits”. In any case, any document like this is doomed to fail unless you can get the DNS Silos to sign it with their own blood, because any rational argument will be shot down with “but it works with …”. Ondrej -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Stateless Hash-Based Signatures in Merkle Tree Ladder Mode (SLH-DSA-MTL) for DNSSEC
Hi, since draft-fregly-dnsop-slh-dsa-mtl-dnssec-02 and draft-harvey-cfrg-mtl-mode-03 have been published now, I would like to discuss something I noticed when this was first brought to my attention during IETF in Prague. The Section 6.2 says: > As described in 9.2 of [I-D.harvey-cfrg-mtl-mode], when a verifier receives a > condensed signature, > the verifier determines whether any of the MTLs it has previously verified > includes a rung that is > compatible with the authentication path in the condensed signature. If not, > then the verifier requests > a new signed ladder. [...] > Accordingly, a resolver SHOULD first query a name server without the > mtl-mode-full option, and then, > if needed, re-issue the query with the mtl-mode-full option. Since responses > to queries with > the mtl-mode-full option are expected to be large, it is RECOMMENDED that > queries with > the mtl-mode-full option be issued over transports (e.g., TCP, TLS, QUIC) > that support large > responses without truncation and/or fragmentation. I have pointed out that a malicious zone operator can return a different run effectively making the resolver request a new signed ladder every time. This effectively removes any benefit that the resolvers gain from using the MTL mode. Again, if I am understanding the protocol correctly, it should be even possible to pre-generate the different answers and just mess with the resolver by invalidating the previously received response by using low TTL numbers and providing different answers every time. Please correct me if I am wrong. Cheers, Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
Re: [DNSOP] New Version Notification for draft-bellis-dnsop-qdcount-is-one-00.txt
Given the uneasy history with firewall implementors, I think it would be best to expand the document to explicitly say somewhere that messages with QDCOUNT=0 are valid. The assumption is implicit in the document, but I've already lost faith in humanity :). Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 17. 2. 2023, at 17:20, Ray Bellis wrote: > > Forwarded Message > Subject: New Version Notification for draft-bellis-dnsop-qdcount-is-one-00.txt > Date: Fri, 17 Feb 2023 08:12:18 -0800 > From: internet-dra...@ietf.org > To: Joe Abley , Ray Bellis > > > A new version of I-D, draft-bellis-dnsop-qdcount-is-one-00.txt > has been successfully submitted by Ray Bellis and posted to the > IETF repository. > > Name: draft-bellis-dnsop-qdcount-is-one > Revision: 00 > Title: In the DNS, QDCOUNT is (usually) One > Document date: 2023-02-17 > Group: Individual Submission > Pages: 6 > URL: https://www.ietf.org/archive/id/draft-bellis-dnsop-qdcount-is-one-00.txt > Status: https://datatracker.ietf.org/doc/draft-bellis-dnsop-qdcount-is-one/ > Html: > https://www.ietf.org/archive/id/draft-bellis-dnsop-qdcount-is-one-00.html > Htmlized: > https://datatracker.ietf.org/doc/html/draft-bellis-dnsop-qdcount-is-one > > > Abstract: > This document clarifies the allowable values of the QDCOUNT parameter > in DNS messages with OPCODE = 0 (QUERY) and specifies the required > behaviour when values that are not allowed are encountered. > > > > The IETF Secretariat > > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Implementor's status on draft-ietf-dnsop-avoid-fragmentation: BIND 9
Tim,I think I’ve just did that in the previous email. I feel that gathering information about more implementations first would be better, so the section on Implementation could be uniform for all gathered input.Ondrej--Ondřej Surý — ISC (He/Him)My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.On 24. 1. 2023, at 15:47, Tim Wicinski wrote:The chairs thank all for this feedback, even at this stage. But it's better to catch these issues now, than later on in the process. On Fri, Jan 20, 2023 at 3:52 PM Ondřej Surý <ond...@isc.org> wrote:I am indifferent about what label we stick on this, but perhaps the document should have a section on implementations? However, I do feel that the Security Considerations is missing on the risks of dropping packets, ICMP filtering and dangers of PMTUD. Also it feels weird to me that the IP_PMTUDISC_OMIT is used by: BIND 9, NSD, Unbound, Knot DNS and PowerDNS, but neither the fact nor the reasoning behind the option is ever mentioned here. Hence, I think the Implementors section should be added to the document.an Implementation Section would be useful and generally they appear as an Appendix. Ondrej, if you could suggest some text with what ISC will implement, along with any reasoning, that would be a great start.tim ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Implementor's status on draft-ietf-dnsop-avoid-fragmentation: BIND 9
I am indifferent about what label we stick on this, but perhaps the document should have a section on implementations? However, I do feel that the Security Considerations is missing on the risks of dropping packets, ICMP filtering and dangers of PMTUD. Also it feels weird to me that the IP_PMTUDISC_OMIT is used by: BIND 9, NSD, Unbound, Knot DNS and PowerDNS, but neither the fact nor the reasoning behind the option is ever mentioned here. Hence, I think the Implementors section should be added to the document. Ondrej -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 20. 1. 2023, at 16:20, Paul Hoffman wrote: > > Given the long list of things in this document that ISC has thought about > and actively decided not to do, is it a good idea that we call it a "best > current practice"? > > --Paul Hoffman > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Implementor's status on draft-ietf-dnsop-avoid-fragmentation: BIND 9
Dear WG and authors, here's an status of UDP fragmentation mitigations in BIND 9 as of now. > 3.1. Recommendations for UDP responders > • UDP responders SHOULD send DNS responses without "Fragment header" > [RFC8200] on IPv6. > • UDP responders are RECOMMENDED to set IP "Don't Fragment flag (DF) bit" > [RFC0791] on IPv4. We don't do that and we don't ever plan to implement this. BIND 9 sets IP_MTU_DISCOVER to IP_PMTUDISC_OMIT[a] with fallback to IP_PMTUDISC_DONT on Linux. On systems with IP_DONTFRAG (FreeBSD), we disable IP_DONTFRAG. (See my remark about PMTUD below...) > • UDP responders SHOULD compose response packets that fit in both the > offered requestor's maximum UDP payload size [RFC6891], the interface MTU, > and the RECOMMENDED maximum DNS/UDP payload size 1400.¶ The default EDNS0 buffer size is 1232, we don't allow sizes smaller than 512 and larger than 4096. We honour the requestor's size up to the configured limit (`max-udp-size`). > • If the UDP responder detects an immediate error that the UDP packet > cannot be sent beyond the path MTU size (EMSGSIZE), the UDP responder MAY > recreate response packets fit in path MTU size, or TC bit set.¶ If the send fails with EMSGSIZE, we set the TC and try to send minimal answer again. > • UDP responders SHOULD limit response size when UDP responders are > located on small MTU (<1500) networks. I don't know what this means. And how is this related to the previous recommendation to limit the response size under "1400". > 3.2. Recommendations for UDP requestors > • UDP requestors SHOULD limit the requestor's maximum UDP payload size to > the RECOMMENDED size of 1400 or smaller size.¶ The default is 1232 (`edns-buf-size`) > • UDP requestors MAY drop fragmented DNS/UDP responses without IP > reassembly to avoid cache poisoning attacks.¶ We don't do that and we don't plan to do that. > • DNS responses may be dropped by IP fragmentation. Upon a timeout, to > avoid name resolution fails, UDP requestors MAY retry using TCP or UDP with a > smaller requestor's maximum UDP payload size per local policy.¶ The fallback to TCP has been already implemented (after two UDP timeouts) > When avoiding fragmentation, a DNS/UDP requestor behind a small-MTU network > may experience UDP timeouts which would reduce performance and which may lead > to TCP fallback. This would indicate prior reliance upon IP fragmentation, > which is universally considered to be harmful to both the performance and > stability of applications, endpoints, and gateways. Avoiding IP fragmentation > will improve operating conditions overall, and the performance of DNS/TCP has > increased and will continue to increase. I kind of feel this misses the other side - if there's a UDP timeout (for any reason), it also increases the attack window for poisoning the requestor's cache. Thus if a UDP response is dropped along the way because it's too big, it does come with a cost. The document and the security consideration also completely avoids the fact that accepting PMTUD for UDP is also considered harmful and dangerous -> which resulted in IP_PMTUDISC_OMIT in the Linux kernel (and similar technique in FreeBSD AFAIK). Notes: a. The option is available since Linux 3.15 - released in 2014, so it should be available virtually everywhere except some really old stuff. Even RHEL/CentOS 7 has backported this to their 3.10 kernel. Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Fwd: Working Group Last Call for draft-ietf-dnsop-rfc5933-bis
Didn’t we also agree to have Implementation Status in the drafts?
There probably should be such section covering both crypto library support
(OpenSSL is deprecating “engines” in favor of new “providers”).
This would be useful to both help the implementors decide whether it even
makes sense to implement the new algorithm and also understand even
whether the DNS server implementors are going to add support for GOST-2012
into their software.
Given the GOST-2001 fiasco, speaking with my ISC BIND 9 hat, I don’t feel
very motivated to do anything to add support for an algorithm that needs extra
OpenSSL engine to even work and then support the code for years while
the deployment is going to be again either national or none at all.
Adding new algorithms to DNSSEC should be driven by cryptographic needs,
and honestly how is this better than existing algorithms in DNSSEC?
I would expect the next DNSSEC algorithm is going to be quantum-resistant
which would bring benefit to the DNS and Internet, and not something produced
by a nation.
Ondrej
--
Ondřej Surý (He/Him)
ond...@isc.org
My working hours and your working hours may be different. Please do not feel
obligated to reply outside your normal working hours.
> On 15. 4. 2022, at 0:19, Michael StJohns wrote:
>
> On 4/14/2022 5:09 PM, Paul Hoffman wrote:
>> On Feb 1, 2022, at 12:35 PM, Tim Wicinski wrote:
>>> We were reviewing the Working Group Last Call for this, and we received no
>>> comments. We know there was interest in at least moving this forward, but
>>> even Warren concurred we can't send this to the IESG unless there are folks
>>> saying they feel it is ready to be published.
>> That was a few months ago. There were only two responses, one negative, one
>> blandly positive ("seems reasonable").
>
> Hi Paul -
>
> Needs work is not a negative, it's a "not yet ready". I don't have a problem
> with the publication of such a document, and I agree with Russ that the
> changes between this and RFC5933 are reasonable - but RFC5933 isn't a model
> of clarity itself and shouldn't be used as justification to publish this
> document. So "needs work" not "ready for publication"
>
> Mike
>
>
>
>>
>> Can the chairs please say what they expect to do with this draft? I ask
>> because it is directly relevant to draft-ietf-dnsop-dnssec-bcp, where the
>> draft's predecessor is mentioned.
>>
>> --Paul Hoffman
>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [secdir] Secdir last call review of draft-ietf-dnsop-server-cookies-04
Hi Benjamin, I did not used appeal to authority as an argument, but I’ve just provided examples that SipHash has been implemented in the similar scenarios and there hasn’t been reported issue with the choice for years now. Using fast PRF (pseudorandom function) for the DNS Cookies is a good choice because it matches the required properties - it needs to be fast and secure in a sense that attacker can’t compute neither the key nor the output of the function. DNS Cookies are not MACs. Sorry for the misnomer of the brute force - what I meant was a protection against a replay attack. I’m just currently very tired with day to day job. Please note that DNS Cookies doesn’t protect the actual DNS message payload, it merely provide means to establish trust between the client and the server as to distinguish between a legitimate and spoofed traffic, so different policies can be used - Response Rate Limiting (RRL) could be turned off for DNS messages with cookies or when under attack it could require fallback to TCP for DNS queries without the DNS Cookie. The DNS cookies doesn’t protect the actual content in any way, neither it does protect the communication from the on path adversary. In that regard, the client cookie is just nonce (and it’s just convenient to use same algorithm to generate it, but it could be output from CSPRNG as well) and the server cookie is a cryptographic primitive that uses the client nonce, key and timestamp to construct the server cookie. Such server cookie is used by the DNS client to authenticate to the server (it’s shared secret, but it requires no per-client state on the server). Just to repeat, the actual payload (DNS message) is not protected by the DNS cookie. If the DNS server could keep a state for every DNS client, a CS random number would be as good as the output of the SipHash. I might not be a cryptographer as my daily job, but I am reasonably confident that SipHash has matching properties, it hasn’t been broken as of today. Also all DNS vendors have agreed to make this choice and the RFC here is merely a way how to ensure interoperability between various implementations. (Typing this on phone, so excuse any irregularities in the text.) Ondrej -- Ondřej Surý — ISC (He/Him) > On 4. 12. 2020, at 21:37, Benjamin Kaduk wrote: > > Hi Ondřej, > > Just because someone else does something, even a "big name", doesn't > necessarily make it a good idea for us to also do it. > We should be able to justify our algorithm choices on cryptographic > principles, not just appeal to authority. > > In a similar vein, you said something about the 32-bit timestamp being wide > enough to prevent brute-force attacks. Could you say a bit more about what > attacks those are that are being prevented? I'm not really seeing how the > width of the timestamp comes into play for that concern, just from a quick > skim of the document. (Timestamps tend to not provide much protection > against brute force by themselves, since time is relatively guessable, > especially to seconds precision.) > > Thanks, > > Ben > >> On Wed, Dec 02, 2020 at 11:18:29PM +0100, Ondřej Surý wrote: >> SYN cookies in both Linux and FreeBSD uses siphash. >> >> * FreeBSD: https://svnweb.freebsd.org/base?view=revision&revision=253210 >> (since 2013) >> * Linux: >> https://github.com/torvalds/linux/commit/fe62d05b295bde037fa324767674540907c89362#diff-14feef60c3dbcf67539f089de04546c907233cbae09e1b2dd2c2bc6d6eae4416 >> (since 2017) >> >> I believe that the SYN cookies have exactly the same properties as DNS >> cookies. >> >> Ondrej >> -- >> Ondřej Surý (He/Him) >> ond...@isc.org >> >>>> On 2. 12. 2020, at 22:15, Eric Rescorla wrote: >>> >>> Well hash tables are an application with somewhat different security >>> properties than MACs, so I don't think this is dispositive. >>> >> >> ___ >> secdir mailing list >> sec...@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir >> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [secdir] Secdir last call review of draft-ietf-dnsop-server-cookies-04
SYN cookies in both Linux and FreeBSD uses siphash. * FreeBSD: https://svnweb.freebsd.org/base?view=revision&revision=253210 (since 2013) * Linux: https://github.com/torvalds/linux/commit/fe62d05b295bde037fa324767674540907c89362#diff-14feef60c3dbcf67539f089de04546c907233cbae09e1b2dd2c2bc6d6eae4416 (since 2017) I believe that the SYN cookies have exactly the same properties as DNS cookies. Ondrej -- Ondřej Surý (He/Him) ond...@isc.org > On 2. 12. 2020, at 22:15, Eric Rescorla wrote: > > Well hash tables are an application with somewhat different security > properties than MACs, so I don't think this is dispositive. > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Secdir last call review of draft-ietf-dnsop-server-cookies-04
Stephen, ad 1) the performance is crucial for DNS over UDP and PRF such as SipHash is more efficient than HMACs. No, it wasn’t consulted with CFRG, and I can’t speak for Willem, but I am confident enough to make the decision. SipHash is widely used for hash tables virtually anywhere now. ad 2) we need a value that’s synchronized well enough and monotonic. I honestly don’t see any value in using 64-bit value here. Using unixtime has a value in itself, it’s a well-known and there’s a little room for any implementor to make a mistake in an implementation. The interoperability is more important than the actual value of the counter. It’s write only counter, nobody is going to interpret it after it has been generated, and it’s wide enough to prevent brute forcing. Cheers, Ondřej -- Ondřej Surý — ISC (He/Him) > On 2. 12. 2020, at 18:47, Stephen Farrell via Datatracker > wrote: > > Reviewer: Stephen Farrell > Review result: Has Issues > > I see two issues here worth checking: > > 1. I don't recall SipHash being used as a MAC in > any IETF standard before. We normally use HMAC, > even if truncated. Why make this change and was > that checked with e.g. CFRG? (And the URL given > in the reference gets me a 404.) > > 2. Is it really a good idea to use a 32 bit seconds > since 1970-01-01 in 2020? I'd have thought that e.g. > a timestamp in hours since then or seconds since > some date in 2020 would be better. > > Here's a couple of nits too: > - section 1: what's a "strong cookie"? > - "gallimaufry" - cute! but not sure it'll help readers to learn that word. > > > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis
I just want to point out, that I am certainly not overthinking this with my implementors hat. The RFC and code-point puts pressure on the DNS vendors to actually implement this „because there’s RFC“. The whole reason for standardization is that there’s interoperatibility between the implementations - and just giving the code points without implementing this hardly fulfills that requirement. Sure, I can ignore the new GOST code point in BIND 9, but that becomes harder when either one of the other open source implementations or one of the big DNS silos will actually do the implementation. So, it’s definitively not „just giving the code point“, it has implications for some of us. Ondrej -- Ondřej Surý (He/Him) ond...@isc.org > On 18 Jun 2020, at 17:36, Jim Reid wrote: > > I think we’re over-thinking this. Just issue new code point(s) for the new > algorithm(s) and be done with it. > > IMO there’s no need for the WG or the IETF to make any statements about the > suitability of the underlying crypto used for optional signing and > validation. That’s largely a matter for those who use these algorithms. > Higher-level concerns about the crypto’s suitability should only come into > play whenever an algorithm is a MUST/SHOULD recommendation in a > standards-track RFC. > > Maybe we need an RFC6895-like process for maintaining this IANA registry, > like we have for RRtype codes? > signature.asc Description: Message signed with OpenPGP ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-belyavskiy-rfc5933-bis
Hi, I do not hold as strong position as Olafur here, but I concur that the document needs much better rationale. There’s no rationale for adopting the new GOST algorithm at the moment and I would especially like to hear why GOST 2012 should be standardized and EC-KCDSA (Korean) and ECGDSA (German) should not. I specifically think that we should only standardize algorithms recommended by cfrg such as RFC 7748 or RFC 8439 (just example, not applicable). I consider the previous GOST standardization for DNSSEC to be a fiasco. I would also ask the WG to require a implementation report before we send this to WGLC. The support for GOST family of algorithms varies between the various crypto libraries. I found it problematic for the DNS vendors that OpenSSL supports the algs only in form of OpenSSL engine, and that said engine had last release in 2018. The project activity looks fine, but issues like this[1] don’t exactly fill me with trust, but at least there’s an active maintainer for the project. As of the adoption - I am indifferent, the things I mentioned could be done with or without WG adopting the document, but I think that the document should not become a RFC (not even Informational) before the items I mentioned are cleared. 1. https://github.com/gost-engine/engine/issues/91 Ondrej -- Ondřej Surý ond...@isc.org > On 16 Jun 2020, at 04:42, Olafur Gudmundsson wrote: > > > Thom > As I have before stated in the past, adding new DNSSEC algorithm is bad for > interoperability, > I oppose the adoption of this document unless there are better reasons put > forward why this algorithm is better than > the 4 ECC algorithms that have been standardized so far. > Better in this case could be stronger, faster, better post-quantum resistance > etc > > Also I want to point out this last call did not specify track so my > opposition is against all tracks, at this point. > > Olafur > > > > >> On Jun 3, 2020, at 5:07 PM, Tim Wicinski wrote: >> >> >> All, >> >> As we stated in the meeting and in our chairs actions, we're going to run >> regular call for adoptions over next few months. >> We are looking for *explicit* support for adoption. >> >> >> This starts a Call for Adoption for draft-belyavskiy-rfc5933-bis >> >> The draft is available here: >> https://datatracker.ietf.org/doc/draft-belyavskiy-rfc5933-bis/ >> >> Please review this draft to see if you think it is suitable for adoption >> by DNSOP, and comments to the list, clearly stating your view. >> >> Please also indicate if you are willing to contribute text, review, etc. >> >> This call for adoption ends: 15 June 2020 >> >> Thanks, >> tim wicinski >> DNSOP co-chair >> >> >> >> ___ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop signature.asc Description: Message signed with OpenPGP ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Fwd: New Version Notification for draft-sury-deprecate-obsolete-resource-records-01.txt
Hi, I still would like to continue with this and I still think it’s a no brainer and I know this is super uninteresting to anyone but the DNS software vendors. But I do have a question for the WG - should we add a text that would allow the “Expert Review” to formally DEPRECATE (as defined in this I-D) other RRTYPEs? This would make things much simpler in the future when we want to formally cleanup more obsoleted records (like NINFO and RKEY, etc...). Ondrej -- Ondřej Surý ond...@isc.org > Begin forwarded message: > > From: internet-dra...@ietf.org > Subject: New Version Notification for > draft-sury-deprecate-obsolete-resource-records-01.txt > Date: 13 May 2019 at 10:58:27 GMT+7 > To: "Evan Hunt" , "Ondrej Sury" > > > A new version of I-D, draft-sury-deprecate-obsolete-resource-records-01.txt > has been successfully submitted by Ondrej Sury and posted to the > IETF repository. > > Name: draft-sury-deprecate-obsolete-resource-records > Revision: 01 > Title:Deprecating obsolete DNS Resource Records Types > Document date:2019-05-13 > Group:Individual Submission > Pages:5 > URL: > https://www.ietf.org/internet-drafts/draft-sury-deprecate-obsolete-resource-records-01.txt > Status: > https://datatracker.ietf.org/doc/draft-sury-deprecate-obsolete-resource-records/ > Htmlized: > https://tools.ietf.org/html/draft-sury-deprecate-obsolete-resource-records-01 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-sury-deprecate-obsolete-resource-records > Diff: > https://www.ietf.org/rfcdiff?url2=draft-sury-deprecate-obsolete-resource-records-01 > > Abstract: > This document deprecates Resource Records (RR) Types that are either > not being used for anything meaningful or were been already made > obsolete by other RFCs. This document updates [RFC1035], [RFC1035], > [RFC4034]. > > > > > 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 > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] ANAME high-level benefit question
Also, I would argue that the ability to run ANAME at your own infrastructure might drive less people to the “managed DNS” land or allow them to migrate away without a significant loss of functionality. One way or another, ANAME-like behaviour became defacto industry standard and we need to have a solution on a protocol level. Ondrej -- Ondřej Surý ond...@isc.org > On 11 May 2019, at 16:34, Ray Bellis wrote: > > > > On 11/05/2019 15:54, Dave Lawrence wrote: > >> I have a related question ... is allowing only targets on their own >> infrastructure currently a limitation most such providers have? > > I don't know about "most", but certainly some. See e.g. the attached > message posted here 2018/06/25. > > Ray > > <[DNSOP] abandoning ANAME and standardizing CNAME at > apex.eml>___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-song-atr-large-resp
> On 21 Jan 2019, at 11:22, Peter van Dijk wrote: > > Signed PGP part > Hello, > > On 18 Jan 2019, at 18:55, Benno Overeinder wrote: > >> We discussed this work (draft -01) in Montreal, and different opinions wrt. >> adoption were expressed. In the past months, the authors pushed a draft >> version -02 that addressed and resolved some of these comments. >> >> This starts a Call for Adoption for: >> draft-song-atr-large-resp >> >> The draft is available here: >> https://datatracker.ietf.org/doc/draft-song-atr-large-resp/ >> >> Please review this draft to see if you think it is suitable for adoption by >> DNSOP, and comments to the list, clearly stating your view. >> >> Please also indicate if you are willing to contribute text, review, etc. >> The WG accepts the document or not, but the WG chairs also expect a >> commitment from the WG participants who support the document to contribute >> to the draft, review, etc. >> >> The intended status of the draft is Experimental, but we want to ask >> developers/vendors if they plan to implement it. >> >> This call for adoption ends: 1 February 2019 > > I oppose adoption. Any implementation of this draft will actively hurt the > DNS and the Internet, and thus publication as an RFC will actively hurt the > DNS and the Internet. > > The draft doubles the number of packets involved in a legitimate exchange; it > more than doubles the number of packets involved in a spoofed exchange. About > half of these packets are ICMP packets. Without the draft, ICMP packets are > useful debugging aids, and in big numbers, indications of attacks or > operational problems. With the draft, ICMP becomes another useless source of > background noise. > > Meanwhile, we have no indication that the draft solves any existing real > world problem in a useful way. > > Please do not adopt. +1 to everything that Peter said. I’ve been opposing ATR draft from the very beginning. We can’t be removing EDNS workarounds and at the same time slap another workaround into the DNS. Ondrej -- Ondřej Surý ond...@isc.org signature.asc Description: Message signed with OpenPGP ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Time to update RSAMD5 and perhaps DSA (algs 1 and 3) to MUST NOT?
Viktor, apart from the I-D in the LC, the upcoming BIND 9.14 release will have: * GOST removed (as it was deprecated by Russian “upstream”) * Both DSA algorithms removed (insecure) * RSAMD5 algorithm to be removed (I just finished the MR and it needs to be reviewed: https://gitlab.isc.org/isc-projects/bind9/merge_requests/1106) Ondrej -- Ondřej Surý ond...@isc.org > On 1 Dec 2018, at 20:51, Viktor Dukhovni wrote: > > The IANA DNSSEC parameter registry lists RSAMD5 (algorithm 1) as > deprecated, and refers to [RFC3110], [RFC4034] which state that > RSAMD5 is "NOT RECOMMENDED". > > > https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml#dns-sec-alg-numbers-1 > > "Survey says" that RSAMD5 is not only deprecated, but is in fact > no longer used, by any of the ~9 million DNSSEC-delegated domains > I've been able to find on the public Internet: > > > https://lists.dns-oarc.net/pipermail/dns-operations/2018-December/018146.html > > It only has the effect of breaking two domains that have only RSAMD5 > in the DS RRset, but have no DNSKEY RRs. 11 domains, have working > keys for algorithms 5, 7, 8 or 13 with a DS RRset that also lists > an orphaned algorithm 1 with no RSAMD5 keys at the zone apex. A > further 18 domains have RSAMD5 DS RRs, but are simply out of service > even sans validation. > > This suggests to me that the deprecation of RSAMD5 is a stunning > success, it is gone, and perhaps it is time to say so: > >* Authoritative zones SHOULD NOT publish RSAMD5 DS RRs or > DNSKEY records. > >* Validating resolvers MUST ignore RSAMD5 DS RRs and DNSKEY > RRs, and MUST treat any zones with only ignored or unsupported > DS records as "insecure". > > Perhaps we could be bolder and say the same for DSA (algorithm 3), > this too is largely gone, but there's a cluster of ~4700 ".me" > domains with DSA keys. It is not clear that enabling those domains > to validate merits ongoing support for algorithm 3. So we might > also add DSA to the list, encouraging resolver implementations to > drop support for both RSAMD5 and DSA. > > -- > Viktor. > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-algorithm-update-03.txt
Dick, good catch! Tim, do you want me to publish -04 addressing this or would it be better to fix this in RFC Editor queue. The diff is simple: https://github.com/oerdnj/draft-ietf-dnsop-algorithm-update/commit/7164f8a6ee4b210f5d83684156cb2905769f7fb4#diff-e9d2d55442440292530838192590a871 O. -- Ondřej Surý ond...@isc.org > On 23 Oct 2018, at 22:37, Dick Franks wrote: > > On Tue, 23 Oct 2018 at 19:34, Tim Wicinski wrote: > > The WGLC has completed and we were waiting on the authors on addressing all > comments and updating their document. > The chairs feel this is ready to proceed. > > Just spotted a fumble with document references in section 3.1 which will need > to be fixed before this is put to bed. > > [3.1, para 6] reads: >ECC-GOST (GOST R 34.11-94) has been superseded by GOST R 34.11-2012 >in [ > RFC6986 > ]. The GOST R 34.11-2012 hasn't been standardized for use >in DNSSEC. > > should read: >ECC-GOST (GOST R 34.10-2001) has been superseded by GOST R 34.10-2012 >in [ > RFC7091 > ]. The GOST R 34.10-2012 hasn't been standardized for use >in DNSSEC. > > > I apologise for not having noticed this earlier. > > > -- Dick > > > > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-algorithm-update-03.txt
Dear colleagues, thank you for the valuable feedback during the WGLC. I have improved the document based on your comments and I think it’s good to go gold. Ondrej -- Ondřej Surý ond...@isc.org > On 23 Oct 2018, at 19:53, internet-dra...@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations WG of the IETF. > >Title : Algorithm Implementation Requirements and Usage > Guidance for DNSSEC >Authors : Paul Wouters > Ondrej Sury > Filename: draft-ietf-dnsop-algorithm-update-03.txt > Pages : 11 > Date: 2018-10-23 > > Abstract: > The DNSSEC protocol makes use of various cryptographic algorithms in > order to provide authentication of DNS data and proof of non- > existence. To ensure interoperability between DNS resolvers and DNS > authoritative servers, it is necessary to specify a set of algorithm > implementation requirements and usage guidelines to ensure that there > is at least one algorithm that all implementations support. This > document defines the current algorithm implementation requirements > and usage guidance for DNSSEC. This document obsoletes [RFC6944]. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-algorithm-update/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dnsop-algorithm-update-03 > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-algorithm-update-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-algorithm-update-03 > > > 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. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-algorithm-update
> On 21 Oct 2018, at 17:40, fujiw...@jprs.co.jp wrote: > >> From: Vladimír Čunát >> On 10/17/18 11:18 PM, fujiw...@jprs.co.jp wrote: >>> 4. In my opinion, Ed25519 is best algorithm some yars later. >>> If the document describes both current RECOMMENDATIONS and >>> RECOMMENDATIONS some years later, we can plan. >> >> >> I agree, but the last paragraph of 3.1 seems to express that already: > > Yes. > > # I'm afraid that some TLD/Root operators may not support ED25519 > # because it is RECOMMENDED (not MUST). The I-D already says: >It is expected that deprecation of an algorithm will be performed >gradually. This provides time for various implementations to update >their implemented algorithms while remaining interoperable. Unless >there are strong security reasons, an algorithm is expected to be >downgraded from MUST to NOT RECOMMENDED or MAY, instead of to MUST >NOT. Similarly, an algorithm that has not been mentioned as >mandatory-to-implement is expected to be introduced with a >RECOMMENDED instead of a MUST. and the last paragraph of 3.1 explicitly says: > It is > expected that ED25519 will become the future RECOMMENDED > default algorithm once there's enough support for this > algorithm in the deployed DNSSEC validators. I don’t think more handholding would be appropriate of IETF RFC. Thanks for all the comments, -- Ondřej Surý ond...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-algorithm-update
Fujiwara-san, I don’t exactly understand why such table would be better than existing text that say: > 3.2. DNSKEY Algorithm Recommendation > >Operation recommendation for new and existing deployments. > >Due to industry-wide trend to move to elliptic curve cryptography, >the ECDSAP256SHA256 is RECOMMENDED for use by new DNSSEC deployments, >and users of RSA based algorithms SHOULD upgrade to ECDSAP256SHA256. I believe this is clear enough. As for the second column, I am strongly opposed to saying what would the recommendation be in ‘2 years’. We have no idea about the deployment of Ed25519 resolvers[*], neither about RSA. But this is a type of document that needs to be regularly refreshed when needed, so we can issue another update in 2-5 years... Ondrej * - I also suspect that saying “usable” is too optimistic given that support for Ed25519 requires new OpenSSL 1.1.0 and the general glacier-speed deployments of new software. -- Ondřej Surý ond...@isc.org > On 15 Oct 2018, at 17:04, fujiw...@jprs.co.jp wrote: > > WGLC comment to draft-ietf-dnsop-algorithm-update-02 > > Section 3.2 is "recommendations for operators". > > There is texts that discuss ECDSAP256SHA256 only in section 3.2. > However, RSASHA256 is still usable. > Please add text about other algorithms. > if there is a table similar to section 3.1, it will help operators. > > For example, > choice of| choice of > sigining algorithm (now) | sigining algorithm (2 years Later) > > RSASHA1*MUST NOT| MUST NOT > RSASHA256 usable | usable/consider change to EC*/Ed* > ECDSAP256* usable | usable > Ed25519 MAY | usable > > > Regards, > > -- > Kazunori Fujiwara, JPRS > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-algorithm-update-02.txt
Colleagues, there are no functional changes to the draft. Evan Hunt improved the language, and I added Implementation Report to the document. Ondrej -- Ondřej Surý ond...@isc.org > On 14 Oct 2018, at 14:16, internet-dra...@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations WG of the IETF. > >Title : Algorithm Implementation Requirements and Usage > Guidance for DNSSEC >Authors : Paul Wouters > Ondrej Sury > Filename: draft-ietf-dnsop-algorithm-update-02.txt > Pages : 10 > Date: 2018-10-14 > > Abstract: > The DNSSEC protocol makes use of various cryptographic algorithms in > order to provide authentication of DNS data and proof of non- > existence. To ensure interoperability between DNS resolvers and DNS > authoritative servers, it is necessary to specify a set of algorithm > implementation requirements and usage guidelines to ensure that there > is at least one algorithm that all implementations support. This > document defines the current algorithm implementation requirements > and usage guidance for DNSSEC. This document obsoletes [RFC6944]. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-algorithm-update/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dnsop-algorithm-update-02 > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-algorithm-update-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-algorithm-update-02 > > > 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. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-algorithm-update
Hi Loganaden, while I understand what you are asking for, I don’t understand how it would improve the document. IETF RFCs are static and if we include any current “numbers” they quickly become invalid. Adding figures to the document doesn’t improve readability or the content. While it would support the claims we make in the document I feel that the consensus process IETF have is just fine for giving the content enough validity, and we don’t have to support every claim we make in the document with figures. Ondrej -- Ondřej Surý ond...@isc.org > On 2 Oct 2018, at 15:40, Loganaden Velvindron wrote: > > On Tue, Oct 2, 2018 at 4:51 PM Tim Wicinski wrote: >> >> >> The chairs and the authors of this document feel that the >> document is in solid shape to proceed to WGLC. >> >> >> This starts a Working Group Last Call for draft-ietf-dnsop-algorithm-update >> >> Current versions of the draft is available here: >> https://datatracker.ietf.org/doc/draft-ietf-dnsop-algorithm-update/ >> > > Section 3.1. > > " > RSASHA1 and RSASHA1-NSEC3-SHA1 are widely deployed, although zones > deploying it are recommended to switch to ECDSAP256SHA256 as there is > an industry-wide trend to move to elliptic curve cryptography. > " > > And also this paragraph: > " > > RSASHA256 is in wide use and considered strong. > > " > > My suggestion would be to include figures or at minimum a reference. > There is a document from ISOC with 3 tables where there is an analysis > of deployment DNSSEC worldwide. > > https://www.internetsociety.org/wp-content/uploads/2017/08/ISOC-State-of-DNSSEC-Deployment-2016-v1.pdf, > Page 23 & Page 24. > > >> The Current Intended Status of this document is: Proposed Standard >> >> Please review the draft and offer relevant comments. >> If this does not seem appropriate please speak out. >> If someone feels the document is *not* ready for publication, please speak >> out with your reasons. >> >> This starts a two week Working Group Last Call process, and ends on: 16 >> October 2018 >> >> thanks >> tim >> >> ___ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt
> On 31 Jul 2018, at 00:44, Paul Hoffman wrote: > > And, even if it is possible to imagine that, requiring a hash function that > has no collision attacks (like SHA-256) would suffice. Yes, that’s exactly what I had suggested in the first place. Now we have a full circle to my original message. O. -- Ondřej Surý ond...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt
Yes, thank you. Seems like the information context was lost in the translation somewhere along the way. O. -- Ondřej Surý ond...@isc.org > On 31 Jul 2018, at 00:38, Wessels, Duane wrote: > > > >> On Jul 29, 2018, at 2:03 PM, Evan Hunt wrote: >> >> On Sun, Jul 29, 2018 at 10:55:31AM +0200, Ondřej Surý wrote: >>> You need to know the hash is valid before you start the download. >>> Therefore the hash has to be signed. >> >> Before you *start* the download? Or before you use what you downloaded? > > I may be wrong, but I think Ondrej may have been referencing the idea of > using BitTorrent where you request the data by its hash value... > > DW > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt
I know some people have 40Gbps at mothers house, but for general usefulness you want to prevent downloading fake (or otherwise invalid) zone before you start downloading it. Especially, it might be very harmful if the client could be tricked into downloading any data distributed via torrent. You don’t want SWAT unit knocking down your door because your nameserver downloaded Universal Declaration of Human Rights. Ondřej -- Ondřej Surý — ISC > On 29 Jul 2018, at 23:03, Evan Hunt wrote: > >> On Sun, Jul 29, 2018 at 10:55:31AM +0200, Ondřej Surý wrote: >> You need to know the hash is valid before you start the download. >> Therefore the hash has to be signed. > > Before you *start* the download? Or before you use what you downloaded? > > -- > Evan Hunt -- e...@isc.org > Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt
Mail headers doesn’t have NSEC records. Also any operation where you need to reconstruct the file by combining bits from different places/channels is prone to errors. You need to know the hash is valid before you start the download. Therefore the hash has to be signed. O. -- Ondřej Surý — ISC On 29 Jul 2018, at 06:50, John R Levine wrote: >> Therefore either you need to exclude the data that changes (hash and its >> RRSIG) when computing the hash for the BitTorrent and the receiving side >> would have to reassemble this. Or you would need OOB mechanism to distribute >> the hash (different part of the tree, CDN, ...). > > Of course you exclude the hash record from the hash. Look at the way we do > DKIM signatures -- the header hash includes all the headers including the > signature header, but it pretends there's no hash field in it. > > I'm also thinking the hash wouldn't need to include the RRSIG records, since > those are mechanically derived from the underlying records and the ZSK. > > > Regards, > John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt
The way BitTorrent works, it’s basically a Merkle tree over the chunks. So, you need to compute the main hash over the zone data. Maybe there’s a smart way to compute hash over the data that includes that hash, but my poor brain thinks it would break the Matrix (or at least the hashing function). Therefore either you need to exclude the data that changes (hash and its RRSIG) when computing the hash for the BitTorrent and the receiving side would have to reassemble this. Or you would need OOB mechanism to distribute the hash (different part of the tree, CDN, ...). Ondřej -- Ondřej Surý — ISC > On 28 Jul 2018, at 23:58, John Levine wrote: > > In article <208f049b-b35a-4755-9a20-fa0c7f685...@isc.org> you write: >> a) the hash has to be independent to zone, so either the hash has to reside >> outside of the root zone, or the root zone file would >> have to be reconstructed with “the torrent hash” and “the torrent data”; >> generally you would want the hash to be signed, >> so the TORRENT RR + RRSIG would have to be distributed outside of the data >> received via BitTorrent > > I'm confused again. Why couldn't the hash RR and sig be in the zone > just like any other record in the zone? > > R's, > John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt
@ISC, we have been discussing this since we started implementing RZ local copy and it’s not that simple. There are at least two problems with BitTorrent: a) the hash has to be independent to zone, so either the hash has to reside outside of the root zone, or the root zone file would have to be reconstructed with “the torrent hash” and “the torrent data”; generally you would want the hash to be signed, so the TORRENT RR + RRSIG would have to be distributed outside of the data received via BitTorrent b) to be effective, most of the peers would have to seed, and I am not sure if the places that would benefit the most would be the places where operators would be willing to seed Ondrej -- Ondřej Surý — ISC > On 27 Jul 2018, at 16:57, Bob Harold wrote: > > >> On Thu, Jul 26, 2018 at 11:07 PM Mark Andrews wrote: >> >> >> > On 27 Jul 2018, at 12:39 pm, Steve Crocker wrote: >> > >> > The passage below puzzles me. Why do you want servers to get the root >> > zone from less trusted sources? >> >> 1) to spread load. >> 2) not all recursive servers have direct access to authoritative sources. >> Some times they need to go through intermediaries. The same will be true >> with transfers of the root zone. > > Maybe I am wrong, but having lots of servers all around the world asking for > the same update at the same time looks like a good place to use bittorrent. > (Is that reasonable?) So the 'sources' will be untrusted, and we do need > some way to verify the resulting file that we get.. > > I like the XHASH idea, it seems to reduce the work required on each update.. > But I would be ok with ZONEMD also. > > -- > Bob Harold > >> > And why does the source matter if the zone entries are DNSSEC-signed? >> >> Steve please go and re-read the parts you cut out when quoting the previous >> message. It gave several reasons. >> >> Also please look at what is and isn’t signed in a zone and think about what >> can be done when you can change the unsigned parts. >> >> Also think about what can be done when you change the signed parts but don’t >> individually verify the RRsets but rather just trust the zone content. >> >> I have a local copy of the root zone. It lives in a seperate view which is >> not accessed directly by clients The name server validate its contents when >> performing recursive lookups on behalf of clients. Such configurations are >> complicated and error prone. It also doesn’t remove potential privacy leaks. >> >> Having a way to verify the entire zone’s contents without having to verify >> every RRset individually after each zone transfer would make running such >> configurations easier. It also removes threats that DNSSEC alone does not >> remove. >> >> > Thanks, >> > >> > Steve >> > >> > Sent from my iPhone >> > >> >> On Jul 26, 2018, at 7:33 PM, Mark Andrews wrote: >> >> >> >> Additionally most nameservers treat zone data as fully trusted. This is >> >> reasonable when you are getting data from a “trusted" source. For the >> >> root zone we want servers to be able to get a copy of the zone from a >> >> untrusted / less trusted source. >> >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt
-- Ondřej Surý ond...@isc.org > On 26 Jul 2018, at 18:48, Paul Hoffman wrote: > > On 26 Jul 2018, at 9:43, Ondřej Surý wrote: > >>> On 26 Jul 2018, at 18:40, Wessels, Duane wrote: >>> >>> Ondrej, >>> >>> Thanks, I think thats a fair point. I was of course hoping to not create >>> yet another IANA registry. >>> >>> If the ZONEMD RR included a count of records as suggested by Paul Wouters >>> would you then be comfortable >>> just using the DS hash algorithms? >> >> That’s probably question you need to ask some cryptographer, so take my >> opinion with a grain of salt. >> >> If is the number of ZONEMD-covered records, then the probability of >> collision attack gets higher. So, unless >> I am mistaken, the delegation heavy zones would be especially susceptible to >> a collision attack. Does it make >> sense? > > If the ZONEMD record is signed, the only person who can mount a collision > attack is the zone owner themselves. If the ZONEMD record is unsigned, an > attacker can just remove it. I believe, that’s not true. The ZONEMD can stay intact while the attacker would modify the unsigned parts of the zone to create a same checksum, but different contents? He might be targeting just this particular zone and it’s delegation, so everything else is throw-away junk that can be modified. > What is the attack you are envisioning? Ondrej ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt
> On 26 Jul 2018, at 18:40, Wessels, Duane wrote: > > Ondrej, > > Thanks, I think thats a fair point. I was of course hoping to not create yet > another IANA registry. > > If the ZONEMD RR included a count of records as suggested by Paul Wouters > would you then be comfortable > just using the DS hash algorithms? That’s probably question you need to ask some cryptographer, so take my opinion with a grain of salt. If is the number of ZONEMD-covered records, then the probability of collision attack gets higher. So, unless I am mistaken, the delegation heavy zones would be especially susceptible to a collision attack. Does it make sense? Ondrej -- Ondřej Surý ond...@isc.org > DW > > >> On Jul 25, 2018, at 8:47 PM, Ondřej Surý wrote: >> >> Hi Matt, and other authors, >> >> with my cryptoplumber[1] hat, I am strongly opposed to using SHA-1 and GOST >> R 34.11-94 for ZONEMD. >> >> It is my understanding, that the specific usage of hashing function in the >> DS record improves the collision >> resistance of the algorithm, because the input data is so small and it has >> to be a valid DNSKEY record[2]. >> >> For ZONEMD, this isn’t true, as you can (in theory) feed the zone with >> infinite amount of non-DNSSEC-signed >> data (GLUEs, delegations) thus making the collision attack feasible. >> >> Thus I believe, the Section 2.1.2 must be changed to disallow usage of >> algorithms with weakened collision >> resistance (and algorithms deprecated by the Russians themselves :). It >> wouldn’t be enough just to discourage >> SHA-1 for creating the ZONEMD, but it needs to be forbidden to use it for >> validating such record. >> I think that new IANA table for ZONEMD must be established, because the >> security properties of the algorithm >> usage are different in DS and ZONEMD records. >> >> Thanks, >> Ondrej >> >> 1. I would be happy if any real cryptographer would chime in. >> >> 2. It doesn’t have to be valid DNSKEY if you just want to cause ruckus, but >> if you are able to inject invalid DS >> records, you might as well cause damage at other levels of the DNS tree. >> >> -- >> Ondřej Surý >> ond...@isc.org >> >>> On 23 May 2018, at 17:32, Weinberg, Matt >>> wrote: >>> >>> Greetings dnsop, >>> >>> We’ve posted a new version of draft-wessels-dns-zone-digest. Of note, this >>> -01 version includes the following changes: >>> >>> • Warren Kumari and Wes Hardaker have been added as coauthors. >>> • Several points of clarification in wording and descriptions. >>> • Removed the requirement to sort by RR CLASS. >>> • Added a Change Log section. >>> >>> Warren and Wes had started on a very similar but unpublished draft, which >>> we should've remembered. Thanks to them for agreeing to join this document >>> as coauthors. >>> We plan to ask for time on the dnsop agenda in Montreal. Your feedback is >>> welcome and appreciated. >>> >>> Thanks. >>> >>> >>> >>> A new version of I-D, draft-wessels-dns-zone-digest-01.txt >>> has been successfully submitted by Matt Weinberg and posted to the >>> IETF repository. >>> >>> Name: draft-wessels-dns-zone-digest >>> Revision: 01 >>> Title: Message Digest for DNS Zones >>> Document date: 2018-05-17 >>> Group: Individual Submission >>> Pages: 13 >>> URL: >>> https://www.ietf.org/internet-drafts/draft-wessels-dns-zone-digest-01.txt >>> Status: >>> https://datatracker.ietf.org/doc/draft-wessels-dns-zone-digest/ >>> Htmlized: >>> https://tools.ietf.org/html/draft-wessels-dns-zone-digest-01 >>> Htmlized: >>> https://datatracker.ietf.org/doc/html/draft-wessels-dns-zone-digest >>> Diff: >>> https://www.ietf.org/rfcdiff?url2=draft-wessels-dns-zone-digest-01 >>> >>> Abstract: >>> This document describes a protocol and DNS Resource Record used to >>> provide a message digest over DNS zone data. In particular, it >>> describes how to compute, sign, represent, and use the message digest >>> to verify the contents of a zone for accuracy and completeness. The >>> ZONEMD Resource Record type is introduced for conveying the message >>> digest data. >>> >>> >>> >>> >>> 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 >>> >>> >>> >>> ___ >>> DNSOP mailing list >>> DNSOP@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsop >> >> ___ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt
Hi Matt, and other authors, with my cryptoplumber[1] hat, I am strongly opposed to using SHA-1 and GOST R 34.11-94 for ZONEMD. It is my understanding, that the specific usage of hashing function in the DS record improves the collision resistance of the algorithm, because the input data is so small and it has to be a valid DNSKEY record[2]. For ZONEMD, this isn’t true, as you can (in theory) feed the zone with infinite amount of non-DNSSEC-signed data (GLUEs, delegations) thus making the collision attack feasible. Thus I believe, the Section 2.1.2 must be changed to disallow usage of algorithms with weakened collision resistance (and algorithms deprecated by the Russians themselves :). It wouldn’t be enough just to discourage SHA-1 for creating the ZONEMD, but it needs to be forbidden to use it for validating such record. I think that new IANA table for ZONEMD must be established, because the security properties of the algorithm usage are different in DS and ZONEMD records. Thanks, Ondrej 1. I would be happy if any real cryptographer would chime in. 2. It doesn’t have to be valid DNSKEY if you just want to cause ruckus, but if you are able to inject invalid DS records, you might as well cause damage at other levels of the DNS tree. -- Ondřej Surý ond...@isc.org > On 23 May 2018, at 17:32, Weinberg, Matt > wrote: > > Greetings dnsop, > > We’ve posted a new version of draft-wessels-dns-zone-digest. Of note, this > -01 version includes the following changes: > > • Warren Kumari and Wes Hardaker have been added as coauthors. > • Several points of clarification in wording and descriptions. > • Removed the requirement to sort by RR CLASS. > • Added a Change Log section. > > Warren and Wes had started on a very similar but unpublished draft, which we > should've remembered. Thanks to them for agreeing to join this document as > coauthors. > We plan to ask for time on the dnsop agenda in Montreal. Your feedback is > welcome and appreciated. > > Thanks. > > > >A new version of I-D, draft-wessels-dns-zone-digest-01.txt >has been successfully submitted by Matt Weinberg and posted to the >IETF repository. > >Name: draft-wessels-dns-zone-digest >Revision: 01 >Title: Message Digest for DNS Zones >Document date: 2018-05-17 >Group: Individual Submission >Pages: 13 >URL: > https://www.ietf.org/internet-drafts/draft-wessels-dns-zone-digest-01.txt >Status: > https://datatracker.ietf.org/doc/draft-wessels-dns-zone-digest/ >Htmlized: > https://tools.ietf.org/html/draft-wessels-dns-zone-digest-01 >Htmlized: > https://datatracker.ietf.org/doc/html/draft-wessels-dns-zone-digest >Diff: > https://www.ietf.org/rfcdiff?url2=draft-wessels-dns-zone-digest-01 > >Abstract: > This document describes a protocol and DNS Resource Record used to > provide a message digest over DNS zone data. In particular, it > describes how to compute, sign, represent, and use the message digest > to verify the contents of a zone for accuracy and completeness. The > ZONEMD Resource Record type is introduced for conveying the message > digest data. > > > > >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 > > > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Incremental zone hash - XHASH
Duane, > My first reaction is that it adds a lot of additional records to the zone. > If I understand correctly, one XHASH for every NSEC/NSEC3, plus an RRSIG for > each XHASH. You didn't really say how (or if) XHASH could be used on an > unsigned zone. What if the ZONEMD+RRSIG would be hash of the XHASH records? That way the XHASH records could stay unsigned. > My second reaction is that it is (necessarily) more complex than what we > proposed with ZONEMD. It might seems there is an additional complexity from the protocol description, but I don’t think it there’s much difference on the implementation level. You need to sort and walk the zone for ZONEMD in the same manner as you would for XHASH. It only differs in an record(s) where you dump and reset the computed hash. Ondrej -- Ondřej Surý ond...@isc.org > On 21 Jul 2018, at 01:38, Wessels, Duane > wrote: > > Mark, > > Thanks for the email. > > My first reaction is that it adds a lot of additional records to the zone. > If I understand correctly, one XHASH for every NSEC/NSEC3, plus an RRSIG for > each XHASH. You didn't really say how (or if) XHASH could be used on an > unsigned zone. > > My second reaction is that it is (necessarily) more complex than what we > proposed with ZONEMD. It seems like it probably works, but I haven't really > spent time thinking about it in depth. > > The use case that my coauthors and I are trying to address with ZONEMD is to > verify authenticity for relatively stable zones being distributed to servers > other than the ones in the NS RRset. For this XHASH feels like too much. > Too much data and too much complexity. I'm not sure if you're proposing > XHASH as an alternative to, or in addition to, ZONEMD. > > If the latter then I'd say get input from operators of dynamic zones and see > if they think the tradeoff of extra data and complexity is of net benefit to > them. > > DW > > > >> On Jul 20, 2018, at 3:31 AM, Mark Andrews wrote: >> >> Rather than having a full zone hash this can be done as a chain >> of hashes (XHASH). >> >> The XHASH would include all records at a signed name (where a signed >> name is NOT an NSEC3 name) up until the next signed name (where a >> signed name is NOT a NSEC3 name) in DNSSEC order similar to ZONEMD. >> If there is a NSEC3 record and its RRSIGs in this range it is included >> in the hash computation. Where a NSEC3 record matches the name of a >> record that exists in the zone it is hashed with that name. The record >> type appears at both top and bottom of zone similar to NS. >> >> The chain is only deemed to be complete if there is a hash record at >> the zone apex. This allows for incremental construction and destruction >> of the XHASH chain similar to the way the presence of NSEC at the zone >> apex indicates that chain is complete. >> >> If there are records that are not at or under the zone apex they are included >> in the final XHASH of the zone sorting from the zone apex to the end of the >> namespace then from the start of the namespace to the zone apex. Such records >> at not normally visible to queries other than AXFR/IXFR. AXFR/IXFR permit >> such >> records. >> >> XHASH would allow for UPDATE to incrementally adjust the chain without >> having to hash the entire zone at once. >> >> XHASH would allow for a slave server to verify a zone is still complete >> after a IXFR by just checking the areas of the zone impacted by the IXFR. >> >> e.g. >> >> example.com SOA >> example.com NS ns.example.com >> example.com DNSKEY … >> example.com NSEC a.example.com NS SOA RRSIG NSEC DNSKEY XHASH >> example.com XHASH … >> >> a.example.com NS ns.a.example.com >> a.example.com NSEC b.example.com NS RRSIG NSEC XHASH >> a.example.com XHASH … >> ns.a.example.com A … >> >> b.example.com NS ns.b.example.com >> b.example.com NSEC ns.example.com NS RRSIG NSEC XHASH >> b.example.com XHASH … >> ns.b.example.com A … >> >> ns.example.com A … >> ns.example.com … >> ns.example.com NSEC example.com A RRSIG NSEC XHASH >> ns.example.com XHASH … >> >> Each of the groupings shows which records plus RRSIGs that are >> included in the XHASH calculation. >> >> To prevent removal/introduction of RRSIGs of XHASH records a DNSKEY >> flag bit is be needed to indicate which RRSIG(XHASH) should/should not >> be present once the chain is complete. The same applies to
Re: [DNSOP] Creating a query/record for A and AAAA
Hi, > On 2 Jul 2018, at 11:53, Tony Finch wrote: > > Paul Vixie wrote: >> >> for QTYPE=A, add as a desired additional data type. >> >> for QTYPE=, add A as a desired additional data type. > > How does the server signal to a client that made an A query that there > are no records so the client does not need to make a followup > query? My answer: use DNSSEC :-) > > What are the incentives to implement this? The current state of the art is > happy eyeballs version 2, which specifies concurrent and A queries; > the client has already made both queries before it finds out it only > needed to make one. I'm not sure how a client could know in advance that > it only needs to make one query. This really isn’t about incentives, but not making the situation worse. A single query without signalling (opportunistic) and without state will double the latency compared to dual A + query fired at the same time. > I think there would be some benefit to this between auth and recursive, > provided the recursive server eagerly validates additional records and > promotes them to the authoritative answer level of RFC 2181 trust. So, instead of adding additional complexity of validating and storing the unsolicited information in additional section, the “prefetch” code in resolvers could be enhanced to pre-fill the cache with additional records when specific RTYPE is requested… Ondrej -- Ondřej Surý ond...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-attrleaf
Oh, one more thing - I think it would be a good idea that this and attrleaf-fix would come as a bundle. Ondrej -- Ondřej Surý ond...@isc.org > On 26 Jun 2018, at 14:10, Ondřej Surý wrote: > > I read the document and I think it’s good to go. > > Ondrej > -- > Ondřej Surý > ond...@isc.org > >> On 25 Jun 2018, at 12:27, Benno Overeinder wrote: >> >> The chairs have read the email discussions on the DNSOP mailing list and >> think that all feedback and comments have been addressed by the author, >> either in the draft or on the mailing list. >> >> This starts a Working Group Last Call for draft-ietf-dnsop-attrleaf >> >> Current versions of the draft is available here: >> https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/ >> >> The Current Intended Status of this document is: Best Current Practice >> >> Please review the draft and offer relevant comments. >> If this does not seem appropriate please speak out. >> If someone feels the document is *not* ready for publication, please >> speak out with your reasons. >> >> This starts a two week Working Group Last Call process, and ends on: 9 >> July 2018. >> >> Thanks, >> >> -- Benno >> >> ___ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-attrleaf
I read the document and I think it’s good to go. Ondrej -- Ondřej Surý ond...@isc.org > On 25 Jun 2018, at 12:27, Benno Overeinder wrote: > > The chairs have read the email discussions on the DNSOP mailing list and > think that all feedback and comments have been addressed by the author, > either in the draft or on the mailing list. > > This starts a Working Group Last Call for draft-ietf-dnsop-attrleaf > > Current versions of the draft is available here: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/ > > The Current Intended Status of this document is: Best Current Practice > > Please review the draft and offer relevant comments. > If this does not seem appropriate please speak out. > If someone feels the document is *not* ready for publication, please > speak out with your reasons. > > This starts a two week Working Group Last Call process, and ends on: 9 > July 2018. > > Thanks, > > -- Benno > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS cookies and multi-vendor anycast incompatibility
> On 21 Jun 2018, at 09:24, Petr Špaček wrote: > So let me ask again: > Are other vendors willing to work on sufficiently detailed > specification? If not just say it! +1 from ISC. I believe that we need to improve interoperability between the implementation or people will not be willing to deploy DNS cookies at all. Ondrej -- Ondřej Surý ond...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] SIG(0) useful (and used?)
But if nobody uses that and nobody else implements this, it sort of beats the usefulness of the feature. Ondrej -- Ondřej Surý — ISC > On 19 Jun 2018, at 23:20, Mark Andrews wrote: > > SIG(0) is much superior for machines updating their own data to TSIG as you > don’t need a secondary storage for the TSIG key. You can replace a master > server without having to worry about transferring TSIG secrets off a dead > machine. You just copy the zone from a slave and go. > > There are other scenarios where it is also superior like automaton delegating > In the reverse tree. > > No I don’t think it should go. > > It should be widely implemented so it can be used. There is a lot of self > fulfilling prophecy in the DNS of people will never is this so we won’t > implement it. > > -- > Mark Andrews > >> On 20 Jun 2018, at 06:48, Ondřej Surý wrote: >> >> Hi, >> >> as far as I could find on the Internet there are only SIG(0) implementation >> in handful DNS implementations - BIND, PHP Net_DNS2 PHP library, >> Net::DNS(::Sec) Perl library, trust_dns written in Rust and perhaps others I >> haven’t found; no mentions of real deployment was found over the Internet >> (but you can blame Google for that)... >> >> Do people think the SIG(0) is something that we should keep in DNS and it >> will be used in the future or it is a good candidate for throwing off the >> boat? >> >> Ondrej >> -- >> Ondřej Surý >> ond...@isc.org >> >> ___ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] SIG(0) useful (and used?)
But is it really used like this? Or will it ever? Ondrej -- Ondřej Surý ond...@isc.org > On 19 Jun 2018, at 23:04, Tony Finch wrote: > > Ondřej Surý wrote: >> >> Do people think the SIG(0) is something that we should keep in DNS and >> it will be used in the future or it is a good candidate for throwing off >> the boat? > > SIG(0) is the only DNS feature that (could) allow unauthenticated client > access to an authenticated server, which would allow > > * secure inteerface to resolver (maybe with SIG(0) + TKEY -> TSIG, > but now probably better to use TLS or DoH) > > * secure stealth secondaries (maybe TLS support would be better) > > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ > an equitable and peaceful international order ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] SIG(0) useful (and used?)
Hi, as far as I could find on the Internet there are only SIG(0) implementation in handful DNS implementations - BIND, PHP Net_DNS2 PHP library, Net::DNS(::Sec) Perl library, trust_dns written in Rust and perhaps others I haven’t found; no mentions of real deployment was found over the Internet (but you can blame Google for that)... Do people think the SIG(0) is something that we should keep in DNS and it will be used in the future or it is a good candidate for throwing off the boat? Ondrej -- Ondřej Surý ond...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex
Oh, what about this? https://tools.ietf.org/html/draft-sury-dnsext-cname-dname-00 :-) O. -- Ondřej Surý ond...@isc.org > On 19 Jun 2018, at 15:18, Petr Špaček wrote: > > Hello dnsop, > > beware, material in this e-mail might cause your head to explode :-) > > This proposal is based on following observations: > - It seems that DNS protocol police lost battle about CNAME at apex, > is is deployed on the Internet. > - Major DNS resolvers like BIND, Unbound, PowerDNS Recursor, dnsmasq > already have code to cope with the "impossible" case of CNAME at the > apex and deal with it in ways which do not break stuff on resolver > side. > - Authoritative servers of vendors named above refuse to serve CNAME at > apex. > - There are CDNs etc. which allow users to create CNAME at apex > no matter what the standards and "normal" servers say and do. > (We have found out this because Knot Resolver is missing hacks for CNAME > at apex and users complain that "it works with every other resolver".) > > > Take a deep breath! > > > Given that resolver side somehow works already ... > could we standardize this obvious violation of RFC 1035? > > It is very clear violation of the standard, but almost everyone found > his way around it using different hacks. These hacks are not going away > because all the CDNs just don't care about standards so we will have > to maintain this code no matter what a great solution we will invent for > future. I.e. adding ANAME will just increase complexity because CNAME at apex > will be there for a long time (if not forever). > > I personally do not like this but it seems better to think though > corner cases in code we already have in production (i.e. think through > current hacks for CNAME at apex) instead of inventing new things like ANAME > (or whatever else). > > Opinions? Tomatoes? Can it work? If not, why not? > > -- > Petr Špacek @ CZ.NIC > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-ietf-dnsop-algorithm-update-01.txt
Oh, looking at the text just before the table it says: Implemenation recommendations for DNSKEY algorithms . I am open to suggestions go to improve this text to emphasize that it is implementation advice, but apart from typo :), I think it does says “Implementation”... Ondrej -- Ondřej Surý ond...@isc.org > On 7 Jun 2018, at 17:28, Ondřej Surý wrote: > >> On 7 Jun 2018, at 08:39, Viktor Dukhovni wrote: >> >> On Tue, Jun 05, 2018 at 09:02:07PM +0200, Ondřej Surý wrote: >> >>> Could I ask for more reviews, so we can progress this document forward? >>> >> >> A couple of quick comments: >> >> 1. Perhaps it might not be clear to all readers whether the >> table in Section 3.1 is *software* implementation advice or >> operational deployment advice? >> >> Seeing that Ed25519 is RECOMMENDED for signing makes me think that >> this software implementation advice, since signing zones with >> Ed25519 seems presently premature. > > It is definitely *software* implementors advice. Good point! > >> 2. I see that RSA-SHA512 (algorithm 10) is not recommended for >> signing, and indeed it is not very widely deployed. Out of >> ~7.6 million signed domains I see ~72k with algorithm 10 ZSKs >> and KSKs, while algorithm 8 is used by ~3.6 million domains in >> KSKs and ZSKs (a ratio of 50:1 for alg 8 : alg 10). >> >> And yet, while it is not popular I don't see that any validators >> supporting RSA and SHA256 are at all likely not to support RSA >> and SHA512. And furthermore, on 64-bit systems SHA512 tends >> to be somewhat faster (more with larger input sizes), because >> it processes input in 64-bit blocks. On my x86_64 laptop, >> running OpenSSL 1.1.1 beta 'speed -evp', gives: >> >> type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes >> 16384 bytes >> sha256 39497.53k 114122.11k 266197.16k 395693.40k 461698.39k >> 469658.28k >> sha512 30863.64k 122424.60k 278926.37k 495961.09k 643754.67k >> 654338.73k >> >> So I am not sure that algorithm 10 warrants discouragement so >> long as 8 is required. Everyone is going to have both, and >> they're basically the same... While the case *for* 10 is not >> strong, the case against 10 looks somewhat weak (does supporting >> 10 for signing carry a real cost?) > > This particular author believes that the DNSSEC should move to ECC, > so there’s a high cost associated with KSK algorithm rollover. So, if people > are going to change to “stronger” (whatever this means in DNSSEC context) > algorithm they should be strongly encouraged to change the algorithm > to ECDSA256 (for now). > > Thanks for the review! > Ondrej > -- > Ondřej Surý > ond...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-ietf-dnsop-algorithm-update-01.txt
> On 7 Jun 2018, at 08:39, Viktor Dukhovni wrote: > > On Tue, Jun 05, 2018 at 09:02:07PM +0200, Ondřej Surý wrote: > >> Could I ask for more reviews, so we can progress this document forward? >> > > A couple of quick comments: > > 1. Perhaps it might not be clear to all readers whether the >table in Section 3.1 is *software* implementation advice or >operational deployment advice? > >Seeing that Ed25519 is RECOMMENDED for signing makes me think that >this software implementation advice, since signing zones with >Ed25519 seems presently premature. It is definitely *software* implementors advice. Good point! > 2. I see that RSA-SHA512 (algorithm 10) is not recommended for >signing, and indeed it is not very widely deployed. Out of >~7.6 million signed domains I see ~72k with algorithm 10 ZSKs >and KSKs, while algorithm 8 is used by ~3.6 million domains in >KSKs and ZSKs (a ratio of 50:1 for alg 8 : alg 10). > >And yet, while it is not popular I don't see that any validators >supporting RSA and SHA256 are at all likely not to support RSA >and SHA512. And furthermore, on 64-bit systems SHA512 tends >to be somewhat faster (more with larger input sizes), because >it processes input in 64-bit blocks. On my x86_64 laptop, >running OpenSSL 1.1.1 beta 'speed -evp', gives: > > type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes > 16384 bytes >sha256 39497.53k 114122.11k 266197.16k 395693.40k 461698.39k > 469658.28k >sha512 30863.64k 122424.60k 278926.37k 495961.09k 643754.67k > 654338.73k > >So I am not sure that algorithm 10 warrants discouragement so >long as 8 is required. Everyone is going to have both, and >they're basically the same... While the case *for* 10 is not >strong, the case against 10 looks somewhat weak (does supporting >10 for signing carry a real cost?) This particular author believes that the DNSSEC should move to ECC, so there’s a high cost associated with KSK algorithm rollover. So, if people are going to change to “stronger” (whatever this means in DNSSEC context) algorithm they should be strongly encouraged to change the algorithm to ECDSA256 (for now). Thanks for the review! Ondrej -- Ondřej Surý ond...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-algorithm-update-01.txt
Dear colleagues, I incorporated text from Michael Sinatra (thanks for that!) and I think the document is ready to go. Could I ask for more reviews, so we can progress this document forward? The sources are also stored at Microsoft^HGithub: https://github.com/oerdnj/draft-ietf-dnsop-algorithm-update So, if you haven’t deleted your account :), you can also send pull requests. Ondrej -- Ondřej Surý ond...@isc.org > Begin forwarded message: > > From: internet-dra...@ietf.org > Subject: New Version Notification for draft-ietf-dnsop-algorithm-update-01.txt > Date: 5 June 2018 at 20:52:20 CEST > To: "Paul Wouters" , "Ondrej Sury" > > > A new version of I-D, draft-ietf-dnsop-algorithm-update-01.txt > has been successfully submitted by Ondrej Sury and posted to the > IETF repository. > > Name: draft-ietf-dnsop-algorithm-update > Revision: 01 > Title:Algorithm Implementation Requirements and Usage > Guidance for DNSSEC > Document date:2018-06-05 > Group:dnsop > Pages:10 > URL: > https://www.ietf.org/internet-drafts/draft-ietf-dnsop-algorithm-update-01.txt > Status: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-algorithm-update/ > Htmlized: > https://tools.ietf.org/html/draft-ietf-dnsop-algorithm-update-01 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-algorithm-update > Diff: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-algorithm-update-01 > > Abstract: > The DNSSEC protocol makes use of various cryptographic algorithms in > order to provide authentication of DNS data and proof of non- > existence. To ensure interoperability between DNS resolvers and DNS > authoritative servers, it is necessary to specify a set of algorithm > implementation requirements and usage guidance to ensure that there > is at least one algorithm that all implementations support. This > document defines the current algorithm implementation requirements > and usage guidance for DNSSEC. This document obsoletes [RFC6944]. > > > > > 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 > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12
I reviewed the -11 to -12 changes and they look good to me. The document is ready to go in my opinion. Ondrej -- Ondřej Surý ond...@isc.org > On 3 May 2018, at 10:15, Geoff Huston wrote: > > Hi WG Chairs (and WG) > > We have submitted -12 of this draft which we believe incorperates the > substantive review comments made during the WG Last Call period that were > posted to the WG Mailing List. >> >> Editors: Please take “concern about a description of current implementation >> status” as WGLC input, and consider what you might be able to add to the >> draft to address it. > > We have also taken the implementation comments posted to the WG mailing list > and collected them in a new section titled "Implementation Experience” in the > light of Suzanne’s request > > So we would like to pass this draft back to the WG Chairs at this point for > your review for potential submission as an RFC. > > Thanks, > > Geoff (for co-editors Joao and Warren) > > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt
> On 26 Mar 2018, at 16:47, Jim Reid wrote: > > On 24 Mar 2018, at 20:20, Ondřej Surý wrote: >> >>> It might be a different story if one of those zombie RRtypes required >>> additional processing. None spring to mind though. >> >> But (most of) those I picked actually *DO*: >> >> a) compression is allowed, so compliant and non-compliant servers can’t >> speak together, because non-compliant will just store junk in the RDATA when >> received from compliant server; >> b) the RDATA needs to be understood and lowercased for canonical form when >> DNSSEC signing; again you need to *implement* this in DNSSEC Validator as it >> would cause validation failures if you don't > > Fair enough Ondřej. Though I suspect the number of servers that sign or > validate MAILA records (or whatever) can be counted on the number of ears on > one hand. :-) On a sunny day, while casually strolling the BIND source code, I found this: case dns_rdatatype_maila: case dns_rdatatype_mailb: query_error(client, DNS_R_NOTIMP, __LINE__); return; So, again, making this _official_ and actually obsolete types that even BIND doesn’t implement, somehow still makes sense to me. Ondrej -- Ondřej Surý ond...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel
And the MR was peer-review and merged into BIND master branch with intent to backport the feature into older release branches. I don’t think it’s a useful or helpful to change the rules for existing adopted work. We need to have a discussion on the mechanisms that would allow implementors to know when to start the implementation of existing draft. From implementors point, it makes little sense to start implementing before the protocol change is almost fully baked (aka WGLC and further), because until then the protocol might change considerably. So, if we require implementation report further down the road, it needs to be more clearly defined than people suddenly shouting “this is not ready” when WGLC starts. And while the attempt to implement something is certainly useful to get valuable feedback, it also imposes some costs (with undefined limit) on implementors (especially the open source implementors) and it sort of discards the whole “Proposed Standard” -> “Internet Standard” classification at global IETF level. I get that we probably need something more lightweight than “Internet Standard” at the WG level, but this needs to be discussed and consensus reached. ISC gave our feedback during the implementation and here are some nits from me (re-reading the document again): ~~~ Section "2. Protocol Walkthrough Example" will be made into Appendix at publication time, so just reminder here that you also need to change the references like "(see the logic below)” when you move the section - perhaps add direct reference to the other section this refers to? ~~~ The table in 3.2 says: "Key Tag is trusted” and “Key Tag is not trusted” - it seems little bit confusing to me; I think that “Key is trusted” and “Key is not trusted”; or some change similar to this needs to be made: “First, the resolver determines if the Key Tag is trusted by comparing numerical value of to any of the Key Tags of an active root zone KSK which is currently trusted…" in paragraph just before the table you mix “Key Tag” and “keytag” and there’s also … My understanding of the text and the proposed fix: […] First, the resolver determines if the numerical value of is equal to any of the Key Tags of an active root zone KSK which is currently trusted by the local resolver and is stored in its store of trusted keys. If a match is found the is trusted. An active root zone KSK is one which could currently be used for validation (that is, a key that is not in either the AddPend or Revoked state as described in [RFC5011]). Second, the resolver alters the response being sent to the original query based on both the left-most label and the presence of a key with given Key Tag in the trust anchor store. Two labels and two possible states of the generate four possible combinations summarized in the table: Label |is trusted|is not trusted -- is-ta | return original answer | return SERVFAIL not-ta | return SERVFAIL | return original answer […] ~~~ o A query name that is signed with a DNSSEC signature that cannot be validated (such as if the corresponding RRset is not signed with a valid RRSIG record). This is called “Bogus” by RFC 4033 Section 5 -> maybe a reference? ~~~ In Section: 7. Privacy Considerations s/mechansim/mechanism/ ~~~ That is all folks. Cheers, Ondrej -- Ondřej Surý ond...@isc.org > On 7 Apr 2018, at 08:27, Evan Hunt wrote: > > On Fri, Apr 06, 2018 at 10:09:50PM -0400, Warren Kumari wrote: >> I think I heard that ISC was considering adding support, but was >> planning on waiting till RFC / some sort of LC. > > Yes. The work in progress is available here: > https://gitlab.isc.org/isc-projects/bind9/merge_requests/123 > > -- > Evan Hunt -- e...@isc.org > Internet Systems Consortium, Inc. > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Current DNS standards, drafts & charter
Definitely. I didn’t mean to rewrite 1:1, but take existing content and do m:n including splitting and combining existing RFCs into new document(s). Ondřej -- Ondřej Surý — ISC > On 27 Mar 2018, at 18:19, Matthew Pounsett wrote: > > > >> On 27 March 2018 at 03:49, Ondřej Surý wrote: >> >> Again, from experience from dnsext, I would strongly suggest that any work >> in this area is split into CHANGE documents and REWRITE documents, with >> strict scope. Documents rewriting existing RFCs while adding more stuff at >> the same time tend to not reach the finish line. >> > Does this include combining documents? For example, it would probably make > sense to combine some of the clarifications documents into any rewrite of > 1034/1035. > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version of draft-ietf-dnsop-algorithm-update-00: Algorithm Implementation Requirements and Usage Guidance for DNSSEC
Hi Michael, > On 27 Mar 2018, at 02:30, Michael Sinatra wrote: > > > > On 03/22/18 08:08, Ondřej Surý wrote: > >> * Separate operational recommendations for default algorithm to >> ECDSAP256SHA256 >> * Deprecation of ECC-GOST (that actually happened elsewhere, so we reflect >> it here) >> >> I also squeezed paragraph about DS algorithm upgrade to operational >> considerations based on Roy Arends’ presentation. > > Regarding the comments (and general tone of the document) regarding > SHA384 and ECDSAP384SHA384: > > I am a bit uncomfortable with the document's disrecommendation of SHA384 > and ECDSAP384SHA384. The main reason for this is that for crypto > recommendations here in the USG, I often point people to the successor > of the NSA Suite B recommendations, now called the "Commercial National > Security Algorithm Suite" or CNSA. The recommendations here call for > SHA384 and P-384: > > https://www.iad.gov/iad/programs/iad-initiatives/cnsa-suite.cfm > > This document made a bit of a splash by pointing out that ECC is not > really quantum-resistant, which led to lots of "theories" as to why > NSA-IAD was making that claim. But the main utility of the document is > the crypto strength recommendations in the document. > > I am *very* sympathetic to the argument that P-256 and SHA-256 are "good > enough" for DNSSEC, especially since we can expect any such signatures > to have expired by the time 112-bit security is completely obsolete. My > motivation is around encouraging people to use the strongest security > available to them without having to worry about whether some > applications could get away with weaker security or not. > > Given that ECDSAP384SHA384 signatures and key lengths are still > significantly smaller than RSASHA256, the adage of "use the strongest > *practical* security algorithm that's available" would still seem to > point to ECDSAP384SHA384. For this reason, I am not comfortable with > the statement: > > "ECDSAP384SHA384 share the same properties as ECDSAP256SHA256, but > offers only a little advantage over ECDSAP256SHA256 and has not seen Perhaps, we could say: “offers only a little advantage for DNSSEC over …” as that would be more accurate. We are (should be) aiming for most practical secure algorithm and that’s ECDSAP256SHA256 at the moment, and ED25519 in a foreseeable future (when there’s enough deployed base). It’s always search for a balance, and given there’s already huge deployed base for ECDSAP256SHA256, I think that discouraging users to use P384 is a reasonable thing to do. > wide deployment, so the usage of this algorithm is discouraged, > especially for signing.” …but the document authors are open to other suggestions, it’s a WG document, so we will follow WG advice. > I would also advocate changing the Signing > Recommendation to "MAY.” That would be fine with me (also to align with ED448 that share many of the properties of P384). I also expect that no implementation would actually rip-out P384 implementation they already have, and for new implementations the recommendation of SHOULD NOT and MAY is of similar value. Cheers, Ondrej -- Ondřej Surý ond...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Current DNS standards, drafts & charter
Hi Suzanne, > If the WG feels that the previous view of how DNSOP should work has been > overtaken by events, we can certainly work with our Area Director (hi > Warren!) on a revised charter. I strongly believe that any work on cleaning up DNS protocol and/or rewriting RFC1034/RFC1035 and associated document would need a new WG with tightly defined charter. Hence, I will not request or I won’t support adopting my deprecating-obsolete-rr-types as a WG document - it might become one of the first documents for new WG, or it might end up as individual submission. While this work might be considered as “protocol maintenance”, I think it is bigger then simple protocol maintenance. Again, from experience from dnsext, I would strongly suggest that any work in this area is split into CHANGE documents and REWRITE documents, with strict scope. Documents rewriting existing RFCs while adding more stuff at the same time tend to not reach the finish line. Ondrej -- Ondřej Surý ond...@isc.org > On 27 Mar 2018, at 01:26, Suzanne Woolf wrote: > > Hi all, > > First, thanks for running with this. > > Top-posting a couple of process observations: > > First, the chairs are always open to discussion of what documents belong in > the WG, interpretation/revision of our charter, etc. There’s a certain amount > of process to be observed, especially if we want to revise our charter, but > nothing unmanageable; it’s the chairs’ job to make process work for the WG > rather than the other way around. > > The current DNSOP charter was deliberately written to be flexible in what we > could work on. Normally an IETF WG is chartered to perform a fairly tightly > constrained piece of work and then either re-charter to an equally specific > next work item, or shut down. But part of the purpose of keeping DNSOP around > in a slightly more open-ended fashion was that the community seemed to > believe that major protocol work on DNS was done, but there would still be > pressure to provide for small tweaks on the wire and review Informational > documents on operational practice such as DNSSEC maintenance. > > Since then, a couple of pieces of work with significant protocol implications > have gotten some initial review in DNSOP, and then moved to new WGs such as > DPRIVE. Most of the documents DNSOP publishes are standards track only for > procedural reasons— implementing them is strictly optional for > interoperability on the public internet— or are informational. > > If the WG feels that the previous view of how DNSOP should work has been > overtaken by events, we can certainly work with our Area Director (hi > Warren!) on a revised charter. > > Given the deliberately loose boundaries on the current charter, we can adjust > what we’re doing instead of (or during) the formal process of revising it. > The charter we have doesn’t obligate us to adopt any particular work item, or > to pursue one that’s been adopted but that the WG finds it doesn’t want to > pursue after all. > > In my own strictly subjective impression, some of what we’re publishing is > first written as an internet-draft….but some is implemented first in the > field and then brought back to the IETF to be documented in an informational > RFC so other implementers can write compatible behavior into their software, > or so operators who want to use a particular feature can figure out how > (*lots* of DNSSEC docs), or operators who don’t want to use a particular > feature can (relatively) easily find ways around it. > > The pressure to standardize extensions to the DNS actually seems lower in the > last few years, because both the RRtype registry and the EDNS opt registry > policies are expert review rather than standards action. However, the > tendency to desire DNS-over-new-transport is recent. So is DPRIVE. So are the > assorted optimizations used by CDN operators such as serve-stale and > client-subnet. > > It’s also worth noting that many WG participants (operators and implementers > alike) have argued over the years that having the IETF refuse to publish an > RFC does nothing to discourage people from inventing and fielding new > features, it just makes it harder to find out what they’re doing— whether you > want to interoperate with them or simply avoid them. So for novel uses of > RRtypes or EDNS options, we’ve tended to encourage people who already had > acquired code points in the registry to document what they’re doing with them > (see RFC 7871 on client-subnet, which had a code point and was in widespread > use and *then* was brought to DNSOP). > > Serious question: should we be encouraging people to document these optional > extensions in RFCs? > > A couple more points inline: > &g
Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt
> On 27 Mar 2018, at 03:36, Dick Franks wrote: > >> please see down-thread where deprecation turns out to be both undesirable >> for the reasons i've given, and additive to developmental complexity since >> there would be _more_ DNS RFC's to read, and suboptimal compared to >> declaring a core subset of DNS technology as "mandatory to implement" and >> simply leaving WKS (and its hypothetical friends) out of that core subset. > > I fail to see how this changes the number of RFCs to be read. > > Nobody has yet defined a core subset; all we have is a camel-load of DNS > technology most of which appears to be "mandatory to implement", > and a mountain of RFCs which are very unlikely to be 100% consistent with > each other. > > Expelling one or more items from the "mandatory" set necessarily involves > writing an RFC to add to this mountain, and sometimes obsoleting an old one. > > The result is a smaller set of "mandatory to implement" DNS technology. > > Repeat this process until nobody can make a good case for further expulsions; > what remains is the core subset. I concur with Dick here. Unless we strip the “core” first, we would be either unable to finish the work because we would endlessly bicker about what to put and what to leave out; or we would end up with even worse superset of what we already have. Stripping down the existing RFCs one-by-one, then just documenting what we already have without changing the content and producing the one “core” document obsoleting 1034,1035 is reasonable approach that could lead to an actionable work plan. Ondrej -- Ondřej Surý ond...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt
> On 26 Mar 2018, at 23:36, Paul Vixie wrote: > > i've had my symbolics 3640 online quite a bit in the last 30 years, This is certainly a fair piece of computer archaelogy, But it is similar to the situation if a museum would insist on providing narrow-wide tracks across the country infrastructure because they have this fine steam engine that still runs. It’s fine to keep your “narrow-wide tracks” in your backyard, but it’s unreasonable to insist that you must be able to run your John Bull coast-to-coast. > and it still makes WKS queries, and i have used WKS responses to control it. > the software still works as well as it was designed to do, but the vendor is > long out of business. however, read on. And it would still be able to issue TYPE7 queries and get answers. There’s neither WKS nor TYPE7 mnemonics on the wire, there’s just \007. I very much doubt that you do changes to the WKS record on a regular basis. I understand that this whole DNS thing is drive by our “pet projects” needs, but this is a museum piece and not something that should shape the DNS standard in year 2018. What I am proposing is reasonable - editing WKS records in hexeditor is reasonable tradeoff to getting rid of stuff that was already dead 30 years ago. Cheers, Ondrej ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt
No, I am claiming that no current Internet standard is using those records and they were already marked as EXPERIMENTAL or OBSOLETE 30 years ago. Ondřej -- Ondřej Surý — ISC > On 26 Mar 2018, at 17:19, Paul Vixie wrote: > > > > Ondřej Surý wrote: > ... >> I think that modifying (or removing stuff from) the DNS standard(s) >> MUST NOT be driven by “how simple it is”, but “how useful it is”. >> >> This would just lead into the situation that we would have two >> categories: “oh, that's too simple to remove” and “oh, that’s too >> difficult to remove” and nothing in between. > > the dichotomy presented here is false. interoperability is a priority. the > observations that you aren't using some feature, and that noone you know is > using that feature, do not support a conclusion that the feature is not in > use. the internet is bigger than what you can measure. > > -- > P Vixie > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt
Thanks to you both. I updated the draft with Evan’s text and merged some of Michael’s text to: https://github.com/oerdnj/draft-sury-dnsop-deprecate-obsolete-resource-records Cheers, -- Ondřej Surý ond...@isc.org > On 26 Mar 2018, at 16:57, Evan Hunt wrote: > > On Mon, Mar 26, 2018 at 10:22:30AM -0400, Michael Casadevall wrote: >> I think to be more specifically, the end goal should be the ability to >> treat obsolete record types as RFC 3597 and remove special casing for >> them. That way, new resolvers simply have to implement 3597 and not >> worry about associated edge cases with the obsolete types. > > Thank you, that's what I was trying to say, you said it better. > >>> 2. responders SHOULD NOT compress rdata when rendering obsolete/deprecated >>> type records to wire format. >>> >> >> The problem here is that right up until the point the camel declares >> these RRtypes dead, the specification specifically allows them to be >> compressed. > > But it's always allowed them not to be compressed, too. The trouble > PowerDNS had was because it wasn't expecting compression, but I would > expect the opposite problem (failing because something *didn't* compress) > to be rarer. > >> 1. Authoritative servers SHOULD warn when loading zones with obsolete >> record types >> >> 2. Resolvers MUST never send obsolete RRtypes in a compressed format. > > Problem here: If the resolver is treating the record as opaque, then it > can only send it along in whatever format it was received in, so this > requirement doesn't work as written. But I think what you mean is that > even if the resolver is able to parse compressed rdata, it MUST NOT > compress when sending the answer along to its own client. This is > re-stated in point 5, below. > >> 3. Signers MUST treat rdata as opaque >> >> 4. Obsolete RRtypes MUST never be treated as a known-type with respect >> to the wire protocol >> >> 5. Resolvers MAY support legacy compression for received data for >> backward compatibility if desired, but SHOULD warn if such information >> is received. Compressed records MUST never be re-transmitted. > > You use MUSTs where I used SHOULDs, but I think we're both pointing > in the same direction. > > -- > Evan Hunt -- e...@isc.org > Internet Systems Consortium, Inc. > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt
> If future-BIND stops parsing an archaic RRType that I happen to use, > I'm going to have to change whatever code or processes that depend on > it. Maybe someone (ISC, even) is going to publish a filter that will > turn all the old RRs in canonical syntax into TYPE representation, > and back again. New RRTypes might then need to get implemented in both > BIND (because presumably they are camel-friendly) and also in the > filter or filters, because perhaps we are targeting multiple > nameserver implementations with our zone file. Joe, do you expect this will be needed for the RR Types I have proposed to be removed? I am specifically trying to not create a generic mechanism to remove any RR Type, just those under MAILA, MAILB umbrella and MINFO. Ondrej -- Ondřej Surý ond...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt
Michael, while I generally agree with your “let’s write a I-D on how to deprecate old RR Types in general”, I would like to keep this document focused on MB, MG, MR, MINFO. I’ll kick out WKS into a separate document, and add MAILB, MAILA, MD and MF in. I would appreciate that in this discussion, instead of saying “RR Types” we should talk about specific RR Types we want to remove from DNS. Saying “removing RR Types” is scary. Saying “removing MB RR Type” is less scary as most people even don’t remember what it was used for. Cheers, -- Ondřej Surý ond...@isc.org > On 26 Mar 2018, at 16:22, Michael Casadevall wrote: > > > > On 03/26/2018 08:45 AM, Evan Hunt wrote: >> On Mon, Mar 26, 2018 at 02:09:14PM +0200, Ondřej Surý wrote: >>> That’s one of the goals of the document - saying: “it’s ok to not >>> implement those RR Types, and it’s ok to break if you receive them" >> >> We need to state clearly what is meant by "ok to break". >> > > I think to be more specifically, the end goal should be the ability to > treat obsolete record types as RFC 3597 and remove special casing for > them. That way, new resolvers simply have to implement 3597 and not > worry about associated edge cases with the obsolete types. > >> I described my preferred approach as an implementer upthread. Let me >> state it again more formally and let people knock it down: >> >> 0. types will be flagged as obsolete/deprecated in the IANA registry, >> and the following guidance is given to DNS implementors in the handling >> of obsolete/deprecated RR types: >> >> 1. auth servers SHOULD log a warning when loading zones that contain >> obsolete/deprecated rrtypes. >> >> 2. responders SHOULD NOT compress rdata when rendering obsolete/deprecated >> type records to wire format. >> > > The problem here is that right up until the point the camel declares > these RRtypes dead, the specification specifically allows them to be > compressed. > > Specifically quoting RFC 3597 here: > To avoid such corruption, servers MUST NOT compress domain names > embedded in the RDATA of types that are class-specific or not well- > known. This requirement was stated in [RFC1123] without defining the > term "well-known"; it is hereby specified that only the RR types > defined in [RFC1035] are to be considered "well-known". > > By definition, the types are in RFC1035; they're well known and thus > compressible. One DNS server may serve a given record uncompressed, > while the next one down the pipe compresses it depending on it's > implementation. > > This came up earlier in the thread, but PowerDNS has an open bug about > this and the MB type due to BIND sending the record compressed, and > PowerDNS not recognizing it: https://github.com/PowerDNS/pdns/issues/5687 > >> 3. queriers which receive obsolete/deprecated type records MAY interpret >> them as unknown type records (rfc 3597), and MUST NOT interfere with >> their transmission. >> >> 3a. note that the choice to parse obsolete/deprecated MAY be contingent >> on whether the rdata is compressed: an obsolete type record MAY be >> parsed as a known type if its rdata is uncompressed, but as an >> unknown type otherwise. >>> 4. validators and signers SHOULD treat rdata for obsolete/deprecated types >> as opaque with respect to canonical RR ordering and deduplication >> > > > On the whole, I'm in favor of removing cruft from the specs wherever > possible, but I'm starting to question if decommissioning RRtypes > qualifies as low hanging fruit. > > If we actually want to decommission these RRtypes, and building off your > starting point, I think the reasonable course of action needs to be this: > > 1. Authoritative servers SHOULD warn when loading zones with obsolete > record types > > 2. Resolvers MUST never send obsolete RRtypes in a compressed format. > > 3. Signers MUST treat rdata as opaque > > 4. Obsolete RRtypes MUST never be treated as a known-type with respect > to the wire protocol > > 5. Resolvers MAY support legacy compression for received data for > backward compatibility if desired, but SHOULD warn if such information > is received. Compressed records MUST never be re-transmitted. > > 6. Validators MAY attempt to to use legacy RR ordering and > de-duplication should validation. If legacy validation is required, the > validator SHOULD warn that it was needed to validate the RRSIGs. > > In effect, we're basically saying, these RRtypes are now RFC 3597, with > the caveat that it's OK to try and
Re: [DNSOP] Fwd: New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt
> On 26 Mar 2018, at 15:39, Tony Finch wrote: > > Evan Hunt wrote: >> >> These RR types have text representations and wire format representations, >> which from a complexity standpoint seem quite harmless to implement. There >> are the old annoying rules about name compression and sorting, which do add >> some complexity, but are already implemented in all the existing codebases. > > There's the particularly special case of WKS which has weird collision > logic - RFC 2136 section 3.4.2.2. It's extra weird that this was specified > in 1997 when WKS was deprecated in 1989 - RFC 1101 and RFC 1123. > > I fear that this will make it hard to delete WKS code because that may > introduce interop bugs if a new server bindly allows colliding WKS records > that an old server objects to. Good catch. WKS would then probably need a separate document that would also remove it from RFC 2136. But it’s funny that we should not remove a record while this was already written in 1989: An application SHOULD NOT rely on the ability to locate a WKS record containing an accurate listing of all services at a particular host address, since the WKS RR type is not often used by Internet sites. To confirm that a service is present, simply attempt to use it. While the special processing was added to RFC 2136 (9 years later) is really beyond my understanding :(. Ondrej -- Ondřej Surý ond...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt
> On 25 Mar 2018, at 15:19, Paul Hoffman wrote: > >> We can make them optional to implement in >> the future, though. > > ...except that, if some implementer reads this document as meaning that they > don't have to handle the listed RRtypes in any special way, they could get > nailed when interoperating with implementations that handle the compression > correctly. That’s one of the goals of the document - saying: “it’s ok to not implement those RR Types, and it’s ok to break if you receive them" > I think it would help if there were more clarity on what exactly is being > proposed, other than adding the words "obsolete" or "deprecated" to a list > of RRtypes on a website somewhere. The draft didn't seem to have > particularly clear guidance to implementers. Correct, and I was also seeking more feedback from the DNS people on that matter. Currently, there are RR Types already marked as “OBSOLETE” in the IANA registry without clear understanding what that does really mean. I guess the document might be able to specify what “OBSOLETE” means for RR Types (in the line of ^^^ “it’s ok to …”.) Ondrej -- Ondřej Surý ond...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt
> On 25 Mar 2018, at 17:27, Paul Wouters wrote: > > And I don't see much point in obsoleting simple defines and logging > unknown RRtypes. Paul, I think that modifying (or removing stuff from) the DNS standard(s) MUST NOT be driven by “how simple it is”, but “how useful it is”. This would just lead into the situation that we would have two categories: “oh, that's too simple to remove” and “oh, that’s too difficult to remove” and nothing in between. Ondrej -- Ondřej Surý ond...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt
> On 24 Mar 2018, at 22:55, Mukund Sivaraman wrote: > > Hi Ondrej > > On Sat, Mar 24, 2018 at 09:20:06PM +0100, Ondřej Surý wrote: >>> It might be a different story if one of those zombie RRtypes required >>> additional processing. None spring to mind though. >> >> But (most of) those I picked actually *DO*: > > In the case of RR types, "additional processing" means type specific > behaviors that do not usually apply to other types. For example, CNAME > has additional processing. The following processing is common to 1035 > types. I knew somebody would notice my “hyperbole”. > Some things to think about for DNS complexity: These are harder to tackle, and I thought beginning with something simple would be … simple. > * Obsoleting CLIENT-SUBNET.. as mentioned on a BIND ticket, > CLIENT-SUBNET flies in the face of where DNS is headed (towards more > privacy). If every user used the resolver on their own network, > there'd be no need for this facility. It's only when forwarders and > caches (that are arguably anti-privacy) from outside the network come > into play, that CLIENT-SUBNET becomes necessary. We as DNS community > should push towards validating resolvers closer to devices. > > This is even without discussing CLIENT-SUBNET's design issues, for > which alone it can go. There is a LOT unwritten in CLIENT-SUBNET RFC. ECS is optional feature and DNS vendors could decide whether the want to implement ECS or not. > * TSIG extras: In TCP continuation (multiple DNS messages such as > during AXFR), TSIG allows some intermediate messages to be sent > unsigned without TSIG RR, and a following TSIG RR to cover all such > intermediate messages. There is no need for such a thing in today's > world. BIND and Knot do not generate such TSIG signed continuations > with gaps (though BIND can parse them), whereas NSD does generate > them. It is just an extra variant to save little space that adds > implementation complexity. I agree that making this simpler would be a good thing, but we’ll have to "not generate, but accept” first approach here. > * TSIG extra extra: TSIG allows truncated MACs which just is ugly. Some > DNS messages may overflow the PMTU or the client-specified EDNS UDP > buffer size if the full MAC is specified vs. the truncated MAC but > this is such a corner case with little benefit compared to complexity > of handling this facility, checking truncated limits, etc. And extra > BADTRUNC rcode, etc. Ack. > * Revising the DNS message format would be a no-no, but there're > redundancies there (repeating owner names [even if they can be > compressed], class, type, TTL, possibility of TTL mismatch among RRs > of a set, etc.). RR class is extra complexity for the most case on the > internet. RRs can be out of order of sets.. it is ugly to parse. DNS > message processing/rendering is inefficient due to the redundancies. BCP perhaps? E.g. write BCP on how to generate good DNS message? > * Name compression (aggressively done) is inefficient and takes up a > significant portion of runtime, and there has been a lot of to and fro > on type-specific rules. RFC 1123 requires name compression, but one > might as well abandon it and put out names in full, esp. over > TCP. It'll eat more bytes, but not much compared to Youtube and > software updates. A document that would say that DNS Compression might or might not happen aggressively would be useful. But then perhaps it would just add more RFCs to read, when some implementors do just read wireshark... > Language in RFCs of the time of 1034/1035 is underspecified. We're > counting pages, but one way to reduce confusion about the protocol is to > _add_ more details and write a bis using 1034/1035 + ncache + edns + > clarifications, etc. with modern language and extra detail. > > As an example, I was asked by a colleage a couple of days ago if any > RFCs required that, if the answer section of a reply had: > > (1) a valid answer RRset matching the RR type that was queried, and > (2) _other_ RRs that are unrelated, > > then should the reply message be discarded? > > While this may be classified to be "common sense", this case does not > appear to be specified, and it was a valid enough question for someone > to ask about it. RFC 1034 has ambiguous language which can be > misconstrued to mean anything: I think this is required, but it also requires a funding for somebody to lead the effort, because most of us here have a day-to-day job that have higher priorities than creating new WG, rewriting old DNS standard and then arguing for years, which _is_ going to happen :). Ondrej -- Ondřej Surý ond...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt
Hi, I’ll conflate more emails into one, as it seems there is a repeating pattern. I would also prefer if somebody > On 24 Mar 2018, at 15:58, Jim Reid wrote: > > Obsoleted RRtypes shouldn’t overload the camel enough to matter. It might be > a different story if one of those zombie RRtypes required additional > processing. None spring to mind though. I am already tired of camel analogy, but there’s the other thing Bert talked about: that the DNS vendors need to grow spine and not implement every little thing. Any new protocol and RR Type must jump through many hoops (Expert Review, WG Review, …), but the stuff that’s already in isn’t subject to any reconsideration if it was a good idea, and it just stays in. On the other hand, the deprecation of SSLv2, then SSLv3 in quick succession has caused much more operational troubles. I know that the (in)security properties is what makes the differences, but this is just a reminder that we do and can remove old stuff from the Internet. > On 24 Mar 2018, at 19:54, Matthew Pounsett wrote: > > Speaking from experience, having spent a few dozen hours so far on some > client code, the code necessary to implement an additional RRType is trivial > by comparison to literally anything else in the protocol, including such > (supposedly) trivial operations as reading and writing zone files. I've got > nothing against deprecating RRTypes that we know aren't in use, but it > doesn't seem like a particularly high priority. This document is sort of litmus paper test, whether we (not necessarily the dnsop WG) can actually remove old cruft from the DNS. The removal of RR Types I proposed is dead simple because of the reasons outlined below. > On 24 Mar 2018, at 13:49, Jared Mauch wrote: > > I think the issue here is just because it's not commonly seen on the > public internet, doesn't mean it's not used. We don't use DHCP to configure > p2p links on routers, this doesn't mean that DHCP can go away, it's used > elsewhere. I am proposing to deprecate RR Types that were either (see Dick Franks’ email for more): a) declared OBSOLETE by RFC 1035 30 years ago b) declared EXPERIMENTAL by RFC 1035 30 years ago c) Adding NXT already marked as OBSOLETE by RFC 3755 also might work There might be other RR Types that might get identified as a step in a wrong direction (as Jim Reid suggested or perhaps something from RFC 1183, RFC 1706), but I would rather stay with these simple cases. To use, the numbers from your zones: > num.type.MD=0 > num.type.MF=0 > num.type.MB=0 > num.type.MG=0 > num.type.MR=0 > num.type.WKS=0 > num.type.MINFO=0 So, the I-D that I am proposing would have absolutely no impact on you. It’s interesting that there’s some NULL RR Type usage in your zones, I suppose that some experiments. And removal of NXT would require some cleaning up: > num.type.NXT=780 I strongly believe this is old cruft as there are no current tools that could the zone sign with pre-DNSSECbis records. So, this is more of subject to DNS archaeology then decision based process. > On 24 Mar 2018, at 18:22, Viktor Dukhovni wrote: > > On Sat, Mar 24, 2018 at 02:58:55PM +, Jim Reid wrote: > >> IMO there's no need to do this in the protocol unless there is convincing >> proof that nobody anywhere is using a now-obsolete RRtype. An RFC saying >> a server could return FORMERR (or whatever) when it gets a query for one >> of these dead/zombie QTYPEs might be OK I suppose. > > Absolutely no! *THAT* would add substantial run-time complexity > for no reason, achieving the opposite of any simplification that > might result from dropping support for the RRtype. If there's no > such data in your zone, return NODATA or NXDOMAIN as appropriate. > If there is such data, return that data. I concur. I am not proposing to hard-fail, only "soft-fail". > On 24 Mar 2018, at 18:22, Viktor Dukhovni wrote: > > One might say that *new* tools may skip > implementing obsolete RRtypes, and that users should avoid new > uses of obsolete RRtypes, but there's not IMHO much impetus > for removing support from existing tools. This is the problem. You can’t just do that, because it is causing operational problems because of name compression in RDATA and RDATA canonicalisation (RFC 4034 Section 6.2). Here’s the example that triggered me to write the I-D: https://github.com/PowerDNS/pdns/issues/5687 Regards, Ondrej -- Ondřej Surý ond...@isc.org > I think what Paul is trying to point out is the same thing, some > enterprises may still be using it internally. Just because we > don't use the RR type in isc.org, nether.net, akamai.com doesn't mean > nobody is using it for their internal networks. We should attempt
Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt
Thanks Dick, this is very helpful suggestion and I’ll use it. Ondrej -- Ondřej Surý ond...@isc.org > On 24 Mar 2018, at 00:06, Dick Franks wrote: > > > On 23 March 2018 at 12:11, Ondřej Surý wrote: > > this is a first attempt to start reducing the load on DNS Implementors and > actually remove the stuff from DNS that’s not used and not needed anymore. > > > I have no quarrel with the overall effect of this proposal, but the > justifications are necessarily different for each category identified in > RFC1035. > > 3.3.4. MD RDATA format (Obsolete) > 3.3.5. MF RDATA format (Obsolete) > > These were already obsolete when RFC1035 was published and arguably should > never have appeared at all. > If these have not already been deprecated somewhere else, there is no > plausible argument against doing so now. > > > 3.3.3. MB RDATA format (EXPERIMENTAL) > 3.3.6. MG RDATA format (EXPERIMENTAL) > 3.3.7. MINFO RDATA format (EXPERIMENTAL) > 3.3.8. MR RDATA format (EXPERIMENTAL) > > After 30 years, it seem clear that the "experiment" produced little or > nothing of lasting value. Plenty of word have been wasted in the past about > open-ended experiments and unpublished results. Deprecating these RRTYPES > would put a formal end to the "experiment". Any counter-argument needs to be > justified by evidence of continuing use in the global internet, and made by > the parties directly affected. The "someone might be using it somewhere ..." > argument is far from convincing. > > > 3.4.2. WKS RDATA format > > WKS is IPv4-specific, so the choice is ether to wait until IPv4 itself > becomes deprecated, or to dispose of it now in the same manner as MB, MG etc. > > > 3.2.3. QTYPE values > > The intended meaning of MAILA is uncertain, but it is already declared by > RFC1035 to be obsolete. > > MAILB is a specific request for MB, MG, and MR records. > > Both should also be deprecated by this document. > > > > --DIck > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt
> It might be a different story if one of those zombie RRtypes required > additional processing. None spring to mind though. But (most of) those I picked actually *DO*: a) compression is allowed, so compliant and non-compliant servers can’t speak together, because non-compliant will just store junk in the RDATA when received from compliant server; b) the RDATA needs to be understood and lowercased for canonical form when DNSSEC signing; again you need to *implement* this in DNSSEC Validator as it would cause validation failures if you don't And all this extra work must be done for RR Types that are unused in current protocols. The implementation for these M* types isn’t just wire<->human readable translation. Ondrej -- Ondřej Surý ond...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt
Joe, it’s actually not the complexity in BIND (although I view everything as extra complexity), it’s the interop for new players that need to implement every piece of rusty junk that's in the protocol to be interoperable. While it seems to be attractive to keep the existing open-source tetrapoly (insert your favorite Greek numerical prefix), the fact is that new implementations do pop up from time to time, and if we can reduce the protocol a little bit, so they can actually implement what’s important, that would be the noble goal here. Let me repeat again - we are speaking about stuff that was declared either OBSOLETE or EXPERIMENTAL already in RFC1035. I’ll elaborate more about why I think we locked ourselves into this when I am not typing on small phone screen in reply to Jared’s message later today. Cheers, Ondrej -- Ondřej Surý — ISC > On 24 Mar 2018, at 14:48, Joe Abley wrote: > >> On Mar 24, 2018, at 13:49, Jared Mauch wrote: >> >> isc/bind can and perhaps should implement logging for these >> rrtypes that say they may be going away so folks can see the impact. > > I'm actually surprised to see that support for rarely-used RRTypes is > really upsetting the camel. > > A combinatorial explosion of annoying workarounds for the inability of > middleboxes or upstream authority servers to implement EDNS(0) > properly seems like a much more plausible camel irritant to me. I'm > sure there are many more like that. > > I can see why you could strip out lines of code by eliminating the > need to parse the canonical formatting of WKS and friends, but I'm > surprised that it's a notable source of complexity. It is, after all, > complexity that I heard is causing the camel strain, not just lines of > code. > > If future-BIND stops parsing an archaic RRType that I happen to use, > I'm going to have to change whatever code or processes that depend on > it. Maybe someone (ISC, even) is going to publish a filter that will > turn all the old RRs in canonical syntax into TYPE representation, > and back again. New RRTypes might then need to get implemented in both > BIND (because presumably they are camel-friendly) and also in the > filter or filters, because perhaps we are targeting multiple > nameserver implementations with our zone file. > > This all sounds like we're just sharing the complexity around. It > doesn't sound any simpler. Maybe it's a silly example? I don't know. > Could be. But I think brushing the grains RRType parsing dust off the > camel is not going to do much for its posture. > > > Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt
The configurations change all the time, I am sorry, but your argument doesn’t have a technical merit. We really do need to start removing obsolete stuff from DNS, and I believe this is a good start. Ondřej -- Ondřej Surý — ISC > On 23 Mar 2018, at 18:39, Paul Vixie wrote: > > > > Ondřej Surý wrote: >> What’s so wrong of using TYPExxx for these if you absolutely need >> them to run the ancient technology while at the same time running the >> latest version of BIND (or your favorite DNS server)? > > because i am loathe to break existing working configurations. when isc > changed the value of allow-query to be LAN only, it took years to do as > safely as we knew how, and even so there was some breakage. > >> Your argument feels like strawman to me. And I am not the one sitting >> on a pile of passive DNS data, so I can’t pull the numbers... > > we don't see a lot of intranet data, so that would not be dispositive. > however, i urge you to reconsider your strawman-ish feelings. we are forever > rebuilding the airplane in flight. the long tail matters. > >> We are not taking the ability to put random TYPEnnn records into the >> zone, we are just saying the tools just won’t understand them >> anymore. Again nothing is going to break on the day one. > > as long as people know what they're doing and are willing to convert their > zones using tools unspecified, that's true. but you are chewing on the > narrowest part of bert's camel here, at some risk, little gain. > > -- > P Vixie > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt
What’s so wrong of using TYPExxx for these if you absolutely need them to run the ancient technology while at the same time running the latest version of BIND (or your favorite DNS server)? Your argument feels like strawman to me. And I am not the one sitting on a pile of passive DNS data, so I can’t pull the numbers... We are not taking the ability to put random TYPEnnn records into the zone, we are just saying the tools just won’t understand them anymore. Again nothing is going to break on the day one. Ondrej -- Ondřej Surý — ISC > On 23 Mar 2018, at 18:26, Paul Vixie wrote: > > > > Ondřej Surý wrote: >> I strongly disagree. The DNS protocol deserve cleanup. Deprecating >> RRTYPEs doesn’t mean the will stop working on the day the RFC is >> published, neither are people going to backport the removal of >> RRTYPEs to existing DNS software releases. >> >> It just means - whatever ancient stuff you are using - you are on >> your own now. It’s same as with the stuff that never got the RFC. > > so anyone supporting an older internal network using modern tools has to stop > upgrading their tooling. that's not constructive for anybody. all of us will > be less safe if these tools become non-upgradeable. > >> Paul, sorry, but the argument “but I know of people running” ancient >> systems can’t be used at every attempt to cleanup the kitchensink >> protocol that DNS is right now. > > ondrej, if you're looking for stuff to kill that nobody is using and that > needlessly fattens the camel, there's a lot of lower hanging fruit. > > to say it's complicated, let's simplify it, and oh by the way we need to add > a CNAME to support the never-workable RFC 5011 plan we adopted in ignorance > many years back, in the same breath, confuses me. > > -- > P Vixie > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt
I strongly disagree. The DNS protocol deserve cleanup. Deprecating RRTYPEs doesn’t mean the will stop working on the day the RFC is published, neither are people going to backport the removal of RRTYPEs to existing DNS software releases. It just means - whatever ancient stuff you are using - you are on your own now. It’s same as with the stuff that never got the RFC. You can you whatever you want, it will be your responsibility (and costs), not the implementors. So, the people can keep their old system running, they just can’t expect the current DNS to interoperate with them. Paul, sorry, but the argument “but I know of people running” ancient systems can’t be used at every attempt to cleanup the kitchensink protocol that DNS is right now. Ondrej -- Ondřej Surý — ISC > On 23 Mar 2018, at 17:55, Paul Vixie wrote: > > > > Ondřej Surý wrote: >> Thanks, now I understand what you are asking for;), so what about: >> >> “No existing Internet Standard uses these Resource Records and there no >> know practical usage in the public Internet.” > > i think this is overbroad. if we aren't also sure that it's not being used in > some private network somewhere, we should not tell implementers to remove > support. a lot of private networks use internet protocols and implementations > to support their local apps and users. > > mf, mg, mb, and mail1 are i think still in use on some as/400 intranets. > > when i removed UID and GID from BIND it was because there was no RFC, not > because i wasn't fully aware of some older athena implementations still in > use at that time which used these instead of TXT. > > ideally we'd put out an extended call for comments about anything we'd like > to remove if it ever worked to anyone's knowledge. if it never worked, like > extended label types in EDNS, they can just be removed. > > this is how we handled IQUERY deprecation and i think it went well. > > -- > P Vixie > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt
Thanks, now I understand what you are asking for;), so what about: “No existing Internet Standard uses these Resource Records and there no know practical usage in the public Internet.” Ondřej -- Ondřej Surý — ISC > On 23 Mar 2018, at 16:51, Bob Harold wrote: > > >> On Fri, Mar 23, 2018 at 12:05 PM, Ondřej Surý wrote: >> No, I don’t mean that. While in theory you can call an aquarium with dead >> fish and algae “in use” and tell your neighbors that you have fish and have >> a green thumb, it wouldn’t be necessarily an accurate assessment of the >> situation. Similarly, an occasional user that tries things doesn’t make >> those experimental RRTYPEs to be “in use”. >> >> What I mean is to make DNS simpler by kicking out stuff that has no use in >> existing protocols. >> >> Ondřej >> -- >> Ondřej Surý — ISC > > Ok, sorry to sound mean. But I think 'not in use' needs to be defined in the > rfc so we all understand it the same. How do we decide when something in no > longer in use? Perhaps there is no quantitative measurement and we just have > to make a judgement call. > > "no known practical usage" ? > "no known use that will break anything if removed" ? > "use is so low that the the advantage of removing exceeds the advantage of > continuing to support it" ? > "there is very little use and we don't think removing it will cause a > problem" ? > > -- > Bob Harold > > >>> On 23 Mar 2018, at 14:18, Bob Harold wrote: >>> >>> >>>> On Fri, Mar 23, 2018 at 8:11 AM, Ondřej Surý wrote: >>>> Heya, >>>> >>>> this is a first attempt to start reducing the load on DNS Implementors and >>>> actually remove the stuff from DNS that’s not used and not needed anymore. >>>> >>>> There’s github for the draft: >>>> https://github.com/oerdnj/draft-sury-dnsop-deprecate-obsolete-resource-records >>>> >>>> Ondrej >>>> -- >>>> Ondřej Surý >>>> ond...@isc.org >>>> >>>>> Begin forwarded message: >>>>> >>>>> From: internet-dra...@ietf.org >>>>> Subject: New Version Notification for >>>>> draft-sury-deprecate-obsolete-resource-records-00.txt >>>>> Date: 23 March 2018 at 12:09:19 GMT >>>>> To: "Ondrej Sury" >>>>> >>>>> >>>>> A new version of I-D, >>>>> draft-sury-deprecate-obsolete-resource-records-00.txt >>>>> has been successfully submitted by Ondrej Sury and posted to the >>>>> IETF repository. >>>>> >>>>> Name: draft-sury-deprecate-obsolete-resource-records >>>>> Revision: 00 >>>>> Title:Deprecating obsolete DNS Resource Records >>>>> Document date:2018-03-22 >>>>> Group:Individual Submission >>>>> Pages:4 >>>>> URL: >>>>> https://www.ietf.org/internet-drafts/draft-sury-deprecate-obsolete-resource-records-00.txt >>>>> Status: >>>>> https://datatracker.ietf.org/doc/draft-sury-deprecate-obsolete-resource-records/ >>>>> Htmlized: >>>>> https://tools.ietf.org/html/draft-sury-deprecate-obsolete-resource-records-00 >>>>> Htmlized: >>>>> https://datatracker.ietf.org/doc/html/draft-sury-deprecate-obsolete-resource-records >>>>> >>>>> >>>>> Abstract: >>>>> This document deprecates Resource Records that are neither being used >>>>> for anything meanigful nor already made obsolete by other RFCs. This >>>>> document updates [RFC1035]. >>> >>> I don't mind deprecating unused types. But I don't understand how an >>> unused type can affect compression. I can only imagine it having an effect >>> if the type actually exists in a packet, which means that it is 'in use'. >>> >>> Do you mean 'types that have DNS records, and hosts query for those >>> records, but we think they are not really used' ? >>> >>> -- >>> Bob Harold > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version of draft-ietf-dnsop-algorithm-update-00: Algorithm Implementation Requirements and Usage Guidance for DNSSEC
I agree with Victor and I believe this is what the draft currently says and recommends. Ondřej -- Ondřej Surý — ISC > On 23 Mar 2018, at 15:58, Viktor Dukhovni wrote: > >> On Thu, Mar 22, 2018 at 01:27:38PM -0400, Paul Wouters wrote: >> >> I think this text also needs an update: >> >>RSASHA1 and RSASHA1-NSEC3-SHA1 are widely deployed, although zones >>deploying it are recommended to switch to ECDSAP256SHA256 as there is >>an industry-wide trend to move to elliptic curve cryptography. >> >> They should switch away from SHA1 as SHA1 is being deprecated industry >> wide. Even if we recommend to move away from RSA (which I'm not sure if there >> is consensus on) to ECC, I would like to move them to ED25519/ED448 over >> the ECDSA* variants. > > I think it is, unfortunately, much too early for such a move. For > example, on Unix systems the requisite OpenSSL 1.1.x libraries that > provide the Edwards EC algorithms, are not yet out of beta! It > will be some years before Ed25519 and Ed448 can be expected to be > widely supported by resolvers. Therefore, I would still strongly > recommend ECDSA, which is widely supported. > > We should certainly encourage the implementation of Ed25519/Ed448 > in resolver and nameserver implementations, but it is much too > early for adoption, beyond dual DS/KSKs one ECDSA and another > Ed25519, with the client choosing whichever it prefers. ZSKs should > IMHO migrate to ECDSA for now to alleviate packet size issues. > >> If it is too soon for that now, I would simply not recommend moving away >> from RSA. And maybe make ECDSAP256SHA256 a MAY instead of a MUST. > > I disagree. ECDSA is widely adopted, and more adoption will help > to reduce packet sizes and improved performance of online signing > where desired (load-balaced responses with DNSSEC, ...). > > -- >Viktor. > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-07
I also prefer #2 Personally, I would go with rzksk-sentinel because it’s shorter and more accurate, but #2 will make me happy. Ondrej -- Ondřej Surý — ISC > On 23 Mar 2018, at 15:20, Wessels, Duane wrote: > > >> On Mar 23, 2018, at 5:13 AM, Warren Kumari wrote: >> >> Dear DNSOP, >> >> Please clearly express a preference for: >> 1: Keeping the current label -- kskroll-sentinel-is-ta-20326.example.com >> 2: Changing it to the new label -- root-key-sentinal-is-ta-20326.example.com >> > > I prefer #2. > > DW > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt
No, I don’t mean that. While in theory you can call an aquarium with dead fish and algae “in use” and tell your neighbors that you have fish and have a green thumb, it wouldn’t be necessarily an accurate assessment of the situation. Similarly, an occasional user that tries things doesn’t make those experimental RRTYPEs to be “in use”. What I mean is to make DNS simpler by kicking out stuff that has no use in existing protocols. Ondřej -- Ondřej Surý — ISC > On 23 Mar 2018, at 14:18, Bob Harold wrote: > > >> On Fri, Mar 23, 2018 at 8:11 AM, Ondřej Surý wrote: >> Heya, >> >> this is a first attempt to start reducing the load on DNS Implementors and >> actually remove the stuff from DNS that’s not used and not needed anymore. >> >> There’s github for the draft: >> https://github.com/oerdnj/draft-sury-dnsop-deprecate-obsolete-resource-records >> >> Ondrej >> -- >> Ondřej Surý >> ond...@isc.org >> >>> Begin forwarded message: >>> >>> From: internet-dra...@ietf.org >>> Subject: New Version Notification for >>> draft-sury-deprecate-obsolete-resource-records-00.txt >>> Date: 23 March 2018 at 12:09:19 GMT >>> To: "Ondrej Sury" >>> >>> >>> A new version of I-D, draft-sury-deprecate-obsolete-resource-records-00.txt >>> has been successfully submitted by Ondrej Sury and posted to the >>> IETF repository. >>> >>> Name: draft-sury-deprecate-obsolete-resource-records >>> Revision: 00 >>> Title: Deprecating obsolete DNS Resource Records >>> Document date: 2018-03-22 >>> Group: Individual Submission >>> Pages: 4 >>> URL: >>> https://www.ietf.org/internet-drafts/draft-sury-deprecate-obsolete-resource-records-00.txt >>> Status: >>> https://datatracker.ietf.org/doc/draft-sury-deprecate-obsolete-resource-records/ >>> Htmlized: >>> https://tools.ietf.org/html/draft-sury-deprecate-obsolete-resource-records-00 >>> Htmlized: >>> https://datatracker.ietf.org/doc/html/draft-sury-deprecate-obsolete-resource-records >>> >>> >>> Abstract: >>> This document deprecates Resource Records that are neither being used >>> for anything meanigful nor already made obsolete by other RFCs. This >>> document updates [RFC1035]. > > I don't mind deprecating unused types. But I don't understand how an unused > type can affect compression. I can only imagine it having an effect if the > type actually exists in a packet, which means that it is 'in use'. > > Do you mean 'types that have DNS records, and hosts query for those records, > but we think they are not really used' ? > > -- > Bob Harold > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-07
It’s not only that - however unbelievable it might seems, but we also have tests (and variable names) and I do believe the things should be consistent for future generations. Ondrej -- Ondřej Surý ond...@isc.org > On 23 Mar 2018, at 12:08, George Michaelson wrote: > > isn't it a #define string? or passed in via environment from configure? > > -G > > On Fri, Mar 23, 2018 at 11:47 AM, Mark Andrews wrote: >> >>> On 23 Mar 2018, at 10:08 pm, Warren Kumari wrote: >>> >>> On Fri, Mar 23, 2018 at 10:07 AM, Mark Andrews wrote: >>>> Geoff you are wrong. Titles should tell you what you are about >>>> to read especially technical documents. There are WAY TOO MANY >>>> RFC TO READ EVERYONE ON THEM. >>> >>> ... you lack ambition :-P >>> >>>> >>>> If I had a TA for andrews.wattle.id.au the current title would >>>> indicate that I could test resolvers to see if there is a TA >>>> installed for it. >>>> >>>> The current draft *is not* generic. It is root TA specific. >>>> That needs to be reflected in the title. >>>> >>>> As for the label it can be used for more than rolling KSKs. >>>> It can be used to see what resolvers are supporting new TA >>>> *when you are not rolling keys*. The current name reflects >>>> *one* use, not all uses. >>> >>> True, it does reflect one use case, not all -- however, we have >>> already changed the name multiple times and implementers are >>> (understandably) becoming annoyed, and supporting N different labels >>> for the tester is also annoying [0]. >> >> As an implementer I say TOUGH! The job of the working group is to >> put out good specifications not to take short cuts just because >> something has been implemented based on a draft. This is the expected >> cost of implementing on a draft. I’ve re-written plenty of code to >> follow draft changes. >> >> I’ve got code to implement this. Some corner cases are currently >> undefined. Changing the label name will cause me to have to re-write >> parts of what I have already written. I know this but I’m still >> calling for the changes. Not only will the specific labels change >> but potentially configuration arguments and with that documentation. >> >>> How about a compromise - we update the draft name, but keep the label >>> the same - the only people who likely care about the label are >>> implementers and testers - once someone sees the name they will read >>> the doc and quickly discover how it can be used. >>> >>> W >>> >>> >>> >>>> >>>> Mark >>>> >>>>> On 23 Mar 2018, at 8:21 pm, Geoff Huston wrote: >>>>> >>>>> >>>>> >>>>>> On 23 Mar 2018, at 12:55 am, Mark Andrews wrote: >>>>>> >>>>>> This title of this document DOES NOT match reality. >>>>>> >>>>>> "A Sentinel for Detecting Trusted Keys in DNSSEC” should be >>>>>> replaced by “A Root Key Trust Anchor Sentinel for DNSSEC”. >>>>>> >>>>>> kskroll-sentinel-- really needs something other >>>>>> than “kskroll” as the first field. “root-key-sentinal--” >>>>>> really more clearly matches what it does. >>>>>> >>>>>> Any other changes that follow from these two changes” >>>>>> >>>>> >>>>> I personally think this is getting into bike shedding at this point. >>>>> >>>>> The title of the document is an adequate description of the content >>>>> and folk who want to know more should read the document, not guess >>>>> from the title! >>>>> >>>>> The label is a piece of syntactic convenience and is entirely >>>>> arbitrary. We could start an almost infinite discussion thread >>>>> over which label is better, but in the end its just a label. >>>>> >>>>> >>>>> regards, >>>>> >>>>> Geoff >>>>> >>>>> >>>>> >>>> >>>> -- >>>> Mark Andrews, ISC >>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>>> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org >>>> >>>> ___ >>>> DNSOP mailing list >>>> DNSOP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dnsop >>> >>> >>> >>> -- >>> I don't think the execution is relevant when it was obviously a bad >>> idea in the first place. >>> This is like putting rabid weasels in your pants, and later expressing >>> regret at having chosen those particular rabid weasels and that pair >>> of pants. >>> ---maf >> >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org >> >> ___ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Fwd: New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt
Heya, this is a first attempt to start reducing the load on DNS Implementors and actually remove the stuff from DNS that’s not used and not needed anymore. There’s github for the draft: https://github.com/oerdnj/draft-sury-dnsop-deprecate-obsolete-resource-records <https://github.com/oerdnj/draft-sury-dnsop-deprecate-obsolete-resource-records> Ondrej -- Ondřej Surý ond...@isc.org > Begin forwarded message: > > From: internet-dra...@ietf.org > Subject: New Version Notification for > draft-sury-deprecate-obsolete-resource-records-00.txt > Date: 23 March 2018 at 12:09:19 GMT > To: "Ondrej Sury" > > > A new version of I-D, draft-sury-deprecate-obsolete-resource-records-00.txt > has been successfully submitted by Ondrej Sury and posted to the > IETF repository. > > Name: draft-sury-deprecate-obsolete-resource-records > Revision: 00 > Title:Deprecating obsolete DNS Resource Records > Document date:2018-03-22 > Group:Individual Submission > Pages:4 > URL: > https://www.ietf.org/internet-drafts/draft-sury-deprecate-obsolete-resource-records-00.txt > Status: > https://datatracker.ietf.org/doc/draft-sury-deprecate-obsolete-resource-records/ > Htmlized: > https://tools.ietf.org/html/draft-sury-deprecate-obsolete-resource-records-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-sury-deprecate-obsolete-resource-records > > > Abstract: > This document deprecates Resource Records that are neither being used > for anything meanigful nor already made obsolete by other RFCs. This > document updates [RFC1035]. > > > > > 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 > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-07
Warren, > however, we have > already changed the name multiple times and implementers are > (understandably) becoming annoyed, and supporting N different labels > for the tester is also annoying [0]. Who are exactly these people? We are aware only of Knot Resolver implementation so far. And I guess Geoff has a “client” side implementation, but it’s not like everybody already implemented this and we are the last one that are asking for a change. Ondrej -- Ondřej Surý ond...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-07
Again, blame the morning and the Google that led me to old version of the draft, in fact the current draft says: [ NOTE: This version uses the labels "kskroll-sentinel-is-ta-", "kskroll-sentinel-not-ta-"; older versions of this document used "_is-ta-", "_not-ta-". Also note that the format of the tag-index is now zero-filled decimal. Apolgies to those who have began implmenting.] And I believe the “kskrool-" part is in fact wrong, as even though it targets the current RZ KSK Roll, it’s not what the mechanism describes - this is a mechanism to monitor root zone trust anchors. Ondrej -- Ondřej Surý ond...@isc.org > On 23 Mar 2018, at 09:38, Ondřej Surý wrote: > > Hi Joao, > > I think Mark has a legitimate question. Once we settle on one specific label, > it will get stapled all over - not only the label in the domain name, but > also configuration options, etc… etc… > > I proposed rzksk-sentinel for our configuration to enable/disable it, but > Mark is quite right that this needs to be in sync with the label. > > Ondrej > -- > Ondřej Surý > ond...@isc.org > >> On 23 Mar 2018, at 09:29, Joao Damas wrote: >> >> Mark, >> >> >>> On 23 Mar 2018, at 00:55, Mark Andrews wrote: >>> >>> This title of this document DOES NOT match reality. >>> >>> "A Sentinel for Detecting Trusted Keys in DNSSEC” should be >>> replaced by “A Root Key Trust Anchor Sentinel for DNSSEC”. >> >> Sigh , really? >> >>> >>> kskroll-sentinel-- really needs something other >>> than “kskroll” as the first field. “root-key-sentinal--” >>> really more clearly matches what it does. >> >> It is just a string that is easily identifiable. Let’s get over this. >> >> Joao >> ___ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-07
Pleas, just ignore me. It’s too early in the morning. The label is of-course is-ta. and not-ta. Ondrej -- Ondřej Surý ond...@isc.org > On 23 Mar 2018, at 09:38, Ondřej Surý wrote: > > Hi Joao, > > I think Mark has a legitimate question. Once we settle on one specific label, > it will get stapled all over - not only the label in the domain name, but > also configuration options, etc… etc… > > I proposed rzksk-sentinel for our configuration to enable/disable it, but > Mark is quite right that this needs to be in sync with the label. > > Ondrej > -- > Ondřej Surý > ond...@isc.org > >> On 23 Mar 2018, at 09:29, Joao Damas wrote: >> >> Mark, >> >> >>> On 23 Mar 2018, at 00:55, Mark Andrews wrote: >>> >>> This title of this document DOES NOT match reality. >>> >>> "A Sentinel for Detecting Trusted Keys in DNSSEC” should be >>> replaced by “A Root Key Trust Anchor Sentinel for DNSSEC”. >> >> Sigh , really? >> >>> >>> kskroll-sentinel-- really needs something other >>> than “kskroll” as the first field. “root-key-sentinal--” >>> really more clearly matches what it does. >> >> It is just a string that is easily identifiable. Let’s get over this. >> >> Joao >> ___ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-07
Hi Joao, I think Mark has a legitimate question. Once we settle on one specific label, it will get stapled all over - not only the label in the domain name, but also configuration options, etc… etc… I proposed rzksk-sentinel for our configuration to enable/disable it, but Mark is quite right that this needs to be in sync with the label. Ondrej -- Ondřej Surý ond...@isc.org > On 23 Mar 2018, at 09:29, Joao Damas wrote: > > Mark, > > >> On 23 Mar 2018, at 00:55, Mark Andrews wrote: >> >> This title of this document DOES NOT match reality. >> >> "A Sentinel for Detecting Trusted Keys in DNSSEC” should be >> replaced by “A Root Key Trust Anchor Sentinel for DNSSEC”. > > Sigh , really? > >> >> kskroll-sentinel-- really needs something other >> than “kskroll” as the first field. “root-key-sentinal--” >> really more clearly matches what it does. > > It is just a string that is easily identifiable. Let’s get over this. > > Joao > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version of draft-ietf-dnsop-algorithm-update-00: Algorithm Implementation Requirements and Usage Guidance for DNSSEC
-- Ondřej Surý ond...@isc.org > On 22 Mar 2018, at 17:27, Paul Wouters wrote: > > On Thu, 22 Mar 2018, Ondřej Surý wrote: > >> https://github.com/oerdnj/draft-ietf-dnsop-algorithm-update >> >> Pull/Merge Requests, Issues, etc. are welcome. >> >> The most of the work done between the last version and this is: >> >> * Removal of MUST-, SHOULD+, etc… >> * Upgrade the urgency of deploying ECC >> * Separate operational recommendations for default algorithm to >> ECDSAP256SHA256 >> * Deprecation of ECC-GOST (that actually happened elsewhere, so we reflect >> it here) > > As for the DS algorithm 4, SHA-384 does not really add anything over > SHA-256, so it would be good to move that further down from MAY to MUST > NOT on the creation (not validation) part. I'm afraid the current > listing might appear as "it is MAY now but will become MUST in the > future". > > Based on Viktor's data, the ratio of SHA256 to SHA384 is 500:1 with > only 8649 DS SHA384 records. Even GOST which is MUST NOT has 4x more > DS records deployed with 36388 records. Sounds good to me, you already have access to the repo :). > I think this text also needs an update: > > RSASHA1 and RSASHA1-NSEC3-SHA1 are widely deployed, although zones > deploying it are recommended to switch to ECDSAP256SHA256 as there is > an industry-wide trend to move to elliptic curve cryptography. > > They should switch away from SHA1 as SHA1 is being deprecated industry > wide. Even if we recommend to move away from RSA (which I'm not sure if there > is consensus on) to ECC, I would like to move them to ED25519/ED448 over > the ECDSA* variants. I don’t think this is currently feasible to do so, so we need to have a feedback from WG. > If it is too soon for that now, I would simply not > recommend moving away from RSA. And maybe make ECDSAP256SHA256 a MAY > instead of a MUST. What would be the technical/security reason for skipping ECDSA? Ondrej ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] New Version of draft-ietf-dnsop-algorithm-update-00: Algorithm Implementation Requirements and Usage Guidance for DNSSEC
Hi, Tim has poked me and Paul W. that WG have actually accepted Algorithm Implementation Requirements and Usage Guidance for DNSSEC as a working group document. I have updated the draft and submitted is as a WG document and meanwhile it sits there patiently for WG chair approval, you can look at the github version meanwhile: https://github.com/oerdnj/draft-ietf-dnsop-algorithm-update Pull/Merge Requests, Issues, etc. are welcome. The most of the work done between the last version and this is: * Removal of MUST-, SHOULD+, etc… * Upgrade the urgency of deploying ECC * Separate operational recommendations for default algorithm to ECDSAP256SHA256 * Deprecation of ECC-GOST (that actually happened elsewhere, so we reflect it here) I also squeezed paragraph about DS algorithm upgrade to operational considerations based on Roy Arends’ presentation. Ondrej -- Ondřej Surý ond...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error
I support the adoption. Will make an effort to review if enforced with sharp object :) O. -- Ondřej Surý -- Technical Fellow CZ.NIC, z.s.p.o.-- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.s...@nic.czhttps://nic.cz/ - Original Message - > From: "tjw ietf" > To: "dnsop" > Sent: Tuesday, 25 July, 2017 18:04:04 > Subject: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error > This draft was the only one which seemed to have broad support in some form > during the meeting last week. > > This starts a Call for Adoption for draft-wkumari-dnsop-extended-error > > The draft is available here: > [ https://tools.ietf.org/html/draft-wkumari-dnsop-extended-error-02 | > https://tools.ietf.org/html/draft-wkumari-dnsop-extended-error-02 ] > > Please review this draft to see if you think it is suitable for adoption by > DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 8 August 2017, 23:59 > > Thanks, > tim wicinski > DNSOP co-chair > > > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption"
- Original Message - > From: "John R Levine" > To: "Woodworth, John R" > Cc: "dnsop" > Sent: Saturday, 22 July, 2017 08:33:30 > Subject: Re: [DNSOP] DNS versioning, was The DNSOP WG has placed > draft-woodworth-bulk-rr in state "Candidate for WG > Adoption" >>> ...BULK absolutely requires online DNSSEC signing, >> Unfortunately, I respectfully reject this as a statement of fact. >> There's even a provision (NPN) ... > > ... which only works if you upgrade every validating resolver. If you > get to do that, you might as well just send the signed BULK record, the > NSEC and RRSIG that show there's nothing at the name, and let the resolver > figure it out. Given how slowly people update their client DNS libraries, > NPN would be a recipe for decades of DNS flakiness, as some resolvers > accept the generated records and some don't. +1 Personally, I think NPN should be just dropped as John L. is correct in his assessment here. I still think BULK is too complicated[*], but I understand the value of interoperability between DNS server vendors. * - compare to our synthrecord plugin: https://www.knot-dns.cz/docs/2.5/html/modules.html#synthrecord-automatic-forward-reverse-records Cheers, -- Ondřej Surý -- Technical Fellow CZ.NIC, z.s.p.o.-- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.s...@nic.czhttps://nic.cz/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt
> But it's certainly another step along the way to DNSbis by accident. Would it be useful to make it not "by accident"? That's why I have a love-hate relationship with TLV inside DNS messages. I have a couple questions: a) make DNS over TCP/TLS sessions without TLV suck less? b) make this draft DNS-SD only, so it can fast forward... c) use the changed paradigm to work on DNSbis without the accident part? Cheers, -- Ondřej Surý -- Technical Fellow CZ.NIC, z.s.p.o.-- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.s...@nic.czhttps://nic.cz/ - Original Message - > From: "Andrew Sullivan" > To: "dnsop" > Sent: Thursday, 20 July, 2017 18:50:44 > Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt > On Thu, Jul 20, 2017 at 06:45:25PM +0200, Ondřej Surý wrote: >> Is this useful for DNS at all, or is this targeted at DNS-SD only? > > I can think of at least one way it would be useful. Large > authoritatives often have a clear population of query sources that ask > a lot -- the "top talkers". It would be excellent if those clients > stood up TCP connections and kept them in place because then (1) the > server could treat their TCP connections as long-lived and (2) the > server could treat new UDP packets from those IPs as suspect. The > current TCP handling makes this mostly suck, and the > session-signalling approach makes it suck less. > > But it's certainly another step along the way to DNSbis by accident. > > A > > -- > Andrew Sullivan > a...@anvilwalrusden.com > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt
Hey, there's one thing I don't really understand from this draft. Is this useful for DNS at all, or is this targeted at DNS-SD only? I think this needs some explaining and perhaps a clear cut is needed. Although it's not mentioned anywhere in the document, the draft makes much more sense to me, if it would clearly state, this should be only used in DNS-SD sessions. Cheers, -- Ondřej Surý -- Technical Fellow CZ.NIC, z.s.p.o.-- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.s...@nic.czhttps://nic.cz/ - Original Message - > From: internet-dra...@ietf.org > To: i-d-annou...@ietf.org > Cc: "dnsop" > Sent: Tuesday, 14 March, 2017 00:44:49 > Subject: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations of the IETF. > >Title : DNS Session Signaling >Authors : Ray Bellis > Stuart Cheshire > John Dickinson > Sara Dickinson > Allison Mankin > Tom Pusateri > Filename: draft-ietf-dnsop-session-signal-02.txt > Pages : 25 > Date: 2017-03-13 > > Abstract: > The EDNS(0) Extension Mechanism for DNS is explicitly defined to only > have "per-message" semantics. This document defines a new Session > Signaling Opcode used to communicate persistent "per-session" > operations, expressed using type-length-value (TLV) syntax, and > defines an initial set of TLVs used to manage session timeouts and > termination. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-dnsop-session-signal-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-session-signal-02 > > > 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. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] UDP fragmentation vs multiple-responses and multi-qtypes
multi-qtypes Security Considerations says: >The method documented here does not change any of the security >properties of the DNS protocol itself. I don't think this statement is true. Why? a) DNS DDoS threats are real and there was a shift towards minimizing answers. This goes in the reverse direction. But you address this in both security considerations. multiple-responses Security Considerations says: > >Additional records will make DNS responses even larger than they are >currently, leading to larger records that can be used in DNS >reflection attacks. One could mitigate this by only serving >responses to EXTRA requests over TCP or when using Cookies [RFC5395], >although there is no easy way to signal this to a client other than >through the use of the truncate bit. multi-qtypes Security Considerations says: >It should however be noted that this method does increase the >potential amplification factor when the DNS protocol is used as a >vector for a denial of service attack. b) UDP fragmentations - it strongly increases the risk of UDP fragmentation which is strongly discouraged (SHOULD NOT) in BCP 145. also multiple-responses Security Considerations says: >A malicious authoritative server could include a large number of >extra records (and associated DNSSEC information) and attempt to DoS >the recursive by making it do lots of DNSSEC validation. However, >this is not considered a realistic threat; CPU for validation is >cheap compared to bandwidth. This can be mitigated by allowing the >recursive resolver to ignore Additional records whenever it considers >itself under attack or its CPU resources are otherwise over- >committed. It should be noted, that ECC validation is more CPU intensive than RSA, as as such I find "CPU for validation is cheap compared to bandwidth" quite bold claim that should come with some data. Cheers, -- Ondřej Surý -- Technical Fellow CZ.NIC, z.s.p.o.-- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.s...@nic.czhttps://nic.cz/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Clarification: Complete or not-complete RRSets in AUTHORITY section? (non-DNSSEC)
Hi there, I am seeking clarification on NS RRSet completeness in AUTHORITY section as we are tackling one particular RPL test from Unbound (iter_pcname.rpl). Imagine a situation where parent (.net/.com NS) gives this glue: QUESTION .example.com. IN A ANSWER AUTHORITY example.com. IN NS ns.example.net. example.com. IN NS ns.example.com. ADDITIONAL ns.example.net. IN A 10.0.0.1 ns.example.com. IN A 10.0.0.2 ~~~ ns.example.net. gives QUESTION www.example.com. IN A ANSWER www.example.com. IN A 10.10.10.1 AUTHORITY example.com. IN NS ns.example.com. ADDITIONAL ns.example.com. IN A 10.0.0.2 ~~~ ns.example.com. just returns SERVFAIL ~~~ And resolver is asked to resolve: Step 1: www.example.com. -> OK, returns 10.10.10.1 Step 2: mail.example.com. -> SERVFAIL, because the NS RRset has been overwritten by www.example.com ANSWER data from AUTHORITY due RFC 2181 5.4.1 Ranking: > Data from the authority section of an authoritative answer, Thus only ns.example.com. is asked and it SERVFAILs. ~~~ In my understanding it should be ok to return SERVFAIL, because there's no way to honor the 5.4.1 Ranking and not fail. Or am I missing something really obvious? Ondrej -- Ondřej Surý -- Technical Fellow CZ.NIC, z.s.p.o.-- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.s...@nic.czhttps://nic.cz/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOP Call for Adoption: draft-hardaker-rfc5011-security-considerations
I support this. And found a nit, the document says: The most confusing element of the above equation comes from the "3 * (DNSKEY RRSIG Signature Validity) / 2" but the formula just before doesn't include "3 *" anywhere in it. Cheers, Ondrej -- Ondřej Surý -- Technical Fellow CZ.NIC, z.s.p.o.-- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.s...@nic.czhttps://nic.cz/ - Original Message - > From: "tjw ietf" > To: "dnsop" > Sent: Thursday, 16 March, 2017 08:16:50 > Subject: [DNSOP] DNSOP Call for Adoption: > draft-hardaker-rfc5011-security-considerations > All > > We've had a lot of WG discussion on this, and it seems relevant to do a formal > call for adoption. If there are outstanding issues raised during the CfA, time > in Chicago will be set aside to have those discussions. > > > This starts a Call for Adoption for: > draft-hardaker-rfc5011-security-considerations > > The draft is available here: > [ > https://datatracker.ietf.org/doc/draft-hardaker-rfc5011-security-considerations/ > | > https://datatracker.ietf.org/doc/draft-hardaker-rfc5011-security-considerations/ > ] > > Please review this draft to see if you think it is suitable for adoption by > DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > If there are > > This call for adoption ends: 30 March 2017 > > Thanks, > tim wicinski > DNSOP co-chair > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-01.txt
Hi, as promised here's copy of my mic comment: The draft is missing TLSA records (RFC 6698). Ondřej On 5 March 2017 18:39:29 internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations of the IETF. Title : DNS Scoped Data Through '_Underscore' Attribute Leaves Author : Dave Crocker Filename: draft-ietf-dnsop-attrleaf-01.txt Pages : 12 Date: 2017-03-05 Abstract: Historically, any DNS RR may occur for any domain name. Recent additions have defined DNS leaf nodes that contain a reserved node name, beginning with an underscore. The underscore construct is used to define a semantic scope for DNS records that are associated with the parent domain. This specification explores the nature of this DNS usage and defines the "underscore names" registry with IANA. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-attrleaf-01 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Fwd: [Curdle] Protocol Action: 'EdDSA for DNSSEC' to Proposed Standard (draft-ietf-curdle-dnskey-eddsa-03.txt)
Dear colleagues, the EDDSA for DNSSEC have been approved by IESG. Ondřej and Robert, co-editors --- Forwarded message --- From: The IESG Date: 9 January 2017 16:23:28 Subject: [Curdle] Protocol Action: 'EdDSA for DNSSEC' to Proposed Standard (draft-ietf-curdle-dnskey-eddsa-03.txt) To: IETF-Announce CC: cur...@ietf.org, curdle-cha...@ietf.org, Daniel Migault , draft-ietf-curdle-dnskey-ed...@ietf.org, The IESG , stephen.farr...@cs.tcd.ie, rfc-edi...@rfc-editor.org The IESG has approved the following document: - 'EdDSA for DNSSEC' (draft-ietf-curdle-dnskey-eddsa-03.txt) as Proposed Standard This document is the product of the CURves, Deprecating and a Little more Encryption Working Group. The IESG contact persons are Stephen Farrell and Kathleen Moriarty. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-dnskey-eddsa/ Technical Summary This document describes how to specify EdDSA keys and signatures in DNS Security (DNSSEC). It uses the Edwards-curve Digital Security Algorithm (EdDSA) with the choice of two curves, Ed25519 and Ed448. Working Group Summary The definition of the signature format was straight forward as it already exists in DNSSEC. In addition the computation and verification of the signature is defined in [I-D.irtf-cfrg-eddsa]. The only discussion was upon the use of using Ed25519ctx versus Ed25519, but the consensus was reached easily. The same discussion also occurred for draft-ietf-ipsecme-eddsa and draft-ietf-curdle-pkix with the same conclusion. The absence of context follows the recommendations of Section 10.3 of I-D.irtf-cfrg-eddsa and avoids unnecessarily complexity. Document Quality The document has been reviewed carefully. Examples have been generated with prototypes. Although no implementations have been reported in the document, there are ongoing effort. Personnel Document Shepherd: Daniel Migault, AD: Stephen Farrell ___ Curdle mailing list cur...@ietf.org https://www.ietf.org/mailman/listinfo/curdle ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-refuse-any
- Original Message - > From: "神明達哉" > To: "tjw ietf" > Cc: "dnsop" > Sent: Friday, 2 December, 2016 20:55:15 > Subject: Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-refuse-any > - Section 3 > > 1. A DNS responder can choose to select one or subset of RRSets at > the QNAME. > > 'one or subset of RRSets' sounds a bit awkward to me, partly because > 'a subset of RRSets' should include 'one of RRSets' and can thus be > redundant, and partly because 'subset of RRSets" might sound related > to 'subset of an RRSet' (it's actually "a subset of set of RRSets"). > So I'd suggest changing this one of the following: > - "one or a few of RRSets (but not all of them)" > - "one or a few of RRSets" > - "a subset of RRSets" > I personally prefer the first most although it may be too verbose. Just a nitpick about using "subset" in general - it should be either "non-empty subset" (or something else) so I like "one or a few" more. Cheers, Ondrej ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-refuse-any
I don't feel very strongly about renaming the draft. I just find a little bit confusing and I imagine I might not be the only one who might feel that way. One way or another I have already reviewed -03 versions of the draft and I think it is ready for publication. Cheers, -- Ondřej Surý -- Technical Fellow CZ.NIC, z.s.p.o.-- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.s...@nic.czhttps://nic.cz/ - Original Message - > From: "tjw ietf" > To: "dnsop" > Sent: Saturday, 26 November, 2016 01:50:48 > Subject: [DNSOP] Working Group Last Call draft-ietf-dnsop-refuse-any > All > > The authors have addressed all the outstanding issues with this draft, and the > chairs feel this is ready for Working Group Last Call. > > There has been one issue raised which we feel the working group may have some > opinion on this. > > Ondrej Sury raised this point: > > > > > > There's a small procedural thing - the last name of the draft > appears on both datatracker.i.o and tools.i.o. I believe it > would be better to reupload the draft with name changed to > > draft-ietf-dnsop-minimal-any > > to prevent the people who might thing the name of the draft > bears any significance. As this requires almost no effort > I think it would be better to this now than fend of the > questions "why is this refuse-any while it doesn't refuse > ANY" later. > > > The authors and the Chairs support this in principle, but the working group > should comment on this during the WGLC process. > > - > This starts a Working Group Last Call for > draft-ietf-dnsop-refuse-any > > Current versions of the draft is available here: > > [ https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/ | > https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/ ] > > Please review the draft and offer relevant comments. Also, if someone feels > the > document is *not* ready for publication, please speak out with your reasons. > > *Also*, if you have any opinion on changing the document named from > 'refuse-any' > to 'minimal-any', please speak out. > > > This starts a two week Working Group Last Call process, and ends on 10 > December, > 2016 > > thanks > tim > > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-dickinson-dnsop-dns-capture-format
+1 for adoption, and I will try to actively review more drafts from now again. Not only this one. O. -- Ondřej Surý -- Technical Fellow CZ.NIC, z.s.p.o.-- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.s...@nic.czhttps://nic.cz/ - Original Message - > From: "tjw ietf" > To: "dnsop" > Sent: Tuesday, 15 November, 2016 09:09:28 > Subject: [DNSOP] Call for Adoption: draft-dickinson-dnsop-dns-capture-format > All > > The response from the room today was pretty positive this draft was worth > adopting and pursuing. We felt their was little benefit in waiting to begin > this Call for Adoption. > > This starts a Call for Adoption for draft-dickinson-dnsop-dns-capture-format > > The draft is available here: > > [ https://datatracker.ietf.org/doc/draft-dickinson-dnsop-dns-capture-format/ | > https://datatracker.ietf.org/doc/draft-dickinson-dnsop-dns-capture-format/ ] > > Please review this draft to see if you think it is suitable for adoption by > DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 1 December 2016. > > Thanks, > tim wicinski > DNSOP co-chair > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] The DNSOP WG has placed draft-wallstrom-dnsop-dns-delegation-requirements in state "Candidate for WG Adoption"
Dear all, I reviewed draft-wallstrom-dnsop-dns-delegation and I think it useful as an overview of the current RFC on the subject are. At the same time I think that in some parts it doesn't match the current (or possibly) future operational best practice. One such example is the "@ MX 0 ." that's commonly used to express that no mail should be ever received at the child zone (and honored by most reasonable mail servers). Therefore I would like to reiterate what I said during the dnsop meeting in Seoul. This is certainly a valuable document, but it makes more sense to keep it close to the tool that uses the rules contained within this document. As the operational practice changes, the document outside the IETF could be updated much faster, and some parts could say: Although RFC recommends , the current operational practice is . Zonemaster and other possible tools might than have an option for RFC-level strictness, or it could be more relaxed. That would allow for better flexibility when there's a need - similar to various TLS testing tools out there. ~~~ As a nit - you use terms "legal hostname" and "valid hostname" without a definition - an language in relevant paragraphs make no distinction. I understand what you are trying to say (legal is about syntax, valid is legal+A or RRSet must exist), others might be confused. Cheers, -- Ondřej Surý -- Technical Fellow CZ.NIC, z.s.p.o.-- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.s...@nic.czhttps://nic.cz/ > - Original Message - >> From: "IETF Secretariat" >> To: draft-wallstrom-dnsop-dns-delegation-requireme...@ietf.org, "dnsop" >> , dnsop-cha...@ietf.org >> Sent: Monday, 14 November, 2016 21:56:36 >> Subject: [DNSOP] The DNSOP WG has placed >> draft-wallstrom-dnsop-dns-delegation-requirements in state "Candidate for WG >> Adoption" > >> The DNSOP WG has placed draft-wallstrom-dnsop-dns-delegation-requirements >> in state >> Candidate for WG Adoption (entered by Tim Wicinski) >> >> The document is available at >> https://datatracker.ietf.org/doc/draft-wallstrom-dnsop-dns-delegation-requirements/ >> >> ___ >> DNSOP mailing list >> DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] The DNSOP WG has placed draft-wallstrom-dnsop-dns-delegation-requirements in state "Candidate for WG Adoption"
Dear all, I reviewed draft-wallstrom-dnsop-dns-delegation and I think -- Ondřej Surý -- Technical Fellow CZ.NIC, z.s.p.o.-- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.s...@nic.czhttps://nic.cz/ - Original Message - > From: "IETF Secretariat" > To: draft-wallstrom-dnsop-dns-delegation-requireme...@ietf.org, "dnsop" > , dnsop-cha...@ietf.org > Sent: Monday, 14 November, 2016 21:56:36 > Subject: [DNSOP] The DNSOP WG has placed > draft-wallstrom-dnsop-dns-delegation-requirements in state "Candidate for WG > Adoption" > The DNSOP WG has placed draft-wallstrom-dnsop-dns-delegation-requirements > in state > Candidate for WG Adoption (entered by Tim Wicinski) > > The document is available at > https://datatracker.ietf.org/doc/draft-wallstrom-dnsop-dns-delegation-requirements/ > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-03.txt
Section 7 (nit): s/implimentations/implementations/ Otherwise I have reviewed the document and I believe it's ready to be put in the oven. ~~~ There's a small procedural thing - the last name of the draft appears on both datatracker.i.o and tools.i.o. I believe it would be better to reupload the draft with name changed to draft-ietf-dnsop-minimal-any to prevent the people who might thing the name of the draft bears any significance. As this requires almost no effort I think it would be better to this now than fend of the questions "why is this refuse-any while it doesn't refuse ANY" later. Cheers, -- Ondřej Surý -- Technical Fellow CZ.NIC, z.s.p.o.-- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.s...@nic.czhttps://nic.cz/ - Original Message - > From: "Ólafur Guðmundsson" > To: "dnsop" > Sent: Wednesday, 16 November, 2016 06:47:43 > Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-03.txt > Dear colleagues > > This version addresses all the outstanding requests for changes. > The editors believe this version is ready for WGLC. > > thanks > Olafur > > > On Wed, Nov 16, 2016 at 2:44 PM, < [ mailto:internet-dra...@ietf.org | > internet-dra...@ietf.org ] > wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations of the IETF. > > Title : Providing Minimal-Sized Responses to DNS Queries with QTYPE=ANY > Authors : Joe Abley > Olafur Gudmundsson > Marek Majkowski > Filename : draft-ietf-dnsop-refuse-any-03.txt > Pages : 9 > Date : 2016-11-15 > > Abstract: > The Domain Name System (DNS) specifies a query type (QTYPE) "ANY". > The operator of an authoritative DNS server might choose not to > respond to such queries for reasons of local policy, motivated by > security, performance or other reasons. > > The DNS specification does not include specific guidance for the > behaviour of DNS servers or clients in this situation. This document > aims to provide such guidance. > > > The IETF datatracker status page for this draft is: > [ https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/ | > https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/ ] > > There's also a htmlized version available at: > [ https://tools.ietf.org/html/draft-ietf-dnsop-refuse-any-03 | > https://tools.ietf.org/html/draft-ietf-dnsop-refuse-any-03 ] > > A diff from the previous version is available at: > [ https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-refuse-any-03 | > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-refuse-any-03 ] > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at [ http://tools.ietf.org/ > | > tools.ietf.org ] . > > Internet-Drafts are also available by anonymous FTP at: > [ ftp://ftp.ietf.org/internet-drafts/ | ftp://ftp.ietf.org/internet-drafts/ ] > > ___ > DNSOP mailing list > [ mailto:DNSOP@ietf.org | DNSOP@ietf.org ] > [ https://www.ietf.org/mailman/listinfo/dnsop | > https://www.ietf.org/mailman/listinfo/dnsop ] > > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSSEC operational issues long term
Mikael, the operation of the root zone and signing of the root zone is in the ICANN/IANA bailiwick. Therefore most of the relevant document to the RZ DNSSEC operations can be found at https://www.iana.org/dnssec/ and the document you are most interested in is here: http://data.iana.org/root-anchors/draft-icann-dnssec-trust-anchor.html + the files https://www.iana.org/dnssec/files It might be worth letting them know if you feel that the documentation is incomplete or inaccurate. ~~~ As a side note for dnsop: It might be worthwhile to either revive draft-ietf-dnsop-dnssec-trust-anchor as Informational or let the IANA adopt that as an IANA document. Cheers, -- Ondřej Surý -- Technical Fellow CZ.NIC, z.s.p.o.-- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.s...@nic.czhttps://nic.cz/ - Original Message - > From: "Mikael Abrahamsson" > To: "Ondřej Surý" > Cc: "dnsop" > Sent: Thursday, 17 November, 2016 02:45:24 > Subject: Re: [DNSOP] DNSSEC operational issues long term > On Thu, 17 Nov 2016, Ondřej Surý wrote: > >> Again, you are using unfair arguments. The devices have to cope with >> that and it doesn't have to be a protocol design. > > Agreed. It can also be method design. There have been some suggestions in > this thread for ways to handle the problem. I have not seen any that is > actually an RFC, preferrably a BCP type document that descibes the problem > and suggests how it can be handled. > > Or is there a document I have missed I can point vendors and IETF people > to, to understand and handle this DNSSEC property (that doesn't seem to be > well known, I talked to several people this morning who had no idea this > DNSSEC limitation existed). > > -- > Mikael Abrahamssonemail: swm...@swm.pp.se ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSSEC operational issues long term
- Original Message - > From: "Mikael Abrahamsson" > To: "Ted Lemon" > Cc: "dnsop" > Sent: Thursday, 17 November, 2016 01:44:59 > Subject: Re: [DNSOP] DNSSEC operational issues long term > On Thu, 17 Nov 2016, Ted Lemon wrote: > >> Embedded systems of this sort need to have a management process so that >> that can be updated. This is needed for more reasons than DNSSEC. Putting a >> ten year old device on a network without upgrading the firmware is >> irresponsible. > > We have been discussing zerotouch (ie 0 day no-human-intervention plugin > of device). This includes the device configuring itself by means of > different methods, and also software-updating itself before it starts to > provide any services. > > DNSSEC (possibly DANE) has been proposed to be one way of finding this > configuration. This is now obviously out of the question unless the > problem I described can be solved. > > So this all boils down to: > > Do the people involved in DNSSEC want their protocol to be part of the > long term solution of securing boostrapping things? Yes? No? > > Right now the answer is no. 9 months shelf life and then DNSSEC fails is > just not usable for things that don't have active human intervention in > its configuration and setup. Again, you are using unfair arguments. The devices have to cope with that and it doesn't have to be a protocol design. Say the vendor used WoSign, StartSSL or other wonky CA that will be deprecated and now the firmware site uses CA, that didn't exist before. The same question could be rephrased as: Do the people involved in PKIX want their protocol to be part of the long term solution of securing bootstrapping things? Yes? No? Or you can accept the fact that you can use cross-signed secure material and you might happen to have a public key for that. For PKIX, that would be a different CA that cross-signed the new one; for DNSSEC, that would be the ICANN-CA. Inventing new knobs and workarounds for dusty devices in the DNS protocol won't improve this (much). Cheers, -- Ondřej Surý -- Technical Fellow CZ.NIC, z.s.p.o.-- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.s...@nic.czhttps://nic.cz/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSSEC operational issues long term
- Original Message - > From: "Dan York" > To: "Mark Andrews" > Cc: "Evan Hunt" , "Bob Harold" , "dnsop" > , "Mikael Abrahamsson" > > Sent: Wednesday, 16 November, 2016 23:28:18 > Subject: Re: [DNSOP] DNSSEC operational issues long term > > On Nov 17, 2016, at 6:46 AM, Mark Andrews < [ mailto:ma...@isc.org | > ma...@isc.org ] > wrote: > > Is it that hard to add a sim or sd card reader? This is the solution > the cable industry uses for its crypto issues but with bigger form > factor cards. > > ... the home CPE market is extremely LOW-margin right now. Service providers > and > regular home users are looking for the cheapest options out there. Adding in a > card reader adds cost and complexity - and a potential tech support issue - > and > the reality is that I suspect the *vast* majority of users will not ever run > into this issue. Most users will buy the box and connect it to their network > and have the trust anchors just work. > > Given the low margin, my suspicion is that most CPE manufacturers would NOT > want > to add in any additional components to solve what for them would be an edge > case in terms of volume. This is the main problem. Most CPE manufacturers don't give a damn about their devices when they are able to sell them successfully to unsuspecting people. So I would suspect that if you bought a low-end device supporting DNSSEC early next year and let it collect a dust for a single year, there's a high chance it won't work either, because there would be no way how to update neither the firmware nor the trust anchors. And even with the usual 2 year warranty most people would not just bother to return faulty device to the seller, because $20 is not worth it. And that's exactly the reason why those vendors are able to do it. Most people just don't care... And I am not convinced that we should design protocols to cater the device vendor irresponsible behavior toward their products. Cheers, -- Ondřej Surý -- Technical Fellow CZ.NIC, z.s.p.o.-- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.s...@nic.czhttps://nic.cz/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSSEC operational issues long term
- Original Message - > From: "Emily Shepherd" > To: "Mikael Abrahamsson" > Cc: "dnsop" > Sent: Wednesday, 16 November, 2016 14:26:53 > Subject: Re: [DNSOP] DNSSEC operational issues long term > On Wed, Nov 16, 2016 at 02:18:17PM +0100, Mikael Abrahamsson wrote: >>Ok, so what I see right now is DNSSEC punting the problem somewhere >>else. NTP is punting it somewhere else. TLS is punting it somehere >>else. > > I don't think this is what people are saying. The issue of trust anchor > updates is one that is not unique to DNSSEC, so it makes sense to look > at some of the solutions other systems which rely on chains of trust > use. What happens, for example, when a Certificate Authority needs to > replace its root certificate? Not only replace - but the ecosystem changes. If you wake-up a device that has been in box for 10 years, it has woke up to a work where Let's Encrypt is largest CA. And how likely it has support for modern crypto, or heck even for SHA2 CA trust anchors. If your device supports crypto it has to be vendor supported for all those 10 years, because frankly the world spins so fast now, that there are so many little things that could break, that DNSSEC is a least of your problems. Vendor has to provide a way how upload a new firmware (possibly in a way a common user can do that). Our phones are supported for 2-3 years and that's only when we are lucky. I strongly believe that you have built an use case to prove something is wrong, but I think it's your use case that's wrong in this case. Cheers, -- Ondřej Surý -- Technical Fellow CZ.NIC, z.s.p.o.-- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.s...@nic.czhttps://nic.cz/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
