Re: BIND 9.18.6 disables RSASHA1 at runtime?
On 9/2/22 14:23, Bjørn Mork wrote: Mark Andrews writes: We don’t log rsamd5 is disabled now ec or ed curves when they are not supported by the crypto provider. Why should rsasha1 based algs be special? Because RSASHA1 validation still is a MUST in RFC8624? MD5 is and ED is not. I don't know if disabled EC curves is a real world problem, but ECDSAP256SHA256 is also a MUST and should get the same treatment. IMHO you should not allow the server to start up with a non-compliant configuration without making sure the adminstrator is aware of the problem. A log warning is sort of a minimum. Personally I'd prefer the server to die by default. It is unsuitable as a validating resolver and forcing adminstrators to find that out the hard way is not very nice. Bjørn I do not think all servers should fail to start on CentOS Stream 9, RHEL9 and derivates. Yes, I have hit too it does not report at all which algorithms are ready to use. But DEFAULT crypto policy on those distributions simply do not allow validation of SHA-1 based signatures to succeed. It is suitable for all other algorithms so I disagree that without algorithms 5 and 7 it is not usable at all. Majority of secured domains use stronger algorithms already. I think it might report at least single line with a list of successfuly initialized algorithms. So it would not report RSASHA1 is not available, but a list of algorithms which are available in this build AND runtime environment. I think such list would be short enough. Administrators should be aware of those issues by reading release notes on affected distributions. They should not be surprised so much. Regards, Petr -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.18.6 disables RSASHA1 at runtime?
Petr Menšík writes: > It is suitable for all other algorithms so I disagree that > without algorithms 5 and 7 it is not usable at all. Majority of > secured domains use stronger algorithms already. Would it be the same if it worked for a majority of TLDs? Say "nz" as an arbitrary example. Would still work fine for a majority of users. It would probably take me some time before I noticed. After all, I rarely have a need to look up "nz" domains. And when it occasionally failed I'd probably never would have blamed Redhat. IMHO BIND without RSASHA1 is useless as a validating resolver as long as there are RSASHA1 signed zones out there. At least as long as this is still allowed. And it is. Hence the MUST validate. The classical example of a failing domain is https://dnsviz.net/d/paypal.com/dnssec/ Maybe acceptable for you? Definitely not for me or my customers. I want DNSSEC validation on that domain. I'd certainly prefer a stronger algorithm. But that's not an option, is it? So, yes, I prefer to be forced to acknowledge this issue. And refusing to start without some form of explicit adminstrator action is the only way that works in my experience. Not enough admins read logs ;-) Bjørn -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.18.6 disables RSASHA1 at runtime?
Petr, care to prepare a MR for this? After all, it's RedHat who is making us all to go through this mess. 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 5. 9. 2022, at 9:56, Petr Menšík wrote: > > I think it might report at least single line with a list of successfuly > initialized algorithms. So it would not report RSASHA1 is not available, but > a list of algorithms which are available in this build AND runtime > environment. I think such list would be short enough. signature.asc Description: Message signed with OpenPGP -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.18.6 disables RSASHA1 at runtime?
> On 5 Sep 2022, at 18:41, Bjørn Mork wrote: > > Petr Menšík writes: > >> It is suitable for all other algorithms so I disagree that >> without algorithms 5 and 7 it is not usable at all. Majority of >> secured domains use stronger algorithms already. > > Would it be the same if it worked for a majority of TLDs? Say "nz" as > an arbitrary example. Would still work fine for a majority of users. It > would probably take me some time before I noticed. After all, I rarely > have a need to look up "nz" domains. And when it occasionally failed I'd > probably never would have blamed Redhat. > > IMHO BIND without RSASHA1 is useless as a validating resolver as long as > there are RSASHA1 signed zones out there. At least as long as this is > still allowed. And it is. Hence the MUST validate. It does validate. Remember the results of validation are secure, insecure, or bogus. The point of the change is ensure that lookups DO NOT FAIL because the OS has removed / disabled support for RSASHA1. Without the change lookups failed with SERVFAIL unless you explicitly said to disable RSASHA1 and NSEC3RSASHA1. With the change they validate as insecure. > The classical example of a failing domain is > https://dnsviz.net/d/paypal.com/dnssec/ > Maybe acceptable for you? Definitely not for me or my customers. I > want DNSSEC validation on that domain. I'd certainly prefer a stronger > algorithm. But that's not an option, is it? What records in paypal.com do you or your customers actually depend upon being signed? Paypal’s web servers depend on CAs not the DNS to provide trust anchors. It's not their SMTP servers as paypalcorp.com is not signed. Yes, I’d like Paypal to have moved to something that is not RSASHA1 based for DNSSEC but at the moment, for all practical uses, whether the zone validates as secure or insecure doesn’t matter. > So, yes, I prefer to be forced to acknowledge this issue. And refusing > to start without some form of explicit adminstrator action is the only > way that works in my experience. Not enough admins read logs ;-) > > > > Bjørn > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from > this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.18.6 disables RSASHA1 at runtime?
Mark Andrews writes: > What records in paypal.com do you or your customers actually depend upon > being signed? Paypal’s web servers depend on CAs not the DNS to provide > trust anchors. It's not their SMTP servers as paypalcorp.com is not signed. OK, let's just hope no CA runs Redhat then. Bjørn -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Mailing list questions (DMARC, ARC, more?)
On Sun 04/Sep/2022 14:17:25 +0200 Benny Pedersen wrote: ARC-Authentication-Results: i=1; mx.pao1.isc.org; dmarc=pass (p=none dis=none) header.from=tana.it; spf=pass smtp.mailfrom=tana.it; dkim=permerror (0-bit key) header.d=tana.it header.i=@tana.it That stanza is faulty. The key at epsilon._domainkey.tana.it is 256 bits, like all ed25519 keys, not 0. Presumably ISC's DKIM filter doesn't support RFC8463. header.b=j8VJHYFh; dkim=pass (1152-bit key; unprotected) header.d=tana.it header.i=@tana.it header.b=DBspF3JP The second signature, rsa, succeeds. However, why unprotected? Presumably the library used by ISC's DKIM filter doesn't support DNSSEC. you have a invalid dkim signing, fix that Nothing to fix on my side. note you on top of that dkim double sign one is working, one is failing That's why I put two. Best Ale -- -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
