Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
On Thu, May 2, 2024 at 11:38 AM John R Levine wrote: > I think we're agreeing that it would be a good idea to continue to > discourage SHA1, but not a good idea to surprise people by making it > suddenly stop working, a la Redhat. > Yep. Conceptually I agree with that. I also realized its inherent in RFC 8624 that it only makes sense if interpreted as guidance to those developing the software and tools that implement DNSSEC signing and/or validation. A DNS operator is only going to sign a specific zone with a single algorithm except during an algorithm roll. And there's no choice of algorithms when deploying a validating resolver. On any platform I've ever encountered, for the most part turning DNSSEC validation on or off is a binary choice. The algorithms that are or aren't supported are built into the software. With that noted, the three drafts are suitable for working group adoption. I support the idea of expressing the table in RFC 8624 in the IANA registry and outlining that future recommendation changes can be applied there in a consolidated location. I do think that should be the sole focus of that draft and the rest of the text and the table of initial recommendations should reflect the current RFC 8624 text. Then the discussion of the other two drafts can focus on whether the recommendations in the current RFC 8624 table should be changed. Thanks, Scott ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
On Thu, 2 May 2024, Scott Morizot wrote: I think we need a clean update to RFC 8624 first that includes instructions to IANA to update the table. I don't think the current draft does that very well. And since the IANA table already has a Zone Signing column, I think we just want to change that one so it has more than a yes/no option per algorithm and then add a Validation column. I think we're agreeing that it would be a good idea to continue to discourage SHA1, but not a good idea to surprise people by making it suddenly stop working, a la Redhat. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
On Thu, May 2, 2024 at 9:19 AM John R Levine wrote: > On Thu, 2 May 2024, Scott Morizot wrote: > > ??? RFC 8624 is explicitly guidance to implementers not operators. The > > "MUST NOT" means MUST NOT implement in a conforming implementation of > > either signing or validation software. That's not an opinion. It's what > the > > text says. > > The word "software" does not appear in RFC 8624. I think it is evident > from the text that the implementers are the people using DNS software and > signing the zones. > > Ondřej and Paul wrote the RFC so perhaps they can tell us what they meant. > I would be curious about that since it's not how I'm used to "implementer" being used in any DNS context. And it also would mean this sentence in the audience section would then make no sense. "This perspective may differ from that of a user who wishes to deploy and configure DNSSEC with only the safest algorithm." I think we need a clean update to RFC 8624 first that includes instructions to IANA to update the table. I don't think the current draft does that very well. And since the IANA table already has a Zone Signing column, I think we just want to change that one so it has more than a yes/no option per algorithm and then add a Validation column. Once that has been adopted then there will actually be columns to update published at IANA. But in any context I've seen over the years the DNS implementers have always been the ones who develop and maintain the supporting tools and software. Users, operators, and terms like that have referred to those of us who deploy and administer authoritative zones and recursive resolvers. Scott ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
On Thu, 2 May 2024, Scott Morizot wrote: On Thu, May 2, 2024 at 7:32 AM John R Levine wrote: MUST NOT is advice on how to interoperate, not on how to write software tools. It's up to the zone operator to follow the advice, not to the tool provider to hold them hostage. ??? RFC 8624 is explicitly guidance to implementers not operators. The "MUST NOT" means MUST NOT implement in a conforming implementation of either signing or validation software. That's not an opinion. It's what the text says. The word "software" does not appear in RFC 8624. I think it is evident from the text that the implementers are the people using DNS software and signing the zones. Ondřej and Paul wrote the RFC so perhaps they can tell us what they meant. R's, John PS: I don't think there is much practical difference between the NOT RECOMMENDED in 8624 and a draft that says MUST NOT to signers, so I would also be perfectly happy to leave things as is and abandon the draft. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
On Thu, May 2, 2024 at 7:32 AM John R Levine wrote: > MUST NOT is advice on how to interoperate, not on how to write software > tools. It's up to the zone operator to follow the advice, not to the tool > provider to hold them hostage. > ??? RFC 8624 is explicitly guidance to implementers not operators. The "MUST NOT" means MUST NOT implement in a conforming implementation of either signing or validation software. That's not an opinion. It's what the text says. It does acknowledge it can be useful guidance to others, but its audience is expressly DNSSEC implementers not users of DNSSEC. Sure, an implementer can choose to ignore the guidance. But creating an environment where implementers have to do that sort of seems to defeat the purpose of RFC 8624. 1.3. Document Audience The recommendations of this document mostly target DNSSEC implementers, as implementations need to meet both high security expectations as well as high interoperability between various vendors and with different versions. Interoperability requires a smooth transition to more secure algorithms. This perspective may differ from that of a user who wishes to deploy and configure DNSSEC with only the safest algorithm. On the other hand, the comments and recommendations in this document are also expected to be useful for such users. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
On Thu, May 2, 2024 at 6:44 AM John Levine wrote: > It appears that Philip Homburg said: > >In your letter dated Thu, 2 May 2024 10:27:17 +0200 you wrote: > >>I'm not following what breaks based on the wording I suggested, and I'm > not su > >>re why you keep bringing that up. :-) > > > >Then an RFC gets published that signers MUST NOT support signing using > SHA1, > >so ldns removes those algorithms. Then a software update brings the new > >version of ldns my system. Now an unsigned zone gets deployed, > > On the other hand, if it issued annoying warning messages every time it > used a SHA1 key, I'd eventually notice and probably rotate the keys. > > I'm with Peter, I do not see a MUST NOT as requiring vendors or operators > to do stupid stuff. > A MUST NOT in RFC 8624 directs implementations to remove their implementation of an algorithm. The current NOT RECOMMENDED is the appropriate recommendation, according to the text of an RFC, for an implementation to issue a warning that the algorithm is deprecated and should not be used for signing. Here's the description of the intent in the deprecation process outlined in RFC 8624. It seems to me this discussion has strayed from that core process to various perspectives about whether or not SHA-1 remains "secure enough". "It is expected that deprecation of an algorithm will be performed gradually in a series of updates to this document. 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. Since the effect of using an unknown DNSKEY algorithm is that the zone is treated as insecure, it is recommended that algorithms downgraded to NOT RECOMMENDED or lower not be used by authoritative nameservers and DNSSEC signers to create new DNSKEYs. This will allow for deprecated algorithms to become less and less common over time. Once an algorithm has reached a sufficiently low level of deployment, it can be marked as MUST NOT so that recursive resolvers can remove support for validating it. Recursive nameservers are encouraged to retain support for all algorithms not marked as MUST NOT." I have seen absolutely no "strong security reasons" presented in this discussion for altering that deprecation model when it comes to DNSSEC algorithms 5 and 7. (I would consider 5 less widely deployed, but since the only difference between the two is support for NSEC3 I don't see a reason to treat them differently.) Algorithm 7 remains widely used and by zones most people would consider significant. In the US, for instance, that includes cdc.gov. Moreover, as others have pointed out, the following assertion in the draft is factually wrong. I'm not going to support a standards document that can't even accurately state facts. "This document retires the use of SHA-1 within DNSSEC." Well, no. It doesn't. NSEC3 will continue to require SHA-1 until such time as that standard is also changed. The draft instructs implementations to no longer support algorithms 5 and 7 for both signing and validation and by changing both to MUST NOT at the same time it contravenes the deprecation model outlined in RFC 8624 without providing any justification beyond some security hand-waving. RFC 8624 provides the correct guidance to implementations for the current state of use for algorithms 5 and 7. There are no "strong security reasons" for deviating from the deprecation model outlined in the RFC. "NOT RECOMMENDED" for signing means the same as "SHOULD NOT". (That's also included with the RFC reference in the text of RFC 8624.) That seems appropriate for signing implementations to issue warnings that the algorithms are deprecated for signing if they choose. The guidance for support in validators is not supposed to move to MUST NOT until an algorithm has reached a low enough level of deployment. I don't see how anyone can reasonably argue that is the case today for algorithm 7. In my opinion, this draft should not move forward. Scott ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
I'm with Peter, I do not see a MUST NOT as requiring vendors or operators to do stupid stuff. For my understanding, do you mean to say that if we publish that a signer MUST NOT generate signatures using algorithms 5 and 7, then the signer can just do that if it generates and annoying warning each time you sign? To me that sounds more like a SHOULD NOT. MUST NOT is advice on how to interoperate, not on how to write software tools. It's up to the zone operator to follow the advice, not to the tool provider to hold them hostage. 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] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
>On the other hand, if it issued annoying warning messages every time it >used a SHA1 key, I'd eventually notice and probably rotate the keys. > >I'm with Peter, I do not see a MUST NOT as requiring vendors or operators >to do stupid stuff. For my understanding, do you mean to say that if we publish that a signer MUST NOT generate signatures using algorithms 5 and 7, then the signer can just do that if it generates and annoying warning each time you sign? To me that sounds more like a SHOULD NOT. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
It appears that Philip Homburg said: >In your letter dated Thu, 2 May 2024 10:27:17 +0200 you wrote: >>I'm not following what breaks based on the wording I suggested, and I'm not su >>re why you keep bringing that up. :-) > >Let's say I sign my zones using some scripts and ldns-signzone. This >has been working for years so is now on autopilot. > >Then an RFC gets published that signers MUST NOT support signing using SHA1, >so ldns removes those algorithms. Then a software update brings the new >version of ldns my system. Now an unsigned zone gets deployed, I use ldns-signzone in my DNS toaster, and if I had SHA1 keys and it stopped signing with the keys I have, updates would crash and nothing would get updated in my DNS. I would certainly notice and would not be happy. On the other hand, if it issued annoying warning messages every time it used a SHA1 key, I'd eventually notice and probably rotate the keys. I'm with Peter, I do not see a MUST NOT as requiring vendors or operators to do stupid stuff. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
Hi Philip, On 2 May 2024, at 10:38, Philip Homburg wrote: > Let's say I sign my zones using some scripts and ldns-signzone. This > has been working for years so is now on autopilot. > > Then an RFC gets published that signers MUST NOT support signing using SHA1, > so ldns removes those algorithms. Then a software update brings the new > version of ldns my system. Now an unsigned zone gets deployed, and the whole > zone is considered bogus by validators who see valid DS record but not a > corresponding signed zone. DNSSEC is not a fire-and-forget system. It adds brittleness to the DNS because it introduces reasons for failure that were not previously there. It requires signatures to be updated, which means it requires changes that were not previosly required in order to keep things in a reasonable state. What you describe above is not very different to my amateur-maintained mail server (that I keep begging my family members to stop using for important things) that routinely breaks because I've blindly upgraded a package and become distracted before checking that everything still works. In those kinds of situations it often breaks, and it should break, because it's not responsible to run an poorly-maintained mail server on the Internet. I am one of many people who have volunteered their time in capacity-building projects in developing regions of the Internet over the past couple of decades. When those projects have included DNSSEC, I try to drill into people that DNSSEC is not just a checkbox or a sign of competence; it's an ongoing responsibility, and if you don't have the resources or inclination to look after it carefully after you have deployed it, the result will be failure and instability. DNSSEC is like a cat. It requires care and feeding. You should not buy one for Christmas and ignore it. Generally, I do not think it's a problem that unmaintained DNSSEC infrastructure might lead to failures because of changes to the protocol. I think it's a feature. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
Another thought on the below ... On 5/2/24 09:42, Philip Homburg wrote: The IETF is not the protocol police so it seems unlikely that signers are going to suddenly remove all traces of SHA1 signing and leave their users in the dark. Independently of SHA-1, it's a reasonable use case to be able to perform an algorithm rollover away from a deprecated algorithm, without going insecure. So, as long as the standards do not prohibit validation with a certain algorithm, it seems like signing with it for transition purposes should be admissible. How about we add a sentence to rfc8624-bis saying that "MUST NOT" in the context of the "Recommended for DNSSEC signing" column does not apply while actively preparing orperforming an algorithm rollover away from that algorithm. This would (1) enable this use case; (2) give implementers a good reason to not kill the actual implementation, but rather turn it off / put warnings there / require an extra setting / ... Best, Peter -- https://desec.io/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
On 5/2/24 10:37, Philip Homburg wrote: In your letter dated Thu, 2 May 2024 10:27:17 +0200 you wrote: I'm not following what breaks based on the wording I suggested, and I'm not su re why you keep bringing that up. :-) Let's say I sign my zones using some scripts and ldns-signzone. This has been working for years so is now on autopilot. Then an RFC gets published that signers MUST NOT support signing using SHA1, so ldns removes those algorithms. Then a software update brings the new version of ldns my system. Now an unsigned zone gets deployed, I don't think the draft warrants that assumption. I'd think that the software update or signing pipeline or replication mechanism would somehow make the admin aware that action needs to be taken. This is no different from any other kind of potentially significant change, such as the change in OpenVPN configuration format between certain updates. In any case, I don't consider this concern (which I find valid) a matter of standardization. It's up to ldns to decide how to handle it, e.g. by releasing a new major version to indicate a compatibility risk, etc. Peter -- https://desec.io/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
In your letter dated Thu, 2 May 2024 10:27:17 +0200 you wrote: >I'm not following what breaks based on the wording I suggested, and I'm not su >re why you keep bringing that up. :-) Let's say I sign my zones using some scripts and ldns-signzone. This has been working for years so is now on autopilot. Then an RFC gets published that signers MUST NOT support signing using SHA1, so ldns removes those algorithms. Then a software update brings the new version of ldns my system. Now an unsigned zone gets deployed, and the whole zone is considered bogus by validators who see valid DS record but not a corresponding signed zone. My reading is that this is what the draft tries to do. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
On 5/2/24 10:19, Philip Homburg wrote: In your letter dated Thu, 2 May 2024 09:58:43 +0200 you wrote: Right. Their policy may be "it's compliant and it works, so why roll?". It'll be easier to push those SHA-1 signers to switch if one can tell them "look, no w you're not compliant anymore". So basically we need a BCP: operators of zones MUST NOT sign their zones with algorithms 5 and 7. If they currently do, they need to move away from those algorithms as quickly as possible. I somewhat agree that this could also be done as a BCP. However, a MUST NOT there and a MUST NOT elsewhere is still a MUST NOT, and I'd prefer them to be in the same place as all the other algorithm recommendations. To me, that would sound better then trying to break protocols to get people to move. I'm not following what breaks based on the wording I suggested, and I'm not sure why you keep bringing that up. :-) Peter -- https://desec.io/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
In your letter dated Thu, 2 May 2024 09:58:43 +0200 you wrote: >Right. Their policy may be "it's compliant and it works, so why roll?". It'll >be easier to push those SHA-1 signers to switch if one can tell them "look, no >w you're not compliant anymore". So basically we need a BCP: operators of zones MUST NOT sign their zones with algorithms 5 and 7. If they currently do, they need to move away from those algorithms as quickly as possible. To me, that would sound better then trying to break protocols to get people to move. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
On 5/2/24 09:42, Philip Homburg wrote: In your letter dated Thu, 2 May 2024 09:21:29 +0200 you wrote: In my view, it's fine to disallow signing with SHA-1-based algorithms to help push signers towards other algorithms. I appreciate the effort, but I'm curious what that means. As far as I know, just about all zones that start signing are not using SHA1 as part of the signature. There is not really an issue with new installations. The affected algorithms have been marked as not recommended for many years so we can assume that in just about any signer they are not the default. The problem is with existing zones who probably have an existing relationship with signer software. Right. Their policy may be "it's compliant and it works, so why roll?". It'll be easier to push those SHA-1 signers to switch if one can tell them "look, now you're not compliant anymore". Peter -- https://desec.io/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
In your letter dated Thu, 2 May 2024 09:21:29 +0200 you wrote: >In my view, it's fine to disallow signing with SHA-1-based algorithms to help >push signers towards other algorithms. I appreciate the effort, but I'm curious what that means. As far as I know, just about all zones that start signing are not using SHA1 as part of the signature. There is not really an issue with new installations. The affected algorithms have been marked as not recommended for many years so we can assume that in just about any signer they are not the default. The problem is with existing zones who probably have an existing relationship with signer software. The IETF is not the protocol police so it seems unlikely that signers are going to suddenly remove all traces of SHA1 signing and leave their users in the dark. Worse, if signers would do that, then there is a distinct risk that people will just use old software. This may have the effect that new signers will not implement these algorithms. However, that will probably be until the first customer comes along who requests these algorithms. Adding RSA+SHA1 is trivial if you already have RSA+SHA2. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
I agree with all that Paul said (and also the other Paul). In my view, it's fine to disallow signing with SHA-1-based algorithms to help push signers towards other algorithms. For interoperability reasons, barring a security threat, I do not think it is appropriate to discourage validation. My impression is that several people share this view, so I created a PR with suggested changes in that direction. Diff: https://github.com/hardaker/draft-hardaker-dnsop-must-not-sha1/pull/3/files (I've created the PR directly as this document has not been adopted.) Best, Peter On 4/30/24 16:04, Paul Wouters wrote: On Tue, 30 Apr 2024, Philip Homburg wrote: The advise is split between producing SHA1 signatures and consuming SHA1 signatures, and those timings do not have to be identical. That said, a number of OSes have already forced the issue by failing SHA1 as cryptographic operation (RHEL, CentOS, Fedora, maybe more). So right now, if you run DNSSEC with SHA1 (which includes NSEC3 using SHA1), your validator might already return it as an insecure zone. I think a MUST NOT for signing with SHA1 is a no-brainer. The timing for MAY on validation should be relatively short (eg 0-2 years?) What worries me about the draft is the security section. I can understand the desire to get rid of old crypto, but as far as I can tell this draft will mostly decrease security. It will also prevent ServFails when the system crypto SHA1 for authentication and signature purposes is blocked, and the DNS software sees this as a failure and returns BOGUS. I am not sure how many DNS implementations are now probing SHA1 and on failure put it in the "unsupported algorithm" class, to serve it as insecure instead of bogus. This issue did hit RHEL,CentOS, Fedora. We can accept as given that it is easy to find collisions for SHA1. However, a second pre-image attack is way off in the future. I'm not too concerned about that. Looking at the signer part, this is not great either. Moving away from SHA1 requires an algorithm roll-over. DNSSEC is already quite fragile and algorithm rolls are worse. So there is a failure risk that is too big ignore. Yes, this fragility is why there are still zones using SHA1 at all. But I think software and DNS services have no matured to the point where it is save to do. Eg bind, opendnssec, knot. This draft requires zones that do not have a collision risk to move to a different algorithm, at a significant risk, but there is no increase in security. So that part is also a net negative for security. Staying at SHA1 incurs the above risk of SHA1 leading to Bogus/ServFail. So it seems that we are asked to adopt a draft that will mostly reduce security, not increase it. It prevents zone outages. There might be other arguments for adopting the draft, such a Redhat not validating signatures with SHA1 anymore. But those arguments are not mentioned in the draft. I guess these considerations can be added to the draft if the WG wants? And if some companies from one country want to shoot themselves in the foot, does the rest of the world have to follow? The IETF and its cryptographic policies are a careful interworking between market forces, reality and desire. Moving to fast leads to RFCs being ignored. Moving too slow means RFCs do not encourage modernization. Every other protocol has left SHA1 behind. It's time for DNS to follow suit. It's had its "exemption" for a few years already. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Like our community service? Please consider donating at https://desec.io/ deSEC e.V. Kyffhäuserstr. 5 10781 Berlin Germany Vorstandsvorsitz: Nils Wisiol Registergericht: AG Berlin (Charlottenburg) VR 37525 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
Hello, At 04:54 PM 30-04-2024, Paul Wouters wrote: On Tue, 30 Apr 2024, Paul Hoffman wrote: Is that something within the realm of ICANN? Perhaps the DNS Tech Day ? You ask those questions sounding as if ICANN staff had not already done so. Why not share the data if you have some? This is the list of TLDs affected: [snip] int.(international orgs - important) Matters related to int. are discussed in RFC 9121. It's a good idea to get some data. It's not a good idea to take a decision by fiat on matters directly related treaty-based organizations. Regards, S. Moonesamy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
On Tue, 30 Apr 2024, Paul Hoffman wrote: Is that something within the realm of ICANN? Perhaps the DNS Tech Day ? You ask those questions sounding as if ICANN staff had not already done so. Why not share the data if you have some? This is the list of TLDs affected: apple. brand TLD beats. brand TLD gd. (Grenada) int.(international orgs - important) kpn.(dutch telco, 59 registrations) la. (Laos) lk. (Sri Lanka) samsung. brand TLD storage. gTLD with 589 registrations vn. (Vietnam) xn--cg4bki (samsung? only contains 2 registrations) xn--l1acc(mongolia related? only contains 7 registrations) xn--mgbai9azgqp6j (??? 0 registrations) xn--q7ce6a (Laos 0 registrations) Note this only includes 4 ccTLDs and the 1 international TLD. The rest of the 14 seems brand/vanity or test/idn domains, and a small gTLD that might be running in "keep the lights on" mode. Can ICANN or anyone from Grenada, Laos, Sri Lanka or Vietnam tell us what is keeping them from moving away from SHA1? Or perhaps a liaison statement from IETF to ICANN ? Such a statement would be quite a different action than the threat of making all the zones under many TLDs go insecure. This thread is about WG adoption of a draft that would do the latter. The "threat" (strong hint) was started five years ago with RFC8624. I'm sure there can be some timeline juggling, but if TLDs still have no plans to move, will they ever move until forced? This really does seem to be the tail end of the long tail. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
Paul Hoffman writes: > This cull-because-of-low usage thread incorrectly assumes that the DNS > is flat instead of a hierarchy. A few points: 1. I only pointed at data that people were asking for. I did not state my personal opinion. 2. I published the drafts based on desires by people to have them published. I'm at the will of the WG in the long run with respect to publishing vs not (as all document authors should be). 3. The whole discussion, IMHO, is side-stepping the real issue: if not now, then when? IE, do we never put something at MUST NOT? Is there a usage threshold? Is it "must be zero"? Is it "known to be broken and everyone must have a flag day instead of a slower process"? These are not easy questions, and there does seem to be many different opinions. RedHat led the pack(ish), and maybe Paul and others will be the tail end at some very late value. There is no right or wrong, and the line of people are likely to spread out along the timeline. And what makes the situation worse is not whether or not "we" want the timeline to have a fixed transition point, but the roll out and adoption and abandoning of older software in the DNS(SEC) landscape takes a really really long time. So the trade off of when to say "stop using this" vs "all software has already stopped using it" has a really really long gap in the middle. There is no perfect. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
On Apr 30, 2024, at 16:00, Paul Wouters wrote: > > On Apr 30, 2024, at 18:42, Paul Hoffman wrote: >> >> This cull-because-of-low usage thread incorrectly assumes that the DNS is >> flat instead of a hierarchy. The last I saw, there are 14 TLDs who use >> RSASHA1. Advancing this draft as-is means that all of the zones under those >> TLDs would be completely wiped out as well. Or maybe that's what the WG >> wants? > > Not wiped out. Being made insecure (versus part of the world only treating > them insecure) Fair point. "Made their efforts to use DNSSEC useless" would have been a better way to say it. > It’s worth contacting them for timelines of migration away from SHA1, as RFC > 8624 is five years old and that already told them to start moving. > > Is that something within the realm of ICANN? Perhaps the DNS Tech Day ? You ask those questions sounding as if ICANN staff had not already done so. > Or perhaps a liaison statement from IETF to ICANN ? Such a statement would be quite a different action than the threat of making all the zones under many TLDs go insecure. This thread is about WG adoption of a draft that would do the latter. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
On Apr 30, 2024, at 18:42, Paul Hoffman wrote: > > This cull-because-of-low usage thread incorrectly assumes that the DNS is > flat instead of a hierarchy. The last I saw, there are 14 TLDs who use > RSASHA1. Advancing this draft as-is means that all of the zones under those > TLDs would be completely wiped out as well. Or maybe that's what the WG wants? Not wiped out. Being made insecure (versus part of the world only treating them insecure) It’s worth contacting them for timelines of migration away from SHA1, as RFC 8624 is five years old and that already told them to start moving. Is that something within the realm of ICANN? Perhaps the DNS Tech Day ? Or perhaps a liaison statement from IETF to ICANN ? Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
On 1 May 2024, at 00:42, Paul Hoffman wrote: > This cull-because-of-low usage thread incorrectly assumes that the DNS is > flat instead of a hierarchy. The last I saw, there are 14 TLDs who use > RSASHA1. Advancing this draft as-is means that all of the zones under those > TLDs would be completely wiped out as well. Wiped out sounds rather final. In reality things that break get fixed if people care about them. Sometimes a forcing function is useful. If we really didn't believe this to be true we would never deprecate anything. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
This cull-because-of-low usage thread incorrectly assumes that the DNS is flat instead of a hierarchy. The last I saw, there are 14 TLDs who use RSASHA1. Advancing this draft as-is means that all of the zones under those TLDs would be completely wiped out as well. Or maybe that's what the WG wants? --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
Paul Wouters writes: > Perhaps Viktor can share his updated numbers with us. Viktor's daily scanning numbers are host on our USC/ISI server at: https://stats.dnssec-tools.org/#/?dnssec_param_tab=0 Click on "DNSSEC Parameter Trends" followed by "KSK algorithm", etc. KSK usage (click on the "domain count" column to get the sorting to match this): 13 11145536 8 11065103 10 205662 14 144076 7 119678 (rsash1-nsec3-sha1) 5 19750 (rsasha1) 15 13497 The SHA1 counts are 2 orders of magnitude lower than the EC and SHA256 based algorithms. To see trends, you can click on labels on the graph to remove them from the graph to zoom in on the nearly flat lines at the bottom. ZSK counts are similar (oddly 7 is slightly higher and 5 is slightly lower). -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
The people arguing for adoption seem to have two major arguments: 1) we should punish zones that sign with old algorithms by making compliant resolvers treat them as insecure 2) we should make it impossible for zones to sign or re-sign with old algorithms #1 affects resolvers, in particular the resolver's security policies. It is based on as-yet unsupported assertions of the lack of safety for SHA-1 in DNSSEC signatures or DS records. #2 affects signing software (and maybe authoritative software?). It is based on the fact that there is a large known set of resolvers that will treat zones signed with SHA-1 (and maybe zones covered with SHA-1 DS records?) as insecure, and the fact that there are easily-chosen alternatives that do not (yet) have this problem. The current must-not-sha1 is worded around #1. I am currently against adoption for that reason. If it was instead worded around #2, it would be easier to support. I am still saddened by the level of interest in these documents, at the expense of other DNSSEC-related documents that are clearly more important. We could be much closer to more stable DNSSEC operations if people showed interest in those WG drafts instead of wanting to pile on more drafts, particularly those that make DNSSEC less safe for some existing users. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
On Tue, 30 Apr 2024, Philip Homburg wrote: - FIPS - PCI-DSS - BSI - OWASP - SOC2 - PKI-industry & CAB/Forum - TLS, IPsec/IKE, OpenPGP, SMIME, et all at IETF. - All the cryptographers including CFRG The problem is that none if them did an impact analysis for this draft. I phrase it the other way around: The DNS community failed to track industry wide commitments and requirements for many years. Yes of course, in isolation it is good to move away from SHA1. Nobody says SHA1 is great, we should promote it. RFC 8624 already says that algorithms 5 and 7 are not recommended for signing. That's from 2019. It could use an update from SHOULD NOT to MUST NOT. That's exactly what this document does. If not now, when would you want to change it? I was reluctant too until I saw the numbers from Viktor about to low amount of SHA1 zones left a few months ago. However, going ahead and breaking things is something different. And that is exactly what is proposed here. And that is something that doesn't give security benefits. Just a reduction of security in the name of crypto purity. As explained, it will cause less breakage not more. It will also cause more insecure zones, but that is not "breakage" and these zones are far behind current practices. I found my old viktor messages, so I refound: https://stats.dnssec-tools.org/#/?top=parameters_param_tab=0 19750 out of 22,713,302 aka 0.08% is using RSASHA1 119678 out of 22,713,302 aka 0.52% is using NEC3-RSASHA1 at 0.6%, I think it is long time to say MUST NOT. Yes that half percent will see their DNSSEC status reduced to insecure, but on the plus side, it won't cause sha1 bogus servfail errors anywhere. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
>- FIPS >- PCI-DSS >- BSI >- OWASP >- SOC2 >- PKI-industry & CAB/Forum >- TLS, IPsec/IKE, OpenPGP, SMIME, et all at IETF. >- All the cryptographers including CFRG The problem is that none if them did an impact analysis for this draft. Yes of course, in isolation it is good to move away from SHA1. Nobody says SHA1 is great, we should promote it. RFC 8624 already says that algorithms 5 and 7 are not recommended for signing. However, going ahead and breaking things is something different. And that is exactly what is proposed here. And that is something that doesn't give security benefits. Just a reduction of security in the name of crypto purity. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
And that doesn’t fail in RH with the tighter crypto. -- Mark Andrews > On 1 May 2024, at 00:46, Paul Wouters wrote: > > On Wed, 1 May 2024, Mark Andrews wrote: > >> One got servfail because validators where not aware that support was ripped >> away underneath it. Validators started to get errors that where totally >> unexpected. Performing runtime testing of algorithm support addressed that >> by allowing the validator to skip the unsupported algorithm. > > The runtime check for SHA1 helped put RSA-SHA1 / NSEC3-RSA-SHA1 into the > "unsupported" category, but RSA-SHA256 with NSEC3 still uses SHA1 > for hashing the QNAME, and while not cryptogrpahic use, still had > problems in practise. I don't remember the full details, but I think > it related to wildcard proofs of non-existence of some kind, leading > to validation failures. > > Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
The validators where not returning BOGUS. They where returning unknown error. Both errors resulted in servfail. Once we knew what RH had done one could go from compile time testing of support to runtime testing of support. The DNSSEC RFC’s already told developers how to handle this. RSASHA1 is just treated as any other unsupported algorithm if there is not runtime support. Unfortunately there isn’t an easy test. You have to attempt to verify a known good signature. -- Mark Andrews > On 1 May 2024, at 00:41, Mark Andrews wrote: > > One got servfail because validators where not aware that support was ripped > away underneath it. Validators started to get errors that where totally > unexpected. Performing runtime testing of algorithm support addressed that by > allowing the validator to skip the unsupported algorithm. > -- > Mark Andrews > >> On 1 May 2024, at 00:04, Paul Wouters wrote: >> On Tue, 30 Apr 2024, Philip Homburg wrote: >> The advise is split between producing SHA1 signatures and consuming SHA1 signatures, and those timings do not have to be identical. That said, a number of OSes have already forced the issue by failing SHA1 as cryptographic operation (RHEL, CentOS, Fedora, maybe more). So right now, if you run DNSSEC with SHA1 (which includes NSEC3 using SHA1), your validator might already return it as an insecure zone. I think a MUST NOT for signing with SHA1 is a no-brainer. The timing for MAY on validation should be relatively short (eg 0-2 years?) >>> >>> What worries me about the draft is the security section. I can understand >>> the desire to get rid of old crypto, but as far as I can tell >>> this draft will mostly decrease security. >> >> It will also prevent ServFails when the system crypto SHA1 for >> authentication and signature purposes is blocked, and the DNS software >> sees this as a failure and returns BOGUS. I am not sure how many DNS >> implementations are now probing SHA1 and on failure put it in the >> "unsupported algorithm" class, to serve it as insecure instead of bogus. >> >> This issue did hit RHEL,CentOS, Fedora. >> >>> We can accept as given that it is easy to find collisions for SHA1. However, >>> a second pre-image attack is way off in the future. >> >> I'm not too concerned about that. >> >>> Looking at the signer part, this is not great either. Moving away from SHA1 >>> requires an algorithm roll-over. DNSSEC is already quite fragile and >>> algorithm >>> rolls are worse. So there is a failure risk that is too big ignore. >> >> Yes, this fragility is why there are still zones using SHA1 at all. But >> I think software and DNS services have no matured to the point where it >> is save to do. Eg bind, opendnssec, knot. >> >>> This draft requires zones that do not have a collision risk to move to a >>> different algorithm, at a significant risk, but there is no increase in >>> security. So that part is also a net negative for security. >> >> Staying at SHA1 incurs the above risk of SHA1 leading to Bogus/ServFail. >> >>> So it seems that we are asked to adopt a draft that will mostly reduce >>> security, not increase it. >> >> It prevents zone outages. >> >>> There might be other arguments for adopting the draft, such a Redhat not >>> validating signatures with SHA1 anymore. But those arguments are not >>> mentioned in the draft. >> >> I guess these considerations can be added to the draft if the WG wants? >> >>> And if some companies from one country want to shoot themselves in the foot, >>> does the rest of the world have to follow? >> >> The IETF and its cryptographic policies are a careful interworking >> between market forces, reality and desire. Moving to fast leads to RFCs >> being ignored. Moving too slow means RFCs do not encourage >> modernization. Every other protocol has left SHA1 behind. It's time for >> DNS to follow suit. It's had its "exemption" for a few years already. >> >> Paul >> >> ___ >> 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] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
On Wed, 1 May 2024, Mark Andrews wrote: One got servfail because validators where not aware that support was ripped away underneath it. Validators started to get errors that where totally unexpected. Performing runtime testing of algorithm support addressed that by allowing the validator to skip the unsupported algorithm. The runtime check for SHA1 helped put RSA-SHA1 / NSEC3-RSA-SHA1 into the "unsupported" category, but RSA-SHA256 with NSEC3 still uses SHA1 for hashing the QNAME, and while not cryptogrpahic use, still had problems in practise. I don't remember the full details, but I think it related to wildcard proofs of non-existence of some kind, leading to validation failures. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
On Tue, 30 Apr 2024, Philip Homburg wrote: So what happens instead is that software is patched to return insecure if SHA1 is not avaiable for signing and that is of course very risky. has been patched, yes. The problem arguably is that DNS moved WAY slower that the industry as a whole to get rid of SHA1. You can blame the industry, but honestly, DNS(SEC) is the outlier here. So it seems that one company is trying set policy. Entities stating to not use SHA1 for cryptographic purposes: - FIPS - PCI-DSS - BSI - OWASP - SOC2 - PKI-industry & CAB/Forum - TLS, IPsec/IKE, OpenPGP, SMIME, et all at IETF. - All the cryptographers including CFRG Given that for a large number of zones, SHA1 does not pose a security risk, there is no 'too slow'. "too slow" is literally what caused this, as the cryptographic libraries and OSes prepared for more centralized OS control and disabling of SHA1 for cryptographic purposes throughout the entire OS. There is a general move to EC for signatures and that solves the SHA1 issue as well. For zones that are currently secure, just let them be secure. They are not guaranteed secure. For some these are insecure already. And endusers or zoneowners might not even be aware of this. And let Redhat ship broken products if they want. I was still at Red Hat when this originally happened, and the DNS software was not prepaered for this. I tried to talk to everyone involved to contain the damage. DNS software got updated. But that was FIVE YEARS ago. I can't believe we are still having a discussion to keep allowing SHA1 five years after the damage started to show. That is a DNS problem, and this draft is the proper way for IETF to signal to people to move away from SHA1. It's the most the IETF can do and it is already damn little. Your proposed alternative seems to be to do nothing, which is clearly ignoring the market and blaming the frontrunner within that market. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
One got servfail because validators where not aware that support was ripped away underneath it. Validators started to get errors that where totally unexpected. Performing runtime testing of algorithm support addressed that by allowing the validator to skip the unsupported algorithm. -- Mark Andrews > On 1 May 2024, at 00:04, Paul Wouters wrote: > On Tue, 30 Apr 2024, Philip Homburg wrote: > >>> The advise is split between producing SHA1 signatures and consuming SHA1 >>> signatures, and those timings do not have to be identical. >>> That said, a number of OSes have already forced the issue by failing >>> SHA1 as cryptographic operation (RHEL, CentOS, Fedora, maybe more). So >>> right now, if you run DNSSEC with SHA1 (which includes NSEC3 using >>> SHA1), your validator might already return it as an insecure zone. >>> I think a MUST NOT for signing with SHA1 is a no-brainer. The timing for >>> MAY on validation should be relatively short (eg 0-2 years?) >> >> What worries me about the draft is the security section. I can understand >> the desire to get rid of old crypto, but as far as I can tell >> this draft will mostly decrease security. > > It will also prevent ServFails when the system crypto SHA1 for > authentication and signature purposes is blocked, and the DNS software > sees this as a failure and returns BOGUS. I am not sure how many DNS > implementations are now probing SHA1 and on failure put it in the > "unsupported algorithm" class, to serve it as insecure instead of bogus. > > This issue did hit RHEL,CentOS, Fedora. > >> We can accept as given that it is easy to find collisions for SHA1. However, >> a second pre-image attack is way off in the future. > > I'm not too concerned about that. > >> Looking at the signer part, this is not great either. Moving away from SHA1 >> requires an algorithm roll-over. DNSSEC is already quite fragile and >> algorithm >> rolls are worse. So there is a failure risk that is too big ignore. > > Yes, this fragility is why there are still zones using SHA1 at all. But > I think software and DNS services have no matured to the point where it > is save to do. Eg bind, opendnssec, knot. > >> This draft requires zones that do not have a collision risk to move to a >> different algorithm, at a significant risk, but there is no increase in >> security. So that part is also a net negative for security. > > Staying at SHA1 incurs the above risk of SHA1 leading to Bogus/ServFail. > >> So it seems that we are asked to adopt a draft that will mostly reduce >> security, not increase it. > > It prevents zone outages. > >> There might be other arguments for adopting the draft, such a Redhat not >> validating signatures with SHA1 anymore. But those arguments are not >> mentioned in the draft. > > I guess these considerations can be added to the draft if the WG wants? > >> And if some companies from one country want to shoot themselves in the foot, >> does the rest of the world have to follow? > > The IETF and its cryptographic policies are a careful interworking > between market forces, reality and desire. Moving to fast leads to RFCs > being ignored. Moving too slow means RFCs do not encourage > modernization. Every other protocol has left SHA1 behind. It's time for > DNS to follow suit. It's had its "exemption" for a few years already. > > Paul > > ___ > 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] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
On Tue, 30 Apr 2024, Mark Andrews wrote: They DO NOT disable SHA1. They disable RSASHA1. The distinction is important. NSEC3 works fine on them. There were issues with NSEC3's use of SHA1 as well. I am failing to find the reports on this now unfortunately. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
>It will also prevent ServFails when the system crypto SHA1 for >authentication and signature purposes is blocked, and the DNS software >sees this as a failure and returns BOGUS. I am not sure how many DNS >implementations are now probing SHA1 and on failure put it in the >"unsupported algorithm" class, to serve it as insecure instead of bogus. > >This issue did hit RHEL,CentOS, Fedora. Bogus would be perfectly fine. The problem is that no operator is going to deploy a system that returns bogus for a commonly used signing algorithm. So what happens instead is that software is patched to return insecure if SHA1 is not avaiable for signing and that is of course very risky. >The IETF and its cryptographic policies are a careful interworking >between market forces, reality and desire. Moving to fast leads to RFCs >being ignored. Moving too slow means RFCs do not encourage >modernization. Every other protocol has left SHA1 behind. It's time for >DNS to follow suit. It's had its "exemption" for a few years already. One thing that keeps showing up in this context is Redhat. RHEL and CentOS are directly controlled by Redat, Fedora is strongly connected to Redhat. So it seems that one company is trying set policy. Not a policy that is grounded in security analysis, a policy based on shipping products that violate current DNSSEC standards. Given that for a large number of zones, SHA1 does not pose a security risk, there is no 'too slow'. There is a general move to EC for signatures and that solves the SHA1 issue as well. For zones that are currently secure, just let them be secure. And let Redhat ship broken products if they want. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
On Tue, 30 Apr 2024, Philip Homburg wrote: The advise is split between producing SHA1 signatures and consuming SHA1 signatures, and those timings do not have to be identical. That said, a number of OSes have already forced the issue by failing SHA1 as cryptographic operation (RHEL, CentOS, Fedora, maybe more). So right now, if you run DNSSEC with SHA1 (which includes NSEC3 using SHA1), your validator might already return it as an insecure zone. I think a MUST NOT for signing with SHA1 is a no-brainer. The timing for MAY on validation should be relatively short (eg 0-2 years?) What worries me about the draft is the security section. I can understand the desire to get rid of old crypto, but as far as I can tell this draft will mostly decrease security. It will also prevent ServFails when the system crypto SHA1 for authentication and signature purposes is blocked, and the DNS software sees this as a failure and returns BOGUS. I am not sure how many DNS implementations are now probing SHA1 and on failure put it in the "unsupported algorithm" class, to serve it as insecure instead of bogus. This issue did hit RHEL,CentOS, Fedora. We can accept as given that it is easy to find collisions for SHA1. However, a second pre-image attack is way off in the future. I'm not too concerned about that. Looking at the signer part, this is not great either. Moving away from SHA1 requires an algorithm roll-over. DNSSEC is already quite fragile and algorithm rolls are worse. So there is a failure risk that is too big ignore. Yes, this fragility is why there are still zones using SHA1 at all. But I think software and DNS services have no matured to the point where it is save to do. Eg bind, opendnssec, knot. This draft requires zones that do not have a collision risk to move to a different algorithm, at a significant risk, but there is no increase in security. So that part is also a net negative for security. Staying at SHA1 incurs the above risk of SHA1 leading to Bogus/ServFail. So it seems that we are asked to adopt a draft that will mostly reduce security, not increase it. It prevents zone outages. There might be other arguments for adopting the draft, such a Redhat not validating signatures with SHA1 anymore. But those arguments are not mentioned in the draft. I guess these considerations can be added to the draft if the WG wants? And if some companies from one country want to shoot themselves in the foot, does the rest of the world have to follow? The IETF and its cryptographic policies are a careful interworking between market forces, reality and desire. Moving to fast leads to RFCs being ignored. Moving too slow means RFCs do not encourage modernization. Every other protocol has left SHA1 behind. It's time for DNS to follow suit. It's had its "exemption" for a few years already. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
>The advise is split between producing SHA1 signatures and consuming SHA1 >signatures, and those timings do not have to be identical. > >That said, a number of OSes have already forced the issue by failing >SHA1 as cryptographic operation (RHEL, CentOS, Fedora, maybe more). So >right now, if you run DNSSEC with SHA1 (which includes NSEC3 using >SHA1), your validator might already return it as an insecure zone. > >I think a MUST NOT for signing with SHA1 is a no-brainer. The timing for >MAY on validation should be relatively short (eg 0-2 years?) What worries me about the draft is the security section. I can understand the desire to get rid of old crypto, but as far as I can tell this draft will mostly decrease security. We can accept as given that it is easy to find collisions for SHA1. However, a second pre-image attack is way off in the future. >From that we can conclude that for any zone that is now signed using SHA1 and that does not have a risk of collision attacks (because the zone does not accept data controlled by third parties), this draft is a clear reduction of security. For a site that does have a risk of collision attacks the situation is less clear. Such a site should move away from using SHA1, but the recommendation for validators will still cause an immediate reduction of security. Looking at the signer part, this is not great either. Moving away from SHA1 requires an algorithm roll-over. DNSSEC is already quite fragile and algorithm rolls are worse. So there is a failure risk that is too big ignore. This draft requires zones that do not have a collision risk to move to a different algorithm, at a significant risk, but there is no increase in security. So that part is also a net negative for security. So it seems that we are asked to adopt a draft that will mostly reduce security, not increase it. There might be other arguments for adopting the draft, such a Redhat not validating signatures with SHA1 anymore. But those arguments are not mentioned in the draft. And if some companies from one country want to shoot themselves in the foot, does the rest of the world have to follow? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
> On 30 Apr 2024, at 06:00, Paul Wouters wrote: > > On Mon, 29 Apr 2024, Philip Homburg wrote: > >> As far as I know there is no second pre-image attack on SHA1, and there >> will not be one in the foreseeable future. > > Correct. > >> So if we deprecate SHA1 for validators, and assuming validators will follow >> this advice, and some platforms already stopped validating SHA1, then there >> may be zones that are mostly secure today that become insecure or bogus >> when we are done with the draft. > > The advise is split between producing SHA1 signatures and consuming SHA1 > signatures, and those timings do not have to be identical. > > That said, a number of OSes have already forced the issue by failing > SHA1 as cryptographic operation (RHEL, CentOS, Fedora, maybe more). So > right now, if you run DNSSEC with SHA1 (which includes NSEC3 using > SHA1), your validator might already return it as an insecure zone. They DO NOT disable SHA1. They disable RSASHA1. The distinction is important. NSEC3 works fine on them. > I think a MUST NOT for signing with SHA1 is a no-brainer. The timing for > MAY on validation should be relatively short (eg 0-2 years?) > > For NSEC3 requiring SHA1, that will depend a bit on whether DNS > validators have rewritten their code to allow the use of SHA1 on > those systems where it is disabled for "cryptographic reasons". I'm > not up to date on it, but my suggestion on adding SHA2 for NSEC3 so > far is not well received. Getting a list of the main resolvers (services > and software) and whether they properly support NSEC3 w SHA1 would > be helpful in making such decisions. > > Paul > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- 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
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
On Apr 29, 2024, at 13:30, Paul Wouters wrote: > > On Mon, 29 Apr 2024, Paul Hoffman wrote: > >> If the purpose of deprecating validation that involves SHA-1 is the decision >> by RedHat to make that entire section of the DNS insecure, the documents >> should say that explicitly. Conflating the pre-image weaknesses of SHA-1 and >> actual useful attacks on DNSSEC, and then using that conflation as the >> reason for the WG adopting these documents, is not useful. > > Redhat is not the source of this. It is the certification people that say you > cannot use SHA1 in cryptographic functions related to authentication, > encryption, or digital signatures. And that these requirements are > getting centrally codified in an OS that cannot take DNS into account. It is still RedHat's choice to read those certification requirements the way that they did; others read them differently. But, regardless of whether we agree with RedHat's decision, if it is that decision that is driving the drafts, the drafts should say that instead of saying that it is some vague concern that has not been substantiated. > Tony Finch and Viktor Dukovhny believe an attack with SHA1 > is possible. I have not yet been convinced by them. See: > https://www.dns.cam.ac.uk/news/2020-01-09-sha-mbles.html I too am not convinced that an attack that needs >250 bytes of identical preamble can apply to DNSSEC-relevant records such as DS, DNSKEY, NSEC, and NSEC3. More than four years after it was published, the original paper (https://sha-mbles.github.io/) has not been updated with any more detail related to DNSSEC, nor do others seem to have followed up. (Note: I could totally have missed such followups; if so, I'm quite interested to hear of them!) --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
On Mon, 29 Apr 2024, Paul Hoffman wrote: If the purpose of deprecating validation that involves SHA-1 is the decision by RedHat to make that entire section of the DNS insecure, the documents should say that explicitly. Conflating the pre-image weaknesses of SHA-1 and actual useful attacks on DNSSEC, and then using that conflation as the reason for the WG adopting these documents, is not useful. Redhat is not the source of this. It is the certification people that say you cannot use SHA1 in cryptographic functions related to authentication, encryption, or digital signatures. And that these requirements are getting centrally codified in an OS that cannot take DNS into account. (And, if anyone believes that collision reduction attacks on a hash are likely to lead to preimage reduction attacks, please look at the literature about MD5. The collision resistance has been massively reduced, and there is still zero preimage reduction after almost 20 years.) Tony Finch and Viktor Dukovhny believe an attack with SHA1 is possible. I have not yet been convinced by them. See: https://www.dns.cam.ac.uk/news/2020-01-09-sha-mbles.html I agree SHA1 in DNSSEC does not pose a risk right now, but also agree that we should push hard for people to stop creating SHA1 based data. Last time Viktor shared data, I think SHA1 was sufficiently small that we could move forward without breaking too much. Perhaps Viktor can share his updated numbers with us. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
On Apr 29, 2024, at 13:00, Paul Wouters wrote: > That said, a number of OSes have already forced the issue by failing > SHA1 as cryptographic operation (RHEL, CentOS, Fedora, maybe more). So > right now, if you run DNSSEC with SHA1 (which includes NSEC3 using > SHA1), your validator might already return it as an insecure zone. If the purpose of deprecating validation that involves SHA-1 is the decision by RedHat to make that entire section of the DNS insecure, the documents should say that explicitly. Conflating the pre-image weaknesses of SHA-1 and actual useful attacks on DNSSEC, and then using that conflation as the reason for the WG adopting these documents, is not useful. --Paul Hoffman (And, if anyone believes that collision reduction attacks on a hash are likely to lead to preimage reduction attacks, please look at the literature about MD5. The collision resistance has been massively reduced, and there is still zero preimage reduction after almost 20 years.) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
On Mon, 29 Apr 2024, Philip Homburg wrote: As far as I know there is no second pre-image attack on SHA1, and there will not be one in the foreseeable future. Correct. So if we deprecate SHA1 for validators, and assuming validators will follow this advice, and some platforms already stopped validating SHA1, then there may be zones that are mostly secure today that become insecure or bogus when we are done with the draft. The advise is split between producing SHA1 signatures and consuming SHA1 signatures, and those timings do not have to be identical. That said, a number of OSes have already forced the issue by failing SHA1 as cryptographic operation (RHEL, CentOS, Fedora, maybe more). So right now, if you run DNSSEC with SHA1 (which includes NSEC3 using SHA1), your validator might already return it as an insecure zone. I think a MUST NOT for signing with SHA1 is a no-brainer. The timing for MAY on validation should be relatively short (eg 0-2 years?) For NSEC3 requiring SHA1, that will depend a bit on whether DNS validators have rewritten their code to allow the use of SHA1 on those systems where it is disabled for "cryptographic reasons". I'm not up to date on it, but my suggestion on adding SHA2 for NSEC3 so far is not well received. Getting a list of the main resolvers (services and software) and whether they properly support NSEC3 w SHA1 would be helpful in making such decisions. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
>I also don't think that simple, procedural documents that are straightforwardl >y-written and uncontentious ought to present a big drain on the resources of t >he working group. I think if we all tried really hard not to nitpick or to pla >y amateur copy-editors we could probably last-call simple documents quite quic >kly and move on with our lives. I don't know anything about ghost, but there is one thing I worry about when it comes to SHA1. As far as I know there is no second pre-image attack on SHA1, and there will not be one in the foreseeable future. So if we deprecate SHA1 for validators, and assuming validators will follow this advice, and some platforms already stopped validating SHA1, then there may be zones that are mostly secure today that become insecure or bogus when we are done with the draft. That doesn't seem to be a simple procedural discussion. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
On 29 Apr 2024, at 00:19, Paul Hoffman wrote: > On Apr 27, 2024, at 17:38, Tim Wicinski wrote: >> Please review these drafts to see if you think they are suitable for adoption >> by DNSOP, and send any comments to the list, clearly stating your view. > > The WG already has many important DNSSEC-related documents that are not > getting enough attention from WG participants. Each of those documents would > have much more significant effects on the security of the DNS than these > proposed documents. The WG should not adopt these proposed documents until > the more important documents have been standardized. I don't find the security value in these documents as easy to assess as you do. I think in general this is a difficult thing to determine and often only possible with the benefit of hindsight. I also don't think that simple, procedural documents that are straightforwardly-written and uncontentious ought to present a big drain on the resources of the working group. I think if we all tried really hard not to nitpick or to play amateur copy-editors we could probably last-call simple documents quite quickly and move on with our lives. There are costs outside the working group (write-ups, IESG telechat time, etc) but while we obviously don't want to dos the wider collective it's not obvious to me that we should make it our job to manage those resources. If we want to say something, we should say something. To put it another way, if it's so hard to publish a document like must-not-sha1 that the best way to win is not to play, we are doing it wrong. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
On Apr 27, 2024, at 17:38, Tim Wicinski wrote: > Please review these drafts to see if you think they are suitable for adoption > by DNSOP, and send any comments to the list, clearly stating your view. The WG already has many important DNSSEC-related documents that are not getting enough attention from WG participants. Each of those documents would have much more significant effects on the security of the DNS than these proposed documents. The WG should not adopt these proposed documents until the more important documents have been standardized. In the future, there may be more relevant attacks on SHA-1 and ECC-GOST, and adopting these documents would make sense then. The advances in practical attacks on SHA-1 have been slow and somewhat predictable. The use of ECC-GOST outside of regions where it was required is nearly non-existent. The WG's attention is valuable, and spending that attention on documents that do not noticeably affect the actual security of the DNS is not a good use of our time. I propose that Wes keep the drafts alive as personal documents until the WG's DNSSEC documents with much more impact are finished. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
