[DNSOP] Re: Questions before adopting must-not-sha1
Yes, I know it does not help now. In fact what blocked me on enabling it in the build were not passing unit tests and other tests after the build. I solved them by using this recipe at Fedora [1]. I will try to enable it in new minor RHEL versions, but already published releases will probably stay the same they are now. With SHA1 disabled at build time. I will try to fix it on following releases, because I now have working way to pass the build, including tests with it. Watch RHEL-8465 ticket for progress [2]. Cheers, Petr 1. https://src.fedoraproject.org/rpms/unbound/pull-request/17 2. https://issues.redhat.com/browse/RHEL-8465 On 17. 11. 24 16:12, Philip Homburg wrote: I have found there is no need to link to different library. What is needed is just different *configuration*. I found a very simple method to share with you: Use OPENSSL_CONF environment to point to conf file containing: .include = /etc/ssl/openssl.cnf [evp_properties] rh-allow-sha1-signatures = yes That is all needed to get SHA1 verification in DNSSEC back, without accepting SHA1 in TLS connections at the same time. Cool, eh? At the risk of going off-topic, it seems that Red Hat is shipping packages with unbound is compiled without support for RSASHA1. So this trick is unlikely help. -- Petr Menšík Senior Software Engineer, RHEL Red Hat, http://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB OpenPGP_0x4931CA5B6C9FC5CB.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: Questions before adopting must-not-sha1
On Sun, 17 Nov 2024, Philip Homburg wrote: [indeed a bit offtopic] Use OPENSSL_CONF environment to point to conf file containing: .include = /etc/ssl/openssl.cnf [evp_properties] rh-allow-sha1-signatures = yes That is all needed to get SHA1 verification in DNSSEC back, without accepting SHA1 in TLS connections at the same time. Cool, eh? At the risk of going off-topic, it seems that Red Hat is shipping packages with unbound is compiled without support for RSASHA1. So this trick is unlikely help. Correct, it is now compiled using --disable-sha1. I think it would be better to enable this again, assuming unbound now has proper code to detect if sha1 is failing or not during runtime. Then the crypto-policies can be used to enable this again. If this was a dedicated container/host, it could simply use: update-crypto-policies --set LEGACY It seems "sha1_in_dnssec" has been obsoleted. I do not know what this was done, I think it was a perfectly fine method to create a crypto policy submodule only enabling sha1 for DNSSEC. Paul ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Minutes from IETF121 and Chairs Actions
All Thanks for productive meetings, and thank you Mr Hoffman for minute taking. I've uploaded them into the datatracker earlier this week, and want to include the Chair's actions we have taken away. We will prioritize these later this week during our chairs call. thanks tim --- # DNSOP IETF121 Chairs Actions * draft-ietf-dnsop-rfc8624-bis - Chairs Action: WGLC * draft-crocker-dnsop-dnssec-algorithm-lifecycle - Chairs Action: authors requested adoption call * draft-buraglio-deprecate7050 - Chairs Action: Interest in adopting * Does draft-momoka-dnsop-3901bis belong in DNSOP? - Chairs Action: schedule call for adoption (same action as from ietf118) * draft-sheth-dns-integration - Chairs Action: some interest in adopting but more discussion * draft-bortzmeyer-more-edes - Chairs Action: No need to adopt unless changing the registry (no interest in that) * draft-davies-internal-tld - Chairs Action: interest in adopting, but also not sure what value. ISE? * draft-fujiwara-dnsop-dns-upper-limit-values - Chairs Action: Interest, but more discussion * draft-eastlake-dnsop-rfc2930bis-tkey and draft-eastlake-dnsop-rfc2931bis-sigzero - Chairs Action: Needs more work https://datatracker.ietf.org/doc/minutes-121-dnsop/ # DNSOP IETF121 Chairs Actions * draft-ietf-dnsop-rfc8624-bis - Chairs Action: WGLC * draft-crocker-dnsop-dnssec-algorithm-lifecycle - Chairs Action: authors requested adoption call * draft-buraglio-deprecate7050 - Chairs Action: Interest in adopting * Does draft-momoka-dnsop-3901bis belong in DNSOP? - Chairs Action: schedule call for adoption (same action as from ietf118) * draft-sheth-dns-integration - Chairs Action: some interest in adopting but more discussion * draft-bortzmeyer-more-edes - Chairs Action: No need to adopt unless changing the registry (no interest in that) * draft-davies-internal-tld - Chairs Action: interest in adopting, but also not sure what value. ISE? * draft-fujiwara-dnsop-dns-upper-limit-values - Chairs Action: Interest, but more discussion * draft-eastlake-dnsop-rfc2930bis-tkey and draft-eastlake-dnsop-rfc2931bis-sigzero - Chairs Action: Needs more work DNSOP WG Minutes Dublin, Ireland Session 1 Date: Monday, November 4, 2024 Time: 1730-1900 local Chairs: Benno Overeinder, Suzanne Woolf, Tim Wicinski Only discussion during the mic line are covered here, not the slides You should definitely read the slides Minutes by Paul Hoffman Administrivia, Chairs Opening, Note Well and Blue Sheets Lots of review of the past few months in the slides Hackathon results ?? draft-ietf-dnsop-generalized-notify, Peter Thomassen https://datatracker.ietf.org/doc/draft-ietf-dnsop-generalized-notify/ See slides Domain Control Validation using DNS, Shivan Sahib https://datatracker.ietf.org/doc/draft-ietf-dnsop-domain-verification-techniques/ Ben Schwartz: Used in places where it is not the right approach This is a kind of weird thing to want Instead it's the other way around: Hey domain name, is this user associated with it? Thinks text about this is buried in the security considerations Shivan: Is this a point-in-time check, or long-term? (Point-in-time) Shumon Huque: Agrees that moving this section up is good Is good to categorize applications that do DCV Not good for long term Ben: Provide good guidance earlier in the doc Shumon: Can reorganize the doc to make it more readable Helped get ACME to make improvements that are in play DNSSEC Cryptographic Algorithm Recommendation Update Process, Wes Hardaker https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8624-bis/ Daniel Kahn Gillmor: Doesn't like using RECOMMENDED because this doesn't help administrator pick one Wes: Didn't want to get into the discussion of what is the one to do Jim Reid: What is the distinction between implementing and using Wes: Implementers write code, users use Tommy Jensen: Doesn't want the implementation column to have a too-narrow list Mike St Johns: Should instead talk about publication side versus client side Wes: Send text to help make the distinction DNS IPv6 Transport Operational Guidelines, Momoka Yamamoto and Tobias Fiebig https://datatracker.ietf.org/doc/draft-momoka-dnsop-3901bis/ Wes: In v6, you can't figure out what's broken This is a bigger problem than just the DNS Geoff Huston wants to fix v6 How will I even be able to detect the problem? We're stuck in the middle Èric Vynke: Would love to have this document Be more careful of when you cannot follow the SHOULD The IANA considerations is only about IANA zones, not good Tommy: Likes this, OK with splitting out We need to work on this, is willing to help Eric Nygren: Important work for us to do
[DNSOP] Re: Questions before adopting must-not-sha1
On 18. 11. 24 15:37, Paul Wouters wrote: On Sun, 17 Nov 2024, Philip Homburg wrote: [indeed a bit offtopic] Correct, it is now compiled using --disable-sha1. I think it would be better to enable this again, assuming unbound now has proper code to detect if sha1 is failing or not during runtime. Then the crypto-policies can be used to enable this again. If this was a dedicated container/host, it could simply use: update-crypto-policies --set LEGACY If the whole talk were about complaining of actually worsening overall security, then using LEGACY should not be proposed to improve that. If you can, use DEFAULT:SHA1. The method with custom OPENSSL_CONF is the most secure way I know, because it still won't allow SHA1 in TLS, but allow it only for generic signature verification, like in DNSSEC. It seems "sha1_in_dnssec" has been obsoleted. I do not know what this was done, I think it was a perfectly fine method to create a crypto policy submodule only enabling sha1 for DNSSEC. Paul There is no way an user can signal into OpenSSL library that he wants it used for DNSSEC verification (or signing) only. Therefore you cannot demand DNSSEC submodule itself. But I think crypto team could have made submodule allowing just generic SHA1 signature verification, where not other uses of SHA-1. You know those people more than I do. They are not DNSSEC supporters and have kind of hard stance to SHA-1. They say nobody should use it anymore and do not want to invest more resources to make it better. Regards, Petr -- Petr Menšík Senior Software Engineer, RHEL Red Hat, http://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB OpenPGP_0x4931CA5B6C9FC5CB.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
