Is this workgroup more appropriate to drive possible change? Has it any
means to modify ietf.org infrastructure?
Forwarded Message
Subject:DNSSEC algorithm used on ietf.org
Date: Wed, 23 Mar 2022 12:28:39 +0100
From: Petr Menšík
Organization: Red Hat
To: tools
y our DNS products. I haven't
heard about it even being considered this way.
I know it might not be best time for it yet, but it has to come someday.
>
> Paul
>
> Sent using a virtual keyboard on a phone
>
>> On Mar 23, 2022, at 15:31, Petr Menšík wrote:
>>
>>
On 3/23/22 15:56, Paul Hoffman wrote:
> On Mar 23, 2022, at 7:30 AM, Petr Menšík wrote:
>> Is this workgroup more appropriate to drive possible change? Has it any
>> means to modify ietf.org infrastructure?
> No and no.
>
> Having said that, please see below for comm
On 3/23/22 18:41, Paul Hoffman wrote:
> On Mar 23, 2022, at 10:04 AM, Petr Menšík wrote:
>>>> I work in Red Hat on DNS related products. We were analysing impact on
>>>> disabling algorithm RSASHA1.
>>> The impact is clear: you will cause many validly-signed
catch whatever is using md5, thus might be insecure. This must
not happen with SHA-1, because NSEC3 does not have any equivalent and
cannot work without it. Regardless used key algorithm, unless I am mistaken.
On 3/23/22 19:21, Brian Dickson wrote:
>
>
> On Wed, Mar 23, 2022 at 9:22 AM Pe
require updated
protocol or just modification of existing software? Is the described
behaviour forbidden by existing RFCs?
Any help or comments would be very welcome.
Best Regards,
Petr Menšík
1. https://bugzilla.redhat.com/show_bug.cgi?id=2077884
--
Petr Menšík
Software Engineer
Red Hat, http
Thank you for those references, they are very useful.
I need to discuss our stance internally first. I think we should have a
better response prepared.
It may take a few days to formulate and explain our direction.
Thanks,
Petr
On 4/25/22 12:02, Bjørn Mork wrote:
> Petr Menšík wri
some time. I am sorry for a disturbance caused. Only minor issues will
arise. Thank you for your attention and I hope I haven't caused any harm.
Best Regards, Petr Menšík
1.
https://en.wikipedia.org/wiki/RSA_numbers#RSA-250
2.
https://csrc.nist.gov/CSRC/media/Projects/cryptogra
--
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
sm contain significant drawback, why it would
not be a good idea?
Best Regards,
Petr Menšík
1. https://ohai.social/@miri64/110819255462045467
2. https://arxiv.org/abs/2207.07486
3.
https://www.ietf.org/archive/id/draft-ietf-core-dns-over-coap-03.html#section-4.3.2
--
Petr Menšík
Software Engi
On 8/4/23 02:45, Ray Bellis wrote:
On 04/08/2023 00:29, Petr Menšík wrote:
What do you think, would such mechanism be useful even on classic
DNS? Are there already deployed alternatives? How useful something
similar might be? Does such mechanism contain significant drawback,
why it would not
ame, yes. It only reduces transmitted bytes
and may avoid TCP retry. And potentially unneeded re-validation of
unmodified records.
Petr
--
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
OpenPGP_0x4931CA5B6C9FC5CB.asc
Descri
https://mailarchive.ietf.org/arch/msg/pqc/CfFbKJyS4YA8hWgXLeOMCQm9kd0/
--
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
OpenPGP_0x4931CA5B6C9FC5CB.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital sign
13 matches
Mail list logo
