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
Thank you for your reply. I have added some comments in-line.
On Thu, May 2, 2024 at 10:42 AM Ben Schwartz wrote:
> It seems like this draft says that the indicated MRDS overrides the EDNS
> BUFSIZE value. This seems likely to create problems if the MRDS value
> could be set by a lower layer in
Hi all,
Following up on this; does the group agree that "_dnssec" is OK?
Thank you.
Best regards,
David Dong
IANA Services Sr. Specialist
On Mon Apr 22 11:42:15 2024, scott.r...@nist.gov wrote:
> On 20 Apr 2024, at 19:38, Paul Wouters wrote:
>
> > On Sat, 20 Apr 2024, Peter Thomassen wrote:
It seems like this draft says that the indicated MRDS overrides the EDNS
BUFSIZE value. This seems likely to create problems if the MRDS value could be
set by a lower layer in the stack or a downstream processing component (without
knowledge of DNS), resulting in responses that are too large
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
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
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
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
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
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
>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
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
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
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
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
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
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".
On 5/2/24 10:13, Philip Homburg wrote:
is getting people to sign there zones in the first place (and adding
transport security). But we have time to just kill 140k signed for
no technical reasons?
In the end the current draft has a strong negative effect on the direct
and
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
> e.g. as other OS vendors follow suit and SHA-1 support
> disappears from crypto libraries.
As described by Mark Andrews, one thing that made the Redhat situation more
complex is that they didn't just remove SHA1 signing support, they modified
openssl to return bogus RSA valdation results at
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
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
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.
23 matches
Mail list logo
