I would propose one line per protocol for disabled methods. This would
allow for easier log parsing
On 2022-09-13 06:28, Petr Špaček wrote:
On 02. 09. 22 15:49, Anand Buddhdev wrote: On 02/09/2022 13:53, Mark
Andrews wrote:
Hi Mark,
We don't log rsamd5 is disabled now ec or ed curves
On 02. 09. 22 15:49, Anand Buddhdev wrote:
On 02/09/2022 13:53, Mark Andrews wrote:
Hi Mark,
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?
The problem I see with 9.18.6 is that at startup,
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.
> 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
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.
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.
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
On 02/09/2022 13:53, Mark Andrews wrote:
Hi Mark,
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?
The problem I see with 9.18.6 is that at startup, it is checking to see
if it can validate
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
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?
--
Mark Andrews
> On 2 Sep 2022, at 20:37, Anand Buddhdev wrote:
>
> On 01/09/2022 23:19, Mark Andrews wrote:
>
> Hi Mark,
>
>> Yes. You will
On 01/09/2022 23:19, Mark Andrews wrote:
Hi Mark,
Yes. You will need to restart the server.
Okay, I'm trying out 9.18.6 on an Oracle Linux 9 server. When starting
BIND, it doesn't log anything about disabling RSASHA1. But when I query
it for ietf.org/SOA, I get an unvalidated response.
Yes. You will need to restart the server.
That all said if you are signing zones using RSASHA1 or NSEC3RSASHA1 you should
transition to a newer algorithm if you want to have your zone validated by as
many as possible.
--
Mark Andrews
> On 1 Sep 2022, at 22:59, Anand Buddhdev wrote:
>
>
12 matches
Mail list logo
