Dear DNSOP WG,
Paul Vixue and I submitted draft-ietf-dnsop-avoid-fragmentation-04.txt .
https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/
https://tools.ietf.org/html/draft-ietf-dnsop-avoid-fragmentation-04
We changed to use "default maximum DNS/UDP payload size" instead
On Thu, 25 Feb 2021 at 14:14, Ben Schwartz wrote:
> The most interesting informational element, in my view, would be guidance
> on how to detect buggy implementations that will create this problem. (Set
> up a test zone and a test resolver and ...?). I think the best practice is
> probably to m
On Feb 25, 2021, at 8:06 AM, Ben Schwartz
wrote:
>
>> On Thu, Feb 25, 2021 at 10:26 AM Paul Hoffman wrote:
>> In reading draft-schwartz-dnsop-dnssec-strict-mode, I still don't understand
>> why it is even useful. If I am signing one of my zones with two algorithms,
>> I must intend to do so.
> On 26 Feb 2021, at 04:39, Paul Wouters wrote:
>
> On Feb 25, 2021, at 11:06, Ben Schwartz
> wrote:
>>
>>
>>
>> That's not especially the intent. Currently, if you sign with two
>> algorithms, and either of those algorithms becomes insecure*, your zone
>> becomes susceptible to forger
> On Feb 23, 2021, at 1:08 PM, Ben Schwartz wrote:
>
> The DNSSEC Strict Mode flag appears in bit $N of the DNSKEY flags field.
> If this flag is set, all records in the zone MUST be signed correctly under
> this key's specified Algorithm. A validator that receives a Strict Mode
> DNSKEY with a
> On Feb 25, 2021, at 5:13 PM, Ben Schwartz wrote:
>
> The most interesting informational element, in my view, would be guidance on
> how to detect buggy implementations that will create this problem. (Set up a
> test zone and a test resolver and ...?). I think the best practice is
> probabl
Ben Schwartz writes:
> I also think that this is not appropriate as a Best Practice. I would suggest
> reversing this draft to make it operational guidance to implementers about
> how to
> enable compliance with RFC 6781 Section 4.1.4.
Thanks for the feedback from both of you.
I think I could
On Thu, 25 Feb 2021, Ben Schwartz wrote:
On Thu, Feb 25, 2021 at 10:26 AM Paul Hoffman wrote:
In reading draft-schwartz-dnsop-dnssec-strict-mode, I still don't
understand why it is even useful. If I am
signing one of my zones with two algorithms, I must intend to do so. What
is th
On Feb 25, 2021, at 11:06, Ben Schwartz
wrote:
>
>
>
> That's not especially the intent. Currently, if you sign with two
> algorithms, and either of those algorithms becomes insecure*, your zone
> becomes susceptible to forgery.
Which is why we have RFC 8624 and it’s successors. It really
In reading draft-schwartz-dnsop-dnssec-strict-mode, I still don't understand
why it is even useful. If I am signing one of my zones with two algorithms, I
must intend to do so. What is the value of me saying that only one of the
signing algorithms is the strong one?
--Paul Hoffman
smime.p7s
De
Hi Ulrich,
On Feb 25, 2021, at 06:53, Ulrich Wisser
wrote:
> But this is a real world problem, one that is holding DNSSEC back.
> If you buy DNS operations the operator will usually tell you what algorithm
> they use, you have no choice in that.
This feels like one of those areas where more s
> On 24 Feb 2021, at 22:44, Mark Andrews wrote:
>
>
>
>> On 25 Feb 2021, at 02:01, Ulrich Wisser
>> wrote:
>>
>>>
>>> On 23 Feb 2021, at 17:49, Ben Schwartz
>>> wrote:
>>>
>>>
>>>
>>> On Tue, Feb 23, 2021 at 11:21 AM Samuel Weiler wrote:
>>> ...
>>> Recognizing that I'm likely biase
12 matches
Mail list logo
