from:"Peter Thomassen"

[DNSOP]Re: Paul Wouters' Yes on draft-ietf-dnsop-dnssec-bootstrapping-10: (with COMMENT)

2024-05-28 Thread Peter Thomassen


Hi Paul,

On 5/27/24 19:39, Paul Wouters via Datatracker wrote:

--
COMMENT:
--

Thanks for addressing all my DICSUSS items and comments. I have updated my 
ballot to Yes,


Thanks!


One last comment left on the new text:

If all else fails, the domain owner might have to request the removal of
 all DS records (e.g., by using the special-value CDS/CDNSKEY RRset
 specified in [RFC8078] Section 4) and have the transfer performed

I think the "e.g." sentence should be removed. This is "in case the dns operator
is not cooperating", so in that case one would assume they wouldn't update these
records either (and the domain owner would need to go through their registrar
website, which would cause the records to be removed at the parent via EPP.


We've made this change and pushed a new revision.

Thanks,
Peter

--
https://desec.io/

___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP]Re: [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)

2024-05-21 Thread Peter Thomassen


[another (last) attempt of reposting this as it did not get delivered to 
dnsop@ietf.org on May 7, as evidenced by the list archive]


Hi,

On 5/2/24 19:59, David Dong via RT wrote:

Following up on this; does the group agree that "_dnssec" is OK?


Looking at what's been said in this thread:
- Two people have proposed to change the label, current proposal: _dnssec
- Two implementers have said they'd make the change but don't seem convinced
- The authors (hats off, but also implementers and authors of current drafts 
using the mechanism) are not convinced

The authors don't feel comfortable declaring consensus in either direction 
(neither do we know whether that's our role), and we're not sure how to 
proceed. Perhaps the DNSOP chairs could weigh in, as the discussion is 
happening on the WG list although the document is technically out of the door 
...


I've been reluctant adding the following argument as to not seem insisting; 
OTOH it may have its own technical merit, so here is.

The "_dnssec" label implies that the mechanism is not suitable for signaling 
unrelated to DNSSEC. That's an artificial limitation, and it's unclear why to impose the 
restriction. An operator could very well want to publish other things, like

- TXT at _abuse.example.com._signal.ns1.provider.net for an abuse address,
- PTR at _catalog.example.com._signal ... for catalog zone membership,
- ...

If the signaling method is generic, I believe it should have a short generic 
label. Any specificity to determine the kind of signal can go into the first 
label.

I have no specific preference for "_signal" other than I don't know what a good 
alternative would be. Narrowing the scope with "_dnssec" doesn't seem to improve the 
situation.

Thanks,
Peter
+ Nils (for the "we"/author statements)



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:


The authors certainly don't insist, but we'd need to pick a suitable
replacement for the "_signal" label.

John proposed "_dnssec-signal" elsewhere in this thread.

The authors would like to note that adding "_dnssec-" eats up 8 more
bytes, increasing chances that bootstrapping will fail due to the
_dsboot.._dnssec-signal. length limitation.
Other than this (unnecessary?) use case narrowing, this choice seems
fine.

That said, does this choice address your concerns?


It would, but I would also be okay if it is just _dnssec.



If the concern is that the label is too generic, “_dnssec” might be
too generic as well. If it is to be more precise, go with _ds-boot or
something more specific to the use case. I don’t have an
implementation in the mix, so it this isn’t a strong opinion.   If the
group agrees _dnssec is fine, then I am fine with it too.

Scott

=
Scott Rose
NIST/CTL/WND
scott.r...@nist.gov
ph: 301-975-8439
GoogleVoice: 571-249-3671
=




--
Like our community service? 
Please consider donating at

https://desec.io/

deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525

___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP]Re: [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)

2024-05-21 Thread Peter Thomassen


Hi,

On 5/2/24 19:59, David Dong via RT wrote:

Following up on this; does the group agree that "_dnssec" is OK?


Looking at what's been said in this thread:
- Two people have proposed to change the label, current proposal: _dnssec
- Two implementers have said they'd make the change but don't seem convinced
- The authors (hats off, but also implementers and authors of current drafts 
using the mechanism) are not convinced

The authors don't feel comfortable declaring consensus in either direction 
(neither do we know whether that's our role), and we're not sure how to 
proceed. Perhaps the DNSOP chairs could weigh in, as the discussion is 
happening on the WG list although the document is technically out of the door 
...


I've been reluctant adding the following argument as to not seem insisting; 
OTOH it may have its own technical merit, so here is.

The "_dnssec" label implies that the mechanism is not suitable for signaling 
unrelated to DNSSEC. That's an artificial limitation, and it's unclear why to impose the 
restriction. An operator could very well want to publish other things, like

- TXT at _abuse.example.com._signal.ns1.provider.net for an abuse address,
- PTR at _catalog.example.com._signal ... for catalog zone membership,
- ...

If the signaling method is generic, I believe it should have a short generic 
label. Any specificity to determine the kind of signal can go into the first 
label.

I have no specific preference for "_signal" other than I don't know what a good 
alternative would be. Narrowing the scope with "_dnssec" doesn't seem to improve the 
situation.

Thanks,
Peter
+ Nils (for the "we"/author statements)



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:


The authors certainly don't insist, but we'd need to pick a suitable
replacement for the "_signal" label.

John proposed "_dnssec-signal" elsewhere in this thread.

The authors would like to note that adding "_dnssec-" eats up 8 more
bytes, increasing chances that bootstrapping will fail due to the
_dsboot.._dnssec-signal. length limitation.
Other than this (unnecessary?) use case narrowing, this choice seems
fine.

That said, does this choice address your concerns?


It would, but I would also be okay if it is just _dnssec.



If the concern is that the label is too generic, “_dnssec” might be
too generic as well. If it is to be more precise, go with _ds-boot or
something more specific to the use case. I don’t have an
implementation in the mix, so it this isn’t a strong opinion.   If the
group agrees _dnssec is fine, then I am fine with it too.

Scott

=
Scott Rose
NIST/CTL/WND
scott.r...@nist.gov
ph: 301-975-8439
GoogleVoice: 571-249-3671
=




--
Like our community service? 
Please consider donating at

https://desec.io/

deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525

___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP]Re: [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)

2024-05-21 Thread Peter Thomassen


[reposting as it did not get delivered to dnsop@ietf.org, as evidenced by the 
list archive]


Hi,

On 5/2/24 19:59, David Dong via RT wrote:

Following up on this; does the group agree that "_dnssec" is OK?


Looking at what's been said in this thread:
- Two people have proposed to change the label, current proposal: _dnssec
- Two implementers have said they'd make the change but don't seem convinced
- The authors (hats off, but also implementers and authors of current drafts 
using the mechanism) are not convinced

The authors don't feel comfortable declaring consensus in either direction 
(neither do we know whether that's our role), and we're not sure how to 
proceed. Perhaps the DNSOP chairs could weigh in, as the discussion is 
happening on the WG list although the document is technically out of the door 
...


I've been reluctant adding the following argument as to not seem insisting; 
OTOH it may have its own technical merit, so here is.

The "_dnssec" label implies that the mechanism is not suitable for signaling 
unrelated to DNSSEC. That's an artificial limitation, and it's unclear why to impose the 
restriction. An operator could very well want to publish other things, like

- TXT at _abuse.example.com._signal.ns1.provider.net for an abuse address,
- PTR at _catalog.example.com._signal ... for catalog zone membership,
- ...

If the signaling method is generic, I believe it should have a short generic 
label. Any specificity to determine the kind of signal can go into the first 
label.

I have no specific preference for "_signal" other than I don't know what a good 
alternative would be. Narrowing the scope with "_dnssec" doesn't seem to improve the 
situation.

Thanks,
Peter
+ Nils (for the "we"/author statements)



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:


The authors certainly don't insist, but we'd need to pick a suitable
replacement for the "_signal" label.

John proposed "_dnssec-signal" elsewhere in this thread.

The authors would like to note that adding "_dnssec-" eats up 8 more
bytes, increasing chances that bootstrapping will fail due to the
_dsboot.._dnssec-signal. length limitation.
Other than this (unnecessary?) use case narrowing, this choice seems
fine.

That said, does this choice address your concerns?


It would, but I would also be okay if it is just _dnssec.



If the concern is that the label is too generic, “_dnssec” might be
too generic as well. If it is to be more precise, go with _ds-boot or
something more specific to the use case. I don’t have an
implementation in the mix, so it this isn’t a strong opinion.   If the
group agrees _dnssec is fine, then I am fine with it too.

Scott

=
Scott Rose
NIST/CTL/WND
scott.r...@nist.gov
ph: 301-975-8439
GoogleVoice: 571-249-3671
=




--
Like our community service? 
Please consider donating at

https://desec.io/

deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525

___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP]Re: Paul Wouters' Discuss on draft-ietf-dnsop-dnssec-bootstrapping-08: (with DISCUSS and COMMENT)

2024-05-20 Thread Peter Thomassen


Hi Paul,

We addressed the last open issue (see below) and submitted a new revision (-10).

Thanks for the helpful discussion, I feel it's made the draft better!

On 5/18/24 03:23, Peter Thomassen wrote:

OLD
   CDS/CDNSKEY records and corresponding signaling records MUST NOT be
   published without the zone owner's consent.  Likewise, the child DNS
   operator MUST enable the zone owner to signal the desire to turn off
   DNSSEC by publication of the special-value CDS/CDNSKEY RRset
   specified in [RFC8078] Section 4.  To facilitate transitions between
   DNS operators, child DNS operators SHOULD support the multi-signer
   protocols described in [RFC8901].

NEW
   It is possible to add CDS/CDNSKEY records and corresponding signaling
   records to a zone without explicit knowledge of the domain owner.  To
   spare domain owners from being caught off guard by state changes
   induced by this practice, Child DNS operators doing so are advised to
   make this transparent.


Maybe add:   ", for example by notifying the domain owner via email".


Mmh, I find this quite prescriptive ("a priming example"). It could also be 
done as an info box when you create the zone (perhaps you can untick a box to disable), 
or as an advertised feature when you book the plan. Those approaches seem favorable, 
because they are ahead of time (before it actually happens), while a notification is 
after the fact.

Now, I'm not sure whether we should go into elaborating on all of this; but *if* we say 
something, I feel we should mention one of the "ahead-of-time" ways. I'd be 
curious to know what you think of this.


NEW
   It is possible to add CDS/CDNSKEY records and corresponding signaling
   records to a zone without the domain owner's explicit knowledge.  To
   spare domain owners from being caught off guard by the ensuing DS
   changes, child DNS operators following this practice are advised to
   make that transparent, such as by informing the domain owner during
   zone creation (e.g., in a GUI), or by notifying them via email.

Thanks,
Peter

--
https://desec.io/

___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP]Re: Paul Wouters' Discuss on draft-ietf-dnsop-dnssec-bootstrapping-08: (with DISCUSS and COMMENT)

2024-05-17 Thread Peter Thomassen

Hi Paul,

On 5/17/24 20:45, Paul Wouters wrote:

# Section 2

OLD
The DS enrollment methods described in Section 3 of [RFC8078] are
deprecated and SHOULD NOT be used. Child DNS operators and parental
agents who wish to use CDS/CDNSKEY records for initial DS enrollment
SHOULD instead support the authentication protocol described in
Section 4 of this document.

NEW
The DS enrollment methods described in Section 3 of [RFC8078] are
less secure than the method described in Section 4 of this document.
It is therefore RECOMMENDED that Child DNS operators and parental
agents who wish to use CDS/CDNSKEY records for initial DS enrollment
instead support the authentication protocol described here.

I would remove the word "instead", as it now doesnt deprecate it.
Otherwise okay.

OK. This leads to the confusing constellation "for initial DS enrollment support", where
"support" looks like a noun but is a verb. I thus restructured the last sentence
equivalently as follows:

NEW
The DS enrollment methods described in Section 3 of [RFC8078] are
less secure than the method described in Section 4 of this document.
Child DNS operators and parental agents wishing to use CDS/CDNSKEY
records for initial DS enrollment SHOULD therefore support the
authentication protocol described here.

That adds significant complexity, to defend against a scenario that is simply "part of
life" in the DNSSEC security model ("there is no way to defend against the parent").

We will leave it to dnssec transparency logging to find "deep signs"

;-)

Thus: Would it address your concern if we said that QNAME minimization is
REQUIRED or RECOMMENDED for resolving signaling records? (Which of the two?)

Let's leave it out for now. Or if you want you can add it as
RECOMMENDED, but I think then you'd also need to talk a bunch about
starting from an empty cache and stuff, so I would leave it out
completely.

Section 5.2 (parent-side operational considerations) already says that it is
"RECOMMENDED toperform queries into signaling domains with an (initially)
coldresolver cache", so it actually fits well.

I used the opportunity to replace "cold" with "empty" (avoiding jargon), and
added right after:

NEW
It is also RECOMMENDED to use QNAME minimization [RFC9156] when
resolving queries for signaling records, to guard against certain
attacks (see Section 6).

In Section 6 (security considerations), I then added:

NEW
If QNAME minimization [RFC9156] is not used when querying for
signaling records, an upstream parent of a signaling domain will see
those CDS/CDNSKEY queries and could respond with an authoritative
answer signed with its own key, instead of sending the referral.
Enabling QNAME minimization reduces the attack surface for such
forgery.

What do you think?

OLD
CDS/CDNSKEY records and corresponding signaling records MUST NOT be
published without the zone owner's consent. Likewise, the child DNS
operator MUST enable the zone owner to signal the desire to turn off
DNSSEC by publication of the special-value CDS/CDNSKEY RRset
specified in [RFC8078] Section 4. To facilitate transitions between
DNS operators, child DNS operators SHOULD support the multi-signer
protocols described in [RFC8901].

NEW
It is possible to add CDS/CDNSKEY records and corresponding signaling
records to a zone without explicit knowledge of the domain owner. To
spare domain owners from being caught off guard by state changes
induced by this practice, Child DNS operators doing so are advised to
make this transparent.

Maybe add: ", for example by notifying the domain owner via email".

Mmh, I find this quite prescriptive ("a priming example"). It could also be
done as an info box when you create the zone (perhaps you can untick a box to disable),
or as an advertised feature when you book the plan. Those approaches seem favorable,
because they are ahead of time (before it actually happens), while a notification is
after the fact.

Now, I'm not sure whether we should go into elaborating on all of this; but *if* we say
something, I feel we should mention one of the "ahead-of-time" ways. I'd be
curious to know what you think of this.

When transferring a zone to another DNS operator, the old and new
child DNS operators need to cooperate to achieve a smooth transition,
e.g., by using the multi-signer protocols described in [RFC8901]. If
all else fails, the domain owner might have to request the removal of
all DS records (e.g., by using the special-value CDS/CDNSKEY RRset
specified in [RFC8078] Section 4) and have the transfer performed
insecurely (see [I-D.hardaker-dnsop-intentionally-temporary-insec].)

If the current DNS hoster does not cooperate, It would not let you use
CDS/CDNSKEY,
so I wouldn't mention 8078.

There's an assumption here that I don't share. It's rooted in the fact that it's very unclear what
"not

[DNSOP]Re: Murray Kucherawy's No Objection on draft-ietf-dnsop-dnssec-bootstrapping-09: (with COMMENT)

2024-05-17 Thread Peter Thomassen


Hi Murray,

On 5/16/24 12:59, Peter Thomassen wrote:

I support Paul's DISCUSS especially with respect to Section 2.  It's peculiar
to say a past process is obsolete and you SHOULD NOT use it, because then
continuing to use it is technically still supported by this document.  Don't we
want to say that new implementations MUST NOT do the old thing and MUST do the
new thing?  Using SHOULD effectively leaves two systems "live" rather than one.


I'd like to observe that while both you and Paul have reservations about what 
Section 2 says regarding RFC 8078, there are opposite conclusions:[...]


Just for the record, this has been resolved, and new text has been suggested 
that removes the deprecation, but recommends the new method over the old. It is 
found in the first part of 
https://mailarchive.ietf.org/arch/msg/dnsop/KX2mbN1UzkqngnMxDLShSa-ICZ8/.

The authors assume that the below is considered resolved (unless we hear back).

Thanks,
Peter



This may be some ignorance talking, but: In Section 4.2, if it's found that the
child is already securely delegated, should this be an error, or just treat the
whole thing like a no-op?  Redundant verification returning an error seems an
odd choice, but I'm probably missing some context.


If you set out to perform bootstrapping, than using the algorithm on a 
bootstrapped zone is an error. The text says that if there is an error, one 
MUST abort.

Whether something else needs to be done depends on circumstances, and (I 
believe) belongs into an operational BCP (as suggested in Benson's Intdir 
review, and indeed such a document is planned).

That said, there's no problem rewording the text, and not calling this an 
"error", but a no-op situation. If you feel that the text should be changed, 
please let me know and we'll do it.


I think the SHOULD in Section 4.3 should really be more like "Parental agents
normally trigger ...".  I'm not clear on why this is a normative SHOULD.  What
if I don't do it in those circumstances, but possibly in others?  I'm still
compliant with a SHOULD then, right?  Why might I do it in other situations?
The text doesn't say.


The SHOULD means that delays are to be avoided once the trigger conditions are met (which 
"normally trigger" does not imply).

Does this satisfy the concern? If the concern is still there, we'll change the 
wording.

Best,
Peter



--
https://desec.io/

___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP]Re: Paul Wouters' Discuss on draft-ietf-dnsop-dnssec-bootstrapping-08: (with DISCUSS and COMMENT)

2024-05-17 Thread Peter Thomassen


Hi Joe,

On 5/17/24 10:39, jab...@strandkip.nl wrote:

The Terminology section says:
Signaling domain: A hostname from the child's NS RRset, prefixed
with the label _signal.


Defining a hostname with an alias containing the word "domain" does not
prevent the confusion though (as in my case of reading the document)


An alternative definition might be "a domain name constructed by prepending the label 
"_signal" to a hostname taken from the child's NS RRSet".


That's a good improvement, thanks! We'll include it in the next revision.

Peter

--
https://desec.io/

___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP]Re: Paul Wouters' Discuss on draft-ietf-dnsop-dnssec-bootstrapping-08: (with DISCUSS and COMMENT)

2024-05-17 Thread Peter Thomassen

Hi Paul,

Thanks once more. Suggested changes and other comments below. Text edits can be
previewed in this PR:
https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/pull/16/commits

On 5/17/24 04:15, Paul Wouters wrote:

Section 2:

The DS enrollment methods described in Section 3 of [RFC8078]
are deprecated and SHOULD NOT be used.

This was discussed on the IESG telechat today, and I think we had
consensus around some text that RECOMMENDS this documenter over
the existing methods, but does not obsolete/deprecate them because
those methods might be the only ones available for now. At a future
point this decision could be updated to obsolete the older methods.

Proposed text:

# Abstract

OLD
This document deprecates the DS enrollment methods described in
Section 3 of RFC 8078 in favor of Section 4 of this document, and
also updates RFC 7344.

NEW
This document establishes the DS enrollment method described in
Section 4 of this document as the preferred method over those from
Section 3 of RFC 8078. It also updates RFC 7344.

# Section 2

Does that work?

If the authors/WG insists on the "deprecated" language, it should also
Obsolete: 8078. But be aware that the document currently does make
references
to it, which it cannot do if it obsoletes the document.

The authors don't insist on anything, and I find this language slightly
irritating.

(In my understanding of the word, it implies the absence of a rationale and/or
an unwillingness to engage in a discussion. I assume that was not the intention
...)

Note that this seems to be just a miscommunication.

[...]

In this
context, the word "insists" just meant to convey "sticks to their current
views" and did not convey anything about intensions of parties involved.

Indeed, it must have been my misinterpretation. (For context, in my native tongue,
"insistieren" implies some degree of stubbornness, and throwing it in someone's
face has a somewhat judgmental undertone.)

Apologies! Thank you for clarifying.

Section 4.1.1:

It is not clear to me if the "signaling domain" really has to be
its own zone or not. eg:

_dsboot.example.co.uk._signal.ns1.example.net

Could this be signed using the DNSKEY of "example.net", or does the
document insist on a zone cut at _signal.ns1.example.net ?

The document does not insist that there be a zone cut.

So in that case, I think it would be more clear to rename "Signaling
domain" to "Signaling name".

The authors agree with Joe's observations (in a "sibling post" to this message), and
believe that "domain" is accurate.

Further, the draft uses "signaling name" for the things that are prefixed to the signaling domain,
such as _dsboot.example.com, so one would have to find a new term for that as well. (Note that
"signaling prefix" would not be good choice either because it is easily confused with _dsboot, the
"signaling type".)

We agree that it is somewhat suboptimal terminology, and there indeed has been
an earlier attempt to find better terminology. Unfortunately, that didn't lead
anywhere. For things attempted, see
https://mailarchive.ietf.org/arch/msg/dnsop/_hQhxmTMJ7qwsj2N6P9uqSRKADY/.

However, the definition of "Signaling Domain" could be made more clear. We've
included the suggestion from Joe's message.

in Step 3: any failure to retrieve the CDS/CDNSKEY RRsets
located at the signaling name under any signaling domain,
including failure of DNSSEC validation, or unauthenticated data
(AD bit not set);

I think it also needs to exclude signaling signatures made by any DNSSEC
keys upstream from the DNS hoster's zone. Eg if we have
_signal.ns1.example.net
we also do not want to see the CDS/CDNSKEY RRsets signed by .net or the
root.

I'm not sure. It's conceivable for a TLD operator to run DNS service for some
of its child zones, and if I recall correctly, some of the smaller ccTLDs do.
In this case, address records of nameservers operated under a child may be part
of the TLD zone (along with the corresponding signaling names), so the
signaling records' signer name is indeed the TLD.

But then it is not a domain that can request DS records anyway

That's a misconception; the zone that's authoritative for some the *nameserver
name*

[DNSOP]Re: Éric Vyncke's No Objection on draft-ietf-dnsop-dnssec-bootstrapping-09: (with COMMENT)

2024-05-17 Thread Peter Thomassen

Hi Éric,

Thank you for your comments. Associated changes will be included in revision
-10, and can be previewed at
https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/pull/16/commits/e7bece2158440c5ed5b221fd8a312ac8f171.

On 5/16/24 15:52, Éric Vyncke via Datatracker wrote:

# COMMENTS (non-blocking)

I am sympathetic to Paul Wouter's comments about 'bailiwick' and the use of
"_signal". The latter is probably to late to be changed.

This has been "arbitrated" by Warren, see
https://mailarchive.ietf.org/arch/msg/dnsop/ju-pAWR-QD6BvqDU7qMjIsgBdPA/.

## Section 2

Two normative "SHOULD" but no reason/suggestion on when the SHOULD can be
bypassed.

This paragraph will be reworked as a result of yesterday's telechat.

## Section 4.1.1

"example.co.uk" is not a IANA/IETF reserved domain name. Suggest to use an
actual reserved domain name.

The example is trying to illustrate that bootstrapping is not limited to
2nd-level domains, but also applies elsewhere in the tree.

We could use subdomain.example.com, but that's confusing because "example.com" is not
commonly considered a registry (unlike "co.uk").

Other options would be "child.under.example" and things like that. The example
would then have to names like _dsboot.child.under.example._signal.ns1.example.net,
parsing of which requires more thinking and is thus less instructive.

The authors therefore prefer to keep this example as is, assuming that there's
no requirement to use a reserved name. (If there is, apologies for the
ignorance, and we'll fix it!)

Suggest to also add the RR type in the example.

added "as CDS/CDNSKEY RRsets"

Perhaps explain `Publication of signaling records under the in-bailiwick domain
_signal.ns3.example.co.uk is not required`.

It's explained in the beginning of the section. As others felt the draft is "more
verbose and repetitive than it needs to be", we'd rather not add to that :-)

## Section 7

Like Erik Kline, I wonder whether the IANA considerations should include a
request for _dsboot. The use of _dsboot is only briefly mentioned in section
1.1, which is rather weak for a proposed standard document (I was close to open
a DISCUSS on this topic).

The authors are not sure under which conditions such registries should or
should not be erected, and thus can't contribute to this discussion. Any
guidance / opinions from others would be appreciated.

(FWIW, it is the authors' impression that adding such a registry seems to add
about 2 pages of text, while its added value may be limited at this time. That
may change once other prefixes get specified, and one might want to consider
erecting a registry at such a later time. Other considerations can be found at
https://mailarchive.ietf.org/arch/msg/dnsop/PSmBgLTZDB-j8fA_9n4B4WWdLDc/.)

Best,
Peter

--
https://desec.io/

___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP]Re: Paul Wouters' Discuss on draft-ietf-dnsop-dnssec-bootstrapping-08: (with DISCUSS and COMMENT)

2024-05-16 Thread Peter Thomassen

Hi Paul, Warren,

Following up on the telechat:

On 5/15/24 20:34, Peter Thomassen wrote:

Section 2:

The DS enrollment methods described in Section 3 of [RFC8078]
are deprecated and SHOULD NOT be used.

I find this to be inconsistent with the Update: 8078 clause, as without
"Section 3", you are basically obsoleting the entire 8078. I don't think
this document should obsolete it, it should augment it. I would rewrite
the above like:

The DS enrollment method described in this document provides more
security than the methods described in Section 3 of [RFC8078],
and are therefor RECOMMENDED in favour of the methods specified
in [RFC8078].

If the authors/WG insists on the "deprecated" language, it should also
Obsolete: 8078. But be aware that the document currently does make references
to it, which it cannot do if it obsoletes the document.

I now understood better what this was about.

My understanding of the WG discussion [4] is that the intention of the current text ("the old
method is NOT RECOMMENDED") is quite similar to that of Paul's proposal ("the new method
is RECOMMENDED").

The word "deprecated" adds the aspect of "phasing out" (i.e., "with a negative slope"),
whereas "obsoleted" is stronger and means that it has already been phased out. (This is my limited non-native
interpretation of English.)

The telechat consensus appears to have been to adopt something like your
wording, without implying a phase-out (deprecation). If I captured this
correctly, we'll incorporate something along those lines.

[4]: https://mailarchive.ietf.org/arch/msg/dnsop/Ld0lgCwJJQvgKIA9eBv8yEtgeoI/

Section 5:

CDS/CDNSKEY records and corresponding signaling records MUST
NOT be published without the zone owner's consent.

This opens a can of worms. How is an implementer going to codify this
MUST? The only usable interpretation I can see is that the DNS hoster,
by being assigned the DNS hoster, has permissions to DNS host the zone
as it sees fit, and thus do DNSSEC. And especially not bother the zone
owner with techno-babble for permissions.

Likewise, the child DNS operator MUST enable the zone owner

Again, this wades into legalize and contractual matters best left
outside of RFC specifications.

These were added based on Warren's concerns that a DNS operator may lock in a
customer by enabling DNSSEC without consent, thus making it harder to move away
from that provider.

The authors believe either way is fine, and would like to hear the IESG's
decision on how to address this (or not).

If I recall correctly, the sentiment was to change the wording around this to
be less MUST-y, but still make the point. We'll try to come up with something
suitable and circulate it here.

Peter

--
https://desec.io/

___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP]Re: Murray Kucherawy's No Objection on draft-ietf-dnsop-dnssec-bootstrapping-09: (with COMMENT)

2024-05-16 Thread Peter Thomassen


Hi Murray,

Thank you for your comments, thoughts below.

On 5/16/24 06:53, Murray Kucherawy via Datatracker wrote:

--
COMMENT:
--

I support Paul's DISCUSS especially with respect to Section 2.  It's peculiar
to say a past process is obsolete and you SHOULD NOT use it, because then
continuing to use it is technically still supported by this document.  Don't we
want to say that new implementations MUST NOT do the old thing and MUST do the
new thing?  Using SHOULD effectively leaves two systems "live" rather than one.


I'd like to observe that while both you and Paul have reservations about what 
Section 2 says regarding RFC 8078, there are opposite conclusions:

- Paul suggested to remove the deprecation of RFC 8078 Section 3, and rewrite Section 2 
of this draft to say that the new method "provides more security [...], and are 
therefor RECOMMENDED in favour of the methods specified in [RFC8078]."

- You suggested that the the right thing to say is that "new implementations MUST 
NOT do the old thing".

So, the two of you have opposing views regarding whether to live systems are 
acceptable.

As a middle ground, the WG had arrived at the current text, of deprecating the 
old methods [1]. This also has the advantage (over your proposal) that it 
encourages old implementations to move on, while your suggestion does not 
include this incentive.

The authors don't have any specific positions, and will be happy to adjust text 
as needed / determined by the IESG.

[1]: https://mailarchive.ietf.org/arch/msg/dnsop/Ld0lgCwJJQvgKIA9eBv8yEtgeoI/


This may be some ignorance talking, but: In Section 4.2, if it's found that the
child is already securely delegated, should this be an error, or just treat the
whole thing like a no-op?  Redundant verification returning an error seems an
odd choice, but I'm probably missing some context.


If you set out to perform bootstrapping, than using the algorithm on a 
bootstrapped zone is an error. The text says that if there is an error, one 
MUST abort.

Whether something else needs to be done depends on circumstances, and (I 
believe) belongs into an operational BCP (as suggested in Benson's Intdir 
review, and indeed such a document is planned).

That said, there's no problem rewording the text, and not calling this an 
"error", but a no-op situation. If you feel that the text should be changed, 
please let me know and we'll do it.


I think the SHOULD in Section 4.3 should really be more like "Parental agents
normally trigger ...".  I'm not clear on why this is a normative SHOULD.  What
if I don't do it in those circumstances, but possibly in others?  I'm still
compliant with a SHOULD then, right?  Why might I do it in other situations?
The text doesn't say.


The SHOULD means that delays are to be avoided once the trigger conditions are met (which 
"normally trigger" does not imply).

Does this satisfy the concern? If the concern is still there, we'll change the 
wording.

Best,
Peter

--
https://desec.io/

___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP]Re: [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)

2024-05-15 Thread Peter Thomassen


Hi David,

The DNSOP chairs have told me that the document is no longer a WG document as 
it's with the IESG, so a consensus call here is not applicable.

Given the discussion here, we'll leave it to the IESG to decide. If I hear any 
news, I'll post them here.

Thanks,
Peter


On 5/15/24 00:03, David Dong via RT wrote:

Hi all,

Following up on this. Please let us know how we should proceed for this. Thank 
you.

Best regards,

David Dong
IANA Services Sr. Specialist

On Thu May 09 09:39:29 2024, pe...@desec.io wrote:

[another (last) attempt of reposting this as it did not get delivered
to dnsop@ietf.org on May 7, as evidenced by the list archive]


Hi,

On 5/2/24 19:59, David Dong via RT wrote:

Following up on this; does the group agree that "_dnssec" is OK?


Looking at what's been said in this thread:
- Two people have proposed to change the label, current proposal:
_dnssec
- Two implementers have said they'd make the change but don't seem
convinced
- The authors (hats off, but also implementers and authors of current
drafts using the mechanism) are not convinced

The authors don't feel comfortable declaring consensus in either
direction (neither do we know whether that's our role), and we're not
sure how to proceed. Perhaps the DNSOP chairs could weigh in, as the
discussion is happening on the WG list although the document is
technically out of the door ...


I've been reluctant adding the following argument as to not seem
insisting; OTOH it may have its own technical merit, so here is.

The "_dnssec" label implies that the mechanism is not suitable for
signaling unrelated to DNSSEC. That's an artificial limitation, and
it's unclear why to impose the restriction. An operator could very
well want to publish other things, like

- TXT at _abuse.example.com._signal.ns1.provider.net for an abuse
address,
- PTR at _catalog.example.com._signal ... for catalog zone membership,
- ...

If the signaling method is generic, I believe it should have a short
generic label. Any specificity to determine the kind of signal can go
into the first label.

I have no specific preference for "_signal" other than I don't know
what a good alternative would be. Narrowing the scope with "_dnssec"
doesn't seem to improve the situation.

Thanks,
Peter
+ Nils (for the "we"/author statements)



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:


The authors certainly don't insist, but we'd need to pick a
suitable
replacement for the "_signal" label.

John proposed "_dnssec-signal" elsewhere in this thread.

The authors would like to note that adding "_dnssec-" eats up 8
more
bytes, increasing chances that bootstrapping will fail due to the
_dsboot.._dnssec-signal. length limitation.
Other than this (unnecessary?) use case narrowing, this choice
seems
fine.

That said, does this choice address your concerns?


It would, but I would also be okay if it is just _dnssec.



If the concern is that the label is too generic, “_dnssec” might be
too generic as well. If it is to be more precise, go with _ds-boot
or
something more specific to the use case. I don’t have an
implementation in the mix, so it this isn’t a strong opinion.   If
the
group agrees _dnssec is fine, then I am fine with it too.

Scott

=
Scott Rose
NIST/CTL/WND
scott.r...@nist.gov
ph: 301-975-8439
GoogleVoice: 571-249-3671
=




___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org


--
Like our community service? 
Please consider donating at

https://desec.io/

deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525

___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP]Re: Paul Wouters' Discuss on draft-ietf-dnsop-dnssec-bootstrapping-08: (with DISCUSS and COMMENT)

2024-05-15 Thread Peter Thomassen

Hi Paul,

Thank you for a thorough review! We've addressed most of your comments and
submitted a new revision (-09) so that the IESG can look at an updated document
during the telechat tomorrow.

Some responses below.

On 5/14/24 19:23, Paul Wouters via Datatracker wrote:

--
DISCUSS:
--

I have a few items to discuss and some comments. I'm leaving out the discussion
of _signal as a name, as this discussion is taking place on dnsop. While I have
a preference, I'll abide by the consensus call of the dnsop wgchairs.

I requested the chairs to do a consensus call on the matter two weeks ago. The response
was that the document is no longer a WG document, so the chairs "have no role in
this".

For the IESG record: The authors don't feel comfortable overriding WGLC
consensus and changing the protocol, given the absence of unanimous consensus
in the WG and skepticism voiced by implementers (who are most affected) [1].
Also, some more deployments have popped up [2]; not sure how to make sure
everyone is aware of the change.

The authors agree with your earlier suggestion [3] to leave this up to the
IESG, and have them decide whether it's worth the breaking change.

[1]: https://mailarchive.ietf.org/arch/msg/dnsop/XobU0tgxTlRaGc2LsUJP-pYADNg/
[2]:
https://lists.nic.cz/hyperkitty/list/knot-dns-us...@lists.nic.cz/message/5D2WQ5W53CJS5K7LZOI72RCZPJNVFSXF/
[3]: https://mailarchive.ietf.org/arch/msg/dnsop/bHtfwOZ0ow4RKH1PbpX2LRuXsN8/

All Sections:

This document uses the term "bailiwick" a lot. The DNS Terminology series of
RFCs recommands to avoid this term and use "in-domain" or "not in-domain".

done

Section 1:

Readers are expected to be familiar with DNSSEC, including
[RFC4033], [RFC4034], [RFC4035], [RFC6781], [RFC7344], and
[RFC8078].

It should say:

Readers are expected to be familiar with DNSSEC [BCP237].

done

Section 2:

The DS enrollment methods described in Section 3 of [RFC8078]
are deprecated and SHOULD NOT be used.

If the authors/WG insists on the "deprecated" language, it should also
Obsolete: 8078. But be aware that the document currently does make references
to it, which it cannot do if it obsoletes the document.

The authors don't insist on anything, and I find this language slightly
irritating. (In my understanding of the word, it implies the absence of a
rationale and/or an unwillingness to engage in a discussion. I assume that was
not the intention ...)

Regarding the suggestion: As you noticed correctly, the document *does* make reference to
RFC 8078, which is why it cannot be obsoleted. It's not clear why you then say that it
"should"?

Further reasons why RFC 8078 isn't simply obsoleted:

- RFC 8078 has normative language in Section 4 (Disabling DNSSEC with Null CDS
record), and in Section 5 (Security Considerations). There has been no
proposal/intention to obsolete the content of these sections.

- RFC 8078 elevates RFC 7344 from Informational to Standards Track. Wouldn't that be
"undone" by obsoleting RFC 8078?

- RFC 8078 registers the "Delete DS" algorithm in an IANA registry. This
continues to be needed.

Deprecating the methods of section 3 therefore is very different from
obsoleting RFC 8078.

The language of "deprecate" vs "obsolete" has been discussed on the list. Libor Peltan and John
Levine suggested to "deprecate" the insecure method [4], and Paul Hoffman pointed out that we could
"obsolete" RFC 8078 only if everything is restated [5]. The WG did not express a desire to restate things
like the Null CDS record in the new document. I guess that's because it is unrelated to bootstrapping.

If you have any specific suggestions for how to address your concern, please
let us know. We can also ask the WG to discuss this matter again to find out if
their view has changed or not.

[4]: https://mailarchive.ietf.org/arch/msg/dnsop/Ld0lgCwJJQvgKIA9eBv8yEtgeoI/
[5]: https://mailarchive.ietf.org/arch/msg/dnsop/CDIUGxpYYsWtT3araRwnRXSMV9Y/

Section 4.1.1:

It is not clear to me if the "signaling domain" really has to be
its own zone or not. eg:

_dsboot.example.co.uk._signal.ns1.example.net

Could this be signed using the DNSKEY of "example.net", or does the
document insist on a zone cut at _signal.ns1.example.net ?

The document does not insist that there be a zone cut.

I think zone cut should not

[DNSOP]Re: Genart last call review of draft-ietf-dnsop-dnssec-bootstrapping-08

2024-05-15 Thread Peter Thomassen


Hi Peter,

Thanks for the review! Your feedback has been addressed in the newest revision 
(-09).

Best,
Peter


On 4/27/24 02:03, Peter Yee via Datatracker wrote:

Reviewer: Peter Yee
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-dnsop-dnssec-bootstrapping-08
Reviewer: Peter Yee
Review Date: 2024-04-26
IETF LC End Date: 2024-04-26
IESG Telechat date: Not scheduled for a telechat

Summary: This draft is yet another method for bootstrapping DNSSEC so that a
parent zone obtains the child zone DNS keys in a trusted manner. It deprecates
the bootstrapping scheme from RFC 8078. There are a few nits in the document,
but otherwise it appears fine. [Ready with Nits]

Major issues: None

Minor issues: None

Nits/editorial comments:

General: Add a comma after all occurrences of "i.e." and "e.g.". The current
usage is inconsistent in the draft.

Page 4, 1st full paragraph: change "in-bailick" to "in-bailiwick".

Page 13, section 9: insert "and" before "Paul Hoffman".




--
Like our community service? 
Please consider donating at

https://desec.io/

deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525

___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP]Re: Dnsdir last call review of draft-ietf-dnsop-dnssec-bootstrapping-08

2024-05-15 Thread Peter Thomassen


Hi Scott,

Thanks for the review! Your feedback has been addressed in the newest revision 
(-09).

Best,
Peter


On 4/18/24 16:36, Scott Rose via Datatracker wrote:

Reviewer: Scott Rose
Review result: Ready

I believe the draft is ready, with a minor typo/nit that don't change the 
document:

In Section 5.1 second paragraph has "Signaling Zone" while other instances are 
"signaling zone".



Scott


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--
Like our community service? 
Please consider donating at

https://desec.io/

deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525

___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP]Re: Roman Danyliw's No Objection on draft-ietf-dnsop-dnssec-bootstrapping-08: (with COMMENT)

2024-05-15 Thread Peter Thomassen


Hi Roman,

Thank you for your review.

Incorporated changes will show up in the -09 revision (will be published later 
today) and are part of this PR: 
https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/pull/15

Details below.

On 5/12/24 23:43, Roman Danyliw via Datatracker wrote:

--
COMMENT:
--

Thank you to Peter Yee for the GENART review.

** Section 6.  Editorial.
The level of rigor in Section 4.2 is needed to prevent publication of
a half-baked DS RRset

Is “half-baked DS RRset” a term-of-art?  To improve readability, I recommend
not using an idiomatic expression.


Replaced with "ill-conceived".


** Section 7.  Editorial. Per the reference to
[draft-ietf-dnsop-dnssec-bootstrapping], this should likely be something like
“[This RFC]” and subsequent comment of that string being replaced by the RFC
Editor.


Done.


** idnits reports:
   ** Obsolete normative reference: RFC 8499 (Obsoleted by RFC 9499)


Done.

Best,
Peter

--
https://desec.io/

___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP]Re: Intdir telechat review of draft-ietf-dnsop-dnssec-bootstrapping-08

2024-05-15 Thread Peter Thomassen


Hi Benson,

Thank you for your review.

On 5/12/24 20:43, Benson Muite via Datatracker wrote:

Reviewer: Benson Muite
Review result: Ready with Nits

I am an assigned INT directorate reviewer for
. These comments were written
primarily for the benefit of the Internet Area Directors. Document editors and
shepherd(s) should treat these comments just like they would treat comments
from any other IETF contributors and resolve them along with any other Last
Call comments that have been received. For more details on the INT Directorate,
see https://datatracker.ietf.org/group/intdir/about/ .

Based on my review, if I was on the IESG I would ballot this document as YES.

SUMMARY:
The draft proposes a mechanism to enable automated initial validation of child
subdomain CDS/CDNSKEY records when an out of balliwick name server is available
and when the child zone name is not too long.

SUGGESTIONS FOR IMPROVEMENT:


Incorporated changes will show up in the -09 revision (will be published later 
today) and are part of this PR: 
https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/pull/15


1. May want to minimize number of acronyms in the abstract, for example DS
(Delegation Signer), CDS (Child DS) and CDNSKEY (Child Domain Name System
public key)


Those terms are identifiers for DNS record types, rather than acronyms. As a salient 
example, the TLSA record type "does not stand for anything" (RFC 6698 Section 
1.2).

As such, they are typically not expanded in DNS-related RFCs (see for, for 
example, RFC 8078 whose abstract uses DS and DNSKEY as well without expansion).


2. Too long is not specified though is mentioned in section 4.4 -
could more details be given


We've added a reference to RFC 1035 Section 3.1 which defines these length 
requirements.


and do deprecated out of band methods need to be
used in such cases?


The document deprecates automatic DNSSEC bootstrapping without authentication. 
If it can't be done automatically with authentication, one can set up DS 
records manually (by interacting with the parent operator).

To do it securely, an out of band channel may be needed (e.g., via the 
registrar's web interface). One does not have to use a deprecated (insecure) 
automated method.


Any estimates on how often too long names might occur?

I'm not aware of any numbers. It essentially happens when the _dsboot and 
_signal labels together with the domain name and longest nameserver hostname 
exceed 255 octets.

As both nameserver names and delegated domain names are usually shorter than 
~120 octets, this is expected to happen very rarely in practice. We don't have 
numbers, unfortunately, but I wouldn't be surprised if the only real examples 
are experiments set up to prove the point.


3.
Will there be a follow on informational best practice document based on
operational experiences?

Saying this is not in scope for the spec document, but yes, various people 
(including some ICANN staff) have expressed interest in writing up best 
practices / operational experience on DNSSEC automation, including (but not 
limited to) the topic of bootstrapping.

Thanks,
Peter

--
https://desec.io/

___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP]Re: [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)

2024-05-14 Thread Peter Thomassen


[reposting as it looks like this did not get delivered during Mailman 
transition last week; original message sent on May 7]


Hi,

On 5/2/24 19:59, David Dong via RT wrote:

Following up on this; does the group agree that "_dnssec" is OK?


Looking at what's been said in this thread:
- Two people have proposed to change the label, current proposal: _dnssec
- Two implementers have said they'd make the change but don't seem convinced
- The authors (hats off, but also implementers and authors of current drafts 
using the mechanism) are not convinced

The authors don't feel comfortable declaring consensus in either direction 
(neither do we know whether that's our role), and we're not sure how to 
proceed. Perhaps the DNSOP chairs could weigh in, as the discussion is 
happening on the WG list although the document is technically out of the door 
...


I've been reluctant adding the following argument as to not seem insisting; 
OTOH it may have its own technical merit, so here is.

The "_dnssec" label implies that the mechanism is not suitable for signaling 
unrelated to DNSSEC. That's an artificial limitation, and it's unclear why to impose the 
restriction. An operator could very well want to publish other things, like

- TXT at _abuse.example.com._signal.ns1.provider.net for an abuse address,
- PTR at _catalog.example.com._signal ... for catalog zone membership,
- ...

If the signaling method is generic, I believe it should have a short generic 
label. Any specificity to determine the kind of signal can go into the first 
label.

I have no specific preference for "_signal" other than I don't know what a good 
alternative would be. Narrowing the scope with "_dnssec" doesn't seem to improve the 
situation.

Thanks,
Peter
+ Nils (for the "we"/author statements)



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:


The authors certainly don't insist, but we'd need to pick a suitable
replacement for the "_signal" label.

John proposed "_dnssec-signal" elsewhere in this thread.

The authors would like to note that adding "_dnssec-" eats up 8 more
bytes, increasing chances that bootstrapping will fail due to the
_dsboot.._dnssec-signal. length limitation.
Other than this (unnecessary?) use case narrowing, this choice seems
fine.

That said, does this choice address your concerns?


It would, but I would also be okay if it is just _dnssec.



If the concern is that the label is too generic, “_dnssec” might be
too generic as well. If it is to be more precise, go with _ds-boot or
something more specific to the use case. I don’t have an
implementation in the mix, so it this isn’t a strong opinion.   If the
group agrees _dnssec is fine, then I am fine with it too.

Scott

=
Scott Rose
NIST/CTL/WND
scott.r...@nist.gov
ph: 301-975-8439
GoogleVoice: 571-249-3671
=




--
Like our community service? 
Please consider donating at

https://desec.io/

deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525

___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP]Re: Erik Kline's No Objection on draft-ietf-dnsop-dnssec-bootstrapping-08: (with COMMENT)

2024-05-07 Thread Peter Thomassen


Hi Erik,

Thanks for your review!

On 5/5/24 00:18, Erik Kline via Datatracker wrote:

## Comments

### S7

* Should there be some kind of registration or reservation for the "_dsboot"
   meaning and usage described in this document?

The authors were wondering as well.

We figured that unlike in case of the existing underscore registry, the issue 
seems less pressing:

The _dsboot etc. labels are under the "main" underscore label right in front of the 
nameserver name. As a result, the signaling type label (like _dsboot) is somewhat 
"shielded", in the sense that they are only used under the signaling mechanism, i.e., by 
DNS operators announcing stuff about their managed zones. Given the limited target group for the 
signaling mechanism overall, collisions seem less likely than with underscore labels in general.

The authors are also not sure under which conditions such registries should or 
should not be erected. In short, we don't really have an answer to your 
question, except that less may be more, but it's not clear.

That said, the authors think "why not", and if you wish, we can add a section 
to address this. I imagine this would be something like RFC 8552 Section 4.1 [1]. This 
would add ~2 pages to the draft, unless there's a shorter way to do it.

[1]: https://www.rfc-editor.org/rfc/rfc8552#section-4.1

Thanks,
Peter and Nils

--
https://desec.io/

___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost

2024-05-02 Thread Peter Thomassen


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 able to perform an 
algorithm rollover away from a deprecated algorithm, without going insecure.

So, as long as the standards do not prohibit validation with a certain 
algorithm, it seems like signing with it for transition purposes should be 
admissible.

How about we add a sentence to rfc8624-bis saying that

"MUST NOT" in the context of the "Recommended for DNSSEC signing" column
does not apply while actively preparing orperforming an algorithm 
rollover
away from that algorithm.

This would

  (1) enable this use case;
  (2) give implementers a good reason to not kill the actual implementation, 
but rather turn it off / put warnings there / require an extra setting / ...

Best,
Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost

2024-05-02 Thread Peter Thomassen





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
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 algorithms. Then a software update brings the new
version of ldns my system. Now an unsigned zone gets deployed,


I don't think the draft warrants that assumption. I'd think that the software 
update or signing pipeline or replication mechanism would somehow make the 
admin aware that action needs to be taken.

This is no different from any other kind of potentially significant change, 
such as the change in OpenVPN configuration format between certain updates.

In any case, I don't consider this concern (which I find valid) a matter of 
standardization. It's up to ldns to decide how to handle it, e.g. by releasing 
a new major version to indicate a compatibility risk, etc.

Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost

2024-05-02 Thread Peter Thomassen





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".


So basically we need a BCP: operators of zones MUST NOT sign their zones
with algorithms 5 and 7. If they currently do, they need to move away
from those algorithms as quickly as possible.


I somewhat agree that this could also be done as a BCP. However, a MUST NOT 
there and a MUST NOT elsewhere is still a MUST NOT, and I'd prefer them to be 
in the same place as all the other algorithm recommendations.


To me, that would sound better then trying to break protocols to get people
to move.


I'm not following what breaks based on the wording I suggested, and I'm not 
sure why you keep bringing that up. :-)

Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Questions before adopting must-not-sha1

2024-05-02 Thread Peter Thomassen





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 indirect users of about 140k zones.


Nothing breaks if we agree to only say MUST NOT for signing, while still 
allowing validation.


The impact on validation software may also be very annoying. Validation
software will have to default to not support SHA1 in signing


No, if we continue to allow validation.

It is then the resolver operator's responsibility to decide whether they want 
to cut validation support for those 140k zones or not. (It's been like that 
anyway, see RedHat.)

The document should be about deprecating signing, not validating. Again, doing 
so doesn't break anything.

Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost

2024-05-02 Thread Peter Thomassen





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 know, just about all zones that start signing are not using
SHA1 as part of the signature. There is not really an issue with new
installations. The affected algorithms have been marked as not recommended
for many years so we can assume that in just about any signer they are not
the default. The problem is with existing zones who probably have an
existing relationship with signer software.


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, now you're not compliant 
anymore".

Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost

2024-05-02 Thread Peter Thomassen


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.

My impression is that several people share this view, so I created a PR with 
suggested changes in that direction. Diff: 
https://github.com/hardaker/draft-hardaker-dnsop-must-not-sha1/pull/3/files

(I've created the PR directly as this document has not been adopted.)

Best,
Peter


On 4/30/24 16:04, Paul Wouters wrote:

On Tue, 30 Apr 2024, Philip Homburg wrote:


The advise is split between producing SHA1 signatures and consuming SHA1
signatures, and those timings do not have to be identical.

That said, a number of OSes have already forced the issue by failing
SHA1 as cryptographic operation (RHEL, CentOS, Fedora, maybe more). So
right now, if you run DNSSEC with SHA1 (which includes NSEC3 using
SHA1), your validator might already return it as an insecure zone.

I think a MUST NOT for signing with SHA1 is a no-brainer. The timing for
MAY on validation should be relatively short (eg 0-2 years?)


What worries me about the draft is the security section. I can understand
the desire to get rid of old crypto, but as far as I can tell
this draft will mostly decrease security.


It will also prevent ServFails when the system crypto SHA1 for
authentication and signature purposes is blocked, and the DNS software
sees this as a failure and returns BOGUS. I am not sure how many DNS
implementations are now probing SHA1 and on failure put it in the
"unsupported algorithm" class, to serve it as insecure instead of bogus.

This issue did hit RHEL,CentOS, Fedora.


We can accept as given that it is easy to find collisions for SHA1. However,
a second pre-image attack is way off in the future.


I'm not too concerned about that.


Looking at the signer part, this is not great either. Moving away from SHA1
requires an algorithm roll-over. DNSSEC is already quite fragile and algorithm
rolls are worse. So there is a failure risk that is too big ignore.


Yes, this fragility is why there are still zones using SHA1 at all. But
I think software and DNS services have no matured to the point where it
is save to do. Eg bind, opendnssec, knot.


This draft requires zones that do not have a collision risk to move to a
different algorithm, at a significant risk, but there is no increase in
security. So that part is also a net negative for security.


Staying at SHA1 incurs the above risk of SHA1 leading to Bogus/ServFail.


So it seems that we are asked to adopt a draft that will mostly reduce
security, not increase it.


It prevents zone outages.


There might be other arguments for adopting the draft, such a Redhat not
validating signatures with SHA1 anymore. But those arguments are not
mentioned in the draft.


I guess these considerations can be added to the draft if the WG wants?


And if some companies from one country want to shoot themselves in the foot,
does the rest of the world have to follow?


The IETF and its cryptographic policies are a careful interworking
between market forces, reality and desire. Moving to fast leads to RFCs
being ignored. Moving too slow means RFCs do not encourage
modernization. Every other protocol has left SHA1 behind. It's time for
DNS to follow suit. It's had its "exemption" for a few years already.

Paul

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--
Like our community service? 
Please consider donating at

https://desec.io/

deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Editorial / OCD nit on draft-ietf-dnsop-generalized-notify

2024-04-24 Thread Peter Thomassen


Hi Warren,

On 4/24/24 16:29, Warren Kumari wrote:

While reading draft-ietf-dnsop-generalized-notify - "Generalized DNS Notifications" 
 I noticed (in the 
Abstract):

"This document extends the use of DNS NOTIFY ([RFC1996] beyond conventional zone 
transfer hints, …"

There is an opening parenthesis with no closing one, and this **completely** 
triggered my OCD…


Oh no! We've fixed it. 
(https://github.com/peterthomassen/draft-ietf-dnsop-generalized-notify/commit/3a37b880cd3e97c974363803552b464f93edab64

;-)

Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)

2024-04-20 Thread Peter Thomassen


Hi Paul,

The authors certainly don't insist, but we'd need to pick a suitable replacement for the 
"_signal" label.

John proposed "_dnssec-signal" elsewhere in this thread.

The authors would like to note that adding "_dnssec-" eats up 8 more bytes, increasing 
chances that bootstrapping will fail due to the 
_dsboot.._dnssec-signal. length limitation. Other than this 
(unnecessary?) use case narrowing, this choice seems fine.

That said, does this choice address your concerns?

The main question then is to get implementations updated. I'm thus copying a 
few implementers so they can comment w.r.t. making this change in their 
implementation. I suppose that barring their objections, it's fine to go ahead?

Thanks,
Nils and Peter


On 4/20/24 01:18, Paul Wouters wrote:

If the authors insist, then as DE of this registry, this entry is okay.

My point below still holds, but I will leave that up to the authors and IESG.

Paul

Sent using a virtual keyboard on a phone


On Apr 19, 2024, at 18:47, David Dong via RT 
 wrote:

Hi Paul,

Just a ping on this; thank you.

Best regards,

David Dong
IANA Services Sr. Specialist


On Sat Apr 13 01:24:13 2024, pe...@desec.io wrote:
Hi Paul,


On 4/12/24 22:36, Paul Wouters wrote:
However, I would urge the authors/WG to pick a less generic and more
specific name than "_signal", such as "_dnssec-bootstrap". Especially
because there is also the well known "Signal" message client. Also,
in case of future different signaling, the current name might become
confusing.


The signaling record names actually have two underscore labels, and
look like (taking nohats.ca as an example)

_dsboot.nohats.ca._signal.ns2.foobar.fi.

The specific type of signal is already indicated by the first label.
Other signaling use cases would use a different first label. (draft-
thomassen-dnsop-mske has an example.)

The _signal label generically indicates that ns2.foobar.fi likes to
signal something about nohats.ca. Its presence is needed to allow
separating the object from the source without ambiguity.

We could change _signal to something else, but not to _dnssec-
bootstrap as that's not generic. Suggestions are welcome.


I'd like to add some considerations:

- The spec has quite a few production implementations (see Section 8),
and changing them would come with significant costs.

- I don't think the _signal label is in use for the Signal messenger.
Even in case it's used in the future, a collision (in terms of prefix
labels + rdtype) seems unlikely.

As there would be significant costs, but no tangible benefit, perhaps
we should not do this.


Further context: The structure of the signaling name is the result of
the DNSOP Interim [1]. Details on rejected alternatives can be found
in [2].

[1]: "Open Issue 3" in https://datatracker.ietf.org/meeting/interim-
2022-dnsop-01/materials/slides-interim-2022-dnsop-01-sessa-
authenticated-dnssec-bootstrapping-00.pdf
[2]:
https://mailarchive.ietf.org/arch/msg/dnsop/FE5Sm5vzZtq9VgKxgkfmv4VuVI8/

Thanks,
Peter


___
DNSOP mailin


--
Like our community service? 
Please consider donating at

https://desec.io/

deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)

2024-04-12 Thread Peter Thomassen

Hi Paul,

On 4/12/24 22:36, Paul Wouters wrote:

However, I would urge the authors/WG to pick a less generic and more
specific name than "_signal", such as "_dnssec-bootstrap". Especially
because there is also the well known "Signal" message client. Also,
in case of future different signaling, the current name might become
confusing.

The signaling record names actually have two underscore labels, and look like
(taking nohats.ca as an example)

_dsboot.nohats.ca._signal.ns2.foobar.fi.

The specific type of signal is already indicated by the first label. Other
signaling use cases would use a different first label.
(draft-thomassen-dnsop-mske has an example.)

The _signal label generically indicates that ns2.foobar.fi likes to signal
something about nohats.ca. Its presence is needed to allow separating the
object from the source without ambiguity.

We could change _signal to something else, but not to _dnssec-bootstrap as
that's not generic. Suggestions are welcome.

I'd like to add some considerations:

- The spec has quite a few production implementations (see Section 8), and
changing them would come with significant costs.

- I don't think the _signal label is in use for the Signal messenger. Even in
case it's used in the future, a collision (in terms of prefix labels + rdtype)
seems unlikely.

As there would be significant costs, but no tangible benefit, perhaps we should
not do this.

Further context: The structure of the signaling name is the result of the DNSOP
Interim [1]. Details on rejected alternatives can be found in [2].

[1]: "Open Issue 3" in
https://datatracker.ietf.org/meeting/interim-2022-dnsop-01/materials/slides-interim-2022-dnsop-01-sessa-authenticated-dnssec-bootstrapping-00.pdf
[2]: https://mailarchive.ietf.org/arch/msg/dnsop/FE5Sm5vzZtq9VgKxgkfmv4VuVI8/

Thanks,
Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-bootstrapping-08.txt

2024-04-11 Thread Peter Thomassen


Dear DNSOP,

Here's a quick change log, all are editorial:

- Editorial changes from AD Review
- Updated implementation section
- Change capitalization of terms from terminology section (from WGLC)

Peter


On 4/11/24 14:59, internet-dra...@ietf.org wrote:

Internet-Draft draft-ietf-dnsop-dnssec-bootstrapping-08.txt is now available.
It is a work item of the Domain Name System Operations (DNSOP) WG of the IETF.

Title:   Automatic DNSSEC Bootstrapping using Authenticated Signals from 
the Zone's Operator
Authors: Peter Thomassen
 Nils Wisiol
Name:draft-ietf-dnsop-dnssec-bootstrapping-08.txt
Pages:   17
Dates:   2024-04-11

Abstract:

This document introduces an in-band method for DNS operators to
publish arbitrary information about the zones they are authoritative
for, in an authenticated fashion and on a per-zone basis.  The
mechanism allows managed DNS operators to securely announce DNSSEC
key parameters for zones under their management, including for zones
that are not currently securely delegated.

Whenever DS records are absent for a zone's delegation, this signal
enables the parent's registry or registrar to cryptographically
validate the CDS/CDNSKEY records found at the child's apex.  The
parent can then provision DS records for the delegation without
resorting to out-of-band validation or weaker types of cross-checks
such as "Accept after Delay".

This document deprecates the DS enrollment methods described in
Section 3 of RFC 8078 in favor of Section 4 of this document, and
also updates RFC 7344.

[ Ed note: This document is being collaborated on at
https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/
(https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/).
The authors gratefully accept pull requests. ]

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-dnsop-dnssec-bootstrapping-08.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-dnssec-bootstrapping-08

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--
Like our community service? 
Please consider donating at

https://desec.io/

deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] AD Review of: draft-ietf-dnsop-dnssec-bootstrapping

2024-04-11 Thread Peter Thomassen

Hi Warren,

Thank you for your helpful feedback, pls see below.

On 4/5/24 22:42, Warren Kumari wrote:

Please SHOUT loudly once you've had a chance to address these, and I'll start
IETF LC.

SHOUTING!

We've included your feedback in the -08 revision that I just submitted.

The below essentially is a commented diff.

Comments / questions:

1: Please be consistent in capitalization of Parent, Child, Registry,
Registrar.

Yup, Paul Hoffman also mentioned this, and we changed all to lowercase upon his
suggestion. It's now included in the new revision.

2: "Signaling Domains SHOULD be delegated as zones of their own, so that the Signaling Zone's
apex coincides with the Signaling Domain (such as _signal.ns1.example.net
). While it is permissible for the Signaling Domain to be
contained in a Signaling Zone of fewer labels (such as example.net ), a
zone cut ensures that bootstrapping activities do not require modifications of the zone containing
the nameserver hostname."
Can you please try and reword this? I'm not entirely sure what "Signaling Domains SHOULD be
delegated as zones of their own," actually *means*. I think I sort of do, but I don't think I
could fully articulate it — perhaps "standalone zones"?

Done

3: "To keep the size of the Signaling Zones minimal and bulk processing efficient
(such as via zone transfers), Child DNS Operators SHOULD remove Signaling Records which
are found to have been acted upon."
This feels fairly hand-wavey (especially because it has a "SHOULD") — how would that
child operators know that the signing records have been processed/consumed? (yes, I know, but it
seems like some text it needed). Perhaps just rewording the sentence would help - something like:
"Once a Child DNS Operator determines that specific Signaling Records have been processed (e.g
by seeing the result in the Parent), they are advised to remove the Signaling Record. This will
help keep the Signaling Zone smaller, and bulk processing (such as via zone transfers) more
efficient."? Something like that…

Done, in the following way:

NEW
Once a Child DNS Operator determines that specific Signaling Records
have been processed (e.g., by seeing the result in the parent zone),
they are advised to remove them. This will reduce the size of the
Signaling Zone, and facilitate more efficient bulk processing (such
as via zone transfers).

4: "It is RECOMMENDED to perform queries within Signaling Domains (Section 4.2) with
an (initially) cold resolver cache or to limit the TTL of cached records to the interval
between scans, as to retrieve the most current information regardless of TTL."
This sentence doesn't really work - it says to "limit the TTL of cached records" so you have the
most current information regardless of the TTL. Perhaps just adding "regardless of the original
TTL" (or "actual TTL" or something...)

Done

NEW
In order to ensure timely DNSSEC bootstrapping of insecure domains,
stalemate situations due to mismatch of cached records (Step 4 of
Section 4.2) need to be avoided. It is thus RECOMMENDED to perform
queries into signaling domains with an (initially) cold resolver
cache, or to disable caching for them (e.g., by limiting response
TTLs to the interval between scans).

5: "(When a batch job is used to attempt bootstrapping for a large number of
delegations, the cache does not need to get cleared in between queries pertaining to
different Children.)"
Is this always true? I'm not sure, but it feels like there could be cases where there are
delegations to domain early on in a run, which you later discover later in a run is also being
bootstrapped. E.g you start with example.com and it uses
ns1.example.net . Later on you discover than example.net
is also bootstrapping, but it is already in the cache…. This might be
a really uncommon corner case (and I might be completely wrong about this causing an issue!), but
it seems like unless we are 100% sure we should just drop this sentence (and implementers can
figure out if the optimization is worth potentially stepping on a rake :-P).
I'll happily note that I cannot figure out if my concern is valid, but it
*feels* like there is something scary here…

Good point! Sometimes, less is more. (Done.)

Nits:
1: s/involes/involves/

Done

2: s/For lack of a comprehensive DNS-innate/Due to the lack of a comprehensive
DNS-innate/

Done

3: "The Parent can then use this signal to cryptographically validate the
CDS/CDNSKEY records found at an insecure Child zone's apex, and upon success secure the
delegation."
Suggest: "The Parent can then use this signal to cryptographically validate the
CDS/CDNSKEY records found at an insecure Child zone's apex and, upon success, secure the
delegation." (I generally avoid noting comma-related nits, but this one triggered my
OCD,

Re: [DNSOP] I-D Action: draft-ietf-dnsop-compact-denial-of-existence-03.txt

2024-03-14 Thread Peter Thomassen


Hi Shumon et al.,

On 3/5/24 08:15, internet-dra...@ietf.org wrote:

Internet-Draft draft-ietf-dnsop-compact-denial-of-existence-03.txt is now
available. It is a work item of the Domain Name System Operations (DNSOP) WG
of the IETF.


I added a PR with some suggestions here: 
https://github.com/shuque/id-dnssec-compact-lies/pull/3

The PR just has the suggestions, with no rationale. If anything's contentious 
or the rationale less obvious than I thought: apologies; happy to provide it!

Also, two questions:

Section 2:

An alternative way to distinguish NXDOMAIN from ENT is to define the 
synthetic Resource Record type for ENTs [...] This typically imposes less work 
on the server since NXDOMAIN responses are a lot more common than ENTs.

Not sure in what regard this is "less" work -- an NSEC record has to be signed 
in any case?


Section 4.1

This section describes an optional but recommended scheme

How do "optional" and "recommended" relate to the corresponding uppercase 
keywords (which don't apply at the same time)?


Best,
Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-generalized-notify-01.txt

2024-03-04 Thread Peter Thomassen


Hi,

This revision has the following changes from -00:

- Describe endpoint discovery
- Rename NOTIFY rrtype to DSYNC (to distinguish from NOTIFY message)
- Reserve scheme values 128-255
- Expanded discussion on amplification risks and garbage notifications
- Clean-up, editorial changes

Looking forward to the WG's feedback.

Best,
Johan/John/Peter


On 3/4/24 16:35, internet-dra...@ietf.org wrote:

Internet-Draft draft-ietf-dnsop-generalized-notify-01.txt is now available. It
is a work item of the Domain Name System Operations (DNSOP) WG of the IETF.

Title:   Generalized DNS Notifications
Authors: Johan Stenstam
 Peter Thomassen
 John Levine
Name:draft-ietf-dnsop-generalized-notify-01.txt
Pages:   16
Dates:   2024-03-04

Abstract:

This document extends the use of DNS NOTIFY ([RFC1996] beyond
conventional zone transfer hints, bringing the benefits of ad-hoc
notifications to DNS delegation maintenance in general.  Use cases
include DNSSEC key rollovers hints, and quicker changes to a
delegation's NS record set.

To enable this functionality, a method for discovering the receiver
endpoint for such notification message is introduced, via the new
NOTIFY record type.

TO BE REMOVED: This document is being collaborated on in Github at:
https://github.com/peterthomassen/draft-ietf-dnsop-generalized-notify
(https://github.com/peterthomassen/draft-ietf-dnsop-generalized-
notify).  The most recent working version of the document, open
issues, etc. should all be available there.  The authors (gratefully)
accept pull requests.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-generalized-notify/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-dnsop-generalized-notify-01.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-generalized-notify-01

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--
Like our community service? 
Please consider donating at

https://desec.io/

deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] unrelated name server name recommendation

2024-03-04 Thread Peter Thomassen




On 3/4/24 15:14, Paul Wouters wrote:

It means every registrant, who doesn’t know about DNS, has to create host 
objects for glue and whenever the ISP changes nameserver names (eg gets bought, 
sold or merges), or IP address, the ISP has to talk to the registrant to fix 
things at their registry. I can promise you those in-domain name servers will 
quickly become very unreliable.


For reference, Viktor's analysis from last year, on glue in .org: 
https://mailarchive.ietf.org/arch/msg/dnsop/EBT2_wg8XJkArA1boRX7GNSKdKw/

The analysis is focuses on sibling glue, not only in-domain, but my main 
takeaway is that 75% of them are stale.

Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] About key tags

2024-03-02 Thread Peter Thomassen




On 2/29/24 18:06, Paul Wouters wrote:
 (If no action is taken, malicious activity might follow now that it is described, but I have not heard of a historical case of it.) 


This attack was more or less described five year ago: https://essay.utwente.nl/78777/ 


They didn’t get to the same amplification levels but if attackers had been 
interested, they could have picked it up as a tool to improve. scripts to run 
were attached to the paper.


My take is that with the current mitigations (tolerate a very small but nonzero 
number of keytag collisions), it's unlikely that this will be exploited in any 
significant way, as the attacker's gain is very limited.

As has been pointed out, no such attacks have been observed in the wild, 
although another flavor of it has been known for years.

Let's not assume there's a big problem unless there actually is an indication 
of it. Perhaps we can leave things as they are (with current mitigations), and 
only once we find that's not enough, with attacks happening and causing much 
resource usage, then revisit. There's no need to do this now.


But also, a resolver that sees a higher than normal load could temporarily take 
certain actions like sacrificing zones with key tag collisions. It doesn’t mean 
it ALWAYS has to do it.


Exactly.

Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] About key tags

2024-03-02 Thread Peter Thomassen





On 3/1/24 14:44, Philip Homburg wrote:

Seriously, while I do believe in the need for a coherent DNSKEY
resource record set, there are some multi-signer proposals that do
not.  If the key set has to be coherent, then someone can guard
against two keys being published with the same key tag.  The recovery
may not be easy as you'd have to determine what key needs to be
kicked and who does it and where (physically in HSMs or process-wise).
I have some doubt that key tag collisions can be entirely avoided.


So now we moved the problem away from the core DNSSEC protocols to the
realm of multi signer protocols.


The core DNSSEC protocol includes multi-signer. RFC 8901 just spells out 
explicitly how it is covered by the protocol; that's why its status is 
Informational.


The first step to conclude is that for the core DNSSEC protocol, requiring
unique key tags is doable.


No. There is no core and non-core part of the spec. Support for multiple keys, 
including keytag collisions, simply is part of that protocol.

(And of course, bounding work is part of the protocol just as well.)

Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] About key tags

2024-02-27 Thread Peter Thomassen




On 2/16/24 17:19, Jim Reid wrote:

If a zone's signatures and keys are constructed and published in such a way 
that it causes indigestion in validators, and as a consequence validators fail 
to return responses for data in that zone, that's a self-inflicted problem and 
the zone administrator surely has every incentive to fix the problem. If the 
tools the zone administrator is using make the problem hard to make, then so 
much the better.


If validators can also make this problem hard to make, that’s so much the 
better too. That should give signers a strong incentive to fix their 
self-inflicted problem and stop hurting validating resolvers.

With (some) validators returning SERVFAIL when encountering a keytag collision, 
any operator adding a DNSKEY (e.g., for rollover) will, in roughly 2^-16 of 
cases, break their zone without notice.

It's not clear to me how one would characterize such validator policy as "mak[ing] 
this problem hard to make".

It rather seems like inviting instability, then telling the signer "well, you 
knew...! Or should have, at least."

I don't see in what way that's better than what we have with the current fixes, 
which successfully address the problem and (AFAICS) don't need to be touched 
again.

Best,
Peter

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] About key tags

2024-02-27 Thread Peter Thomassen





On 2/15/24 22:53, Mark Andrews wrote:

But we can state that they should be avoided when generating new DNSKEYs. BIND 
has been avoiding key tag collisions for 2 decades now when generating new 
keys. Multi-signers all have to have the current published DNSKEY RRset which 
includes *all* DNSKEYs as part of their publication process.

Multi-signer peers do not need to publish each other's KSKs. A DNSKEY response 
only needs to contain the KSK suitable for validating the response RRset itself 
(i.e., the responding peer's KSK), and any ZSKs/CSKs that may be needed for 
validation of other responses.

Multi-signers thus aren't necessarily aware of keytag collisions across KSKs.

When using DS provisioning automation via CDS/CDNKSEY, they'll have to exchange 
each other's KSKs for publishing a joint C* RRset (as in 
draft-thomassen-dnsop-mske). The collision could be detected then, but using C* 
automation is not required.

Best,
Peter

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Post-quantum algorithms for DNSSEC

2024-02-08 Thread Peter Thomassen


Hi Petr,

On 2/8/24 11:10, Petr Menšík wrote:

I just found a draft regarding DNSSec solving post-quantum algorithms [1]. From 
a talk about it on csnog.eu site. A very surprising fact for it is seems never 
been mentioned here, where most DNSSec related standards were done recently.


It's a research effort, with little operational ("DNSOP") relevance at this 
time.


It might be just my inexperience, but it seems to me pquip WG had not even made 
any attempt at using expert opinions here. Is my impression wrong?


PQUIP has had no role; it's an individual and not a WG draft.

Prior to announcing the draft, the authors had consulted with Paul Wouters and 
others, and the suggestion was to submit this to the IRTF. During discussion at 
IETF 118 (IRTF open?), this plan solidified.


Even announcement on pqc list [2] does not contain any reference to dnsop, 
dnspriv or other I would expect. Also names responsible for the draft are 
unknown to me, not containing any person I have seen recently in DNSSec related 
RFCs.


It's because they're mainly researchers. You may recognize some of the names in 
the Acknowledgements section. (And there's no relation to DPRIVE.)


Is that a separate activity or cooperation is already in progress and I just 
haven't found it? Are people here aware of it?


I expect that once a mailing list has formed, it will also be announced here, 
so that interested folks can join, and expertise moves both ways. You're of 
course welcome to participate in the effort.

For some extra context, see also the third sentence of the abstract [1] and 
Section 5.1 of OTCO-031 [2].

Best,
Peter

[1]: 
https://datatracker.ietf.org/doc/draft-fregly-research-agenda-for-pqc-dnssec/00/
[2]: https://www.icann.org/en/system/files/files/octo-031-11feb22-en.pdf

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DELEG and parent only resolution

2024-02-01 Thread Peter Thomassen





On 2/1/24 13:55, Havard Eidnes wrote:

Stupid question time:


The target of a DELEG alias cannot be stored in the child
zone. It would not resolve if you do.


Doesn't this mean that we can never get to an environment where
there only exists DELEG records and no NS records, and still have
a working DNS?


DELEG records can contain IP addresses so they can replace NS+glue.


OK, then I don't understand the reasoning behind the claim in the
innermost quote above.  What, then, exactly, prevents you from
using a target of the DELEG record into the child zone, if it can
be made equivalent to NS+glue?

The impossibility is only in DELEG alias mode: When used in SVCB-style alias 
mode, the record doesn't carry any extra key-value pairs, so you can't include 
the IP address hints.

The result would be comparable to a glueless in-bailiwick delegation, leaving 
the resolver clueless as to how to proceed ...

Best,
Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Re: General comment about downgrades vs. setting expectations in protocol definitions

2024-02-01 Thread Peter Thomassen




On 2/1/24 13:34, Edward Lewis wrote:

The proper response will depend on the reason - more accurately the presumed 
(lacking any out-of-band signals) reason - why the record is absent.


Barring any other information, the proper response should IMHO not depend on 
the presumed reason, but assume the worst case. Anything else would break 
expected security guarantees.


From observations of the deployment of DNSSEC, [...]
It’s very important that a secured protocol be able to thwart or limit damage 
due to malicious behavior, but it also needs to tolerate benign operational 
mistakes.  If mistakes are frequent and addressed by dropping the guard, then 
the security system is a wasted in investment.


That latter sentence seems right to me, but it doesn't follow that the protocol needs to 
tolerate "benign operational mistakes".

Another approach would be to accompany protocol deployment with a suitable set 
of automation tools, so that the chance of operational mistakes goes down. That 
would be my main take-away from DNSSEC observations.

In other words, perhaps we should consider a protocol incomplete if the spec 
doesn't easily accommodate automation and deployment without it would yield 
significant operational risk.

Let's try to include automation aspects from the beginning.

Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Documenting DELEG design trade-offs

2024-01-31 Thread Peter Thomassen

On 1/31/24 15:33, Paul Wouters wrote:

A new RRtype has a fairly big cost meassures in years, both in
terms of DNS software, DNS deployment and worse, in Registrar
deployment for Registrant webui elements.

Re-using DS is not nice, but neither was Pseudo OPT, EDNS0, etc.
But it gains us a decade.

As discussed, DELEG needs a signal to tell the resolver "please expect a DELEG
record or a proof-of-nonexistence". Suggestions were to put this into a DNSKEY flag
at the parent, or into a special-algo DS record repurposed as a flags field.

When re-using DS to carry the DELEG-style information itself (as shown on slide 13 of
Paul's deck [1]), that downgrade resilience comes for free; in a way, it's like a
"verbose" version of the special-DS flag.

In the usual DELEG proposal, we need (1) DELEG and (2) an anti-downgrade flag
(in DNSKEY or DS), whereas with this proposal, only one thing (special DS
record) is needed.

Put more provocatively: Why do two things where one suffices?

Yet more provocatively:
- Let's rename DS from "Delegation Signer" to "Delegation Signal".
- It can carry
* legacy DS records (algo/digest type != 0), and/or
* other kinds of signed delegation information (payload determined by other
fields).

Framed this way, it doesn't sound like bending the concept so much anymore. It
simply is the go-to RRset that's used for signaling delegations.

We already know that existing resolvers don't mind the unsolicited DS. Those
who signal support wouldn't need to be served an NS RRset, though.

[1]
https://datatracker.ietf.org/meeting/interim-2024-dnsop-01/materials/slides-interim-2024-dnsop-01-sessa-initial-reflections-on-deleg-00.pdf

In fact, I would argue we should do both. Prepare to keep some RRtypes
into our pocket while we do DS-overload AliasMode now, and see where
that gets us in the next 1-3 years. Then re-evaluate.

I think that's worth considering.

Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-dnsop-deleg-00

2024-01-30 Thread Peter Thomassen




On 1/30/24 16:05, Paul Wouters wrote:

DNSSEC is not mandatory, it is recommended.

One motivation behind DELEG is the ability to use “Aliasmode” to point to an 
SVCB record elsewhere, which contains a DS record. This way, DS records in 
various top level domains can be federated under a single operator. This works 
solely if both the DELEG is signed and “elsewhere” is signed.


I don't understand what you are saying here. Can you elaborate and maybe
include an example?


nohats.ca.  86400  IN NSns2.foobar.fi.
nohats.ca.  86400  IN DELEG 0 _conf.ns2.foobar.fi.
nohats.ca.  86400  IN RRSIG DELEG ...

_conf.ns2.foobar.fi. 3600  IN SVCB  . ( alpn=doq ipv4hint=192.0.2.54
dnskey="257 3 13 BdaQBzPJKqw5U..." )
_conf.ns2.foobar.fi. 3600  IN RRSIG SVCB ...

The _conf.ns2.foobar.fi. ALPN and DNSKEY configuration can be reused by other 
delegations as well, and the operator of ns2.foobar.fi can change it as it sees 
fit without requiring the delegations to be updated.

(Hope this is what you meant.)

The whole DELEG thing can also be done without DNSSEC, but then you can't 
establish the chain of trust like that. (And you don't need DNSSEC when the 
child is insecure, so it's not a problem.)

~Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Followup Working Group Last Call for draft-ietf-dnsop-dnssec-bootstrapping

2024-01-22 Thread Peter Thomassen





On 1/22/24 17:47, Paul Hoffman wrote:

I support the publication of this document. As I told the authors a long time ago, I'm 
still uneasy with all the capitalization ("Client" and so on) because it 
disagrees with our Terminology RFC, and still offer to do a massive pull request to fix 
it, but if they want to keep it, that's up to them.

I don't recall that; apologies for apparently missing that comment.

The capitalization was chosen to blend in when reading together with RFC 7344, 
which uses this style and from which the terminology itself is borrowed as well.

The authors however have no preference at all. I'll mark this as a to-do for 
the next revision.

Are you concerned only about the terms defined in 8499bis (such as "child"), or also the RFC 7344 terms 
("Parental Agent", "Child DNS Operator") and new ones ("Signaling Name/Record/Zone")?

(If you prefer, you can answer this via a PR, but I don't want you to do all 
the work.)

Thanks,
Peter

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-bootstrapping-07.txt

2024-01-19 Thread Peter Thomassen


Dear WP,

This is the update resulting from WGLC comments. Changes:

- Editorial changes to Security Considerations
- Add/discuss bootstrapping triggers via notifications
- (non-WGLC) Add Glauca registrar implementation

Best,
Peter


On 1/19/24 14:56, internet-dra...@ietf.org wrote:

Internet-Draft draft-ietf-dnsop-dnssec-bootstrapping-07.txt is now available.
It is a work item of the Domain Name System Operations (DNSOP) WG of the IETF.

Title:   Automatic DNSSEC Bootstrapping using Authenticated Signals from 
the Zone's Operator
Authors: Peter Thomassen
 Nils Wisiol
Name:draft-ietf-dnsop-dnssec-bootstrapping-07.txt
Pages:   17
Dates:   2024-01-19

Abstract:

This document introduces an in-band method for DNS operators to
publish arbitrary information about the zones they are authoritative
for, in an authenticated fashion and on a per-zone basis.  The
mechanism allows managed DNS operators to securely announce DNSSEC
key parameters for zones under their management, including for zones
that are not currently securely delegated.

Whenever DS records are absent for a zone's delegation, this signal
enables the parent's registry or registrar to cryptographically
validate the CDS/CDNSKEY records found at the child's apex.  The
parent can then provision DS records for the delegation without
resorting to out-of-band validation or weaker types of cross-checks
such as "Accept after Delay".

This document deprecates the DS enrollment methods described in
Section 3 of RFC 8078 in favor of Section 4 of this document, and
also updates RFC 7344.

[ Ed note: This document is being collaborated on at
https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/
(https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/).
The authors gratefully accept pull requests. ]

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-dnsop-dnssec-bootstrapping-07.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-dnssec-bootstrapping-07

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--
Like our community service? 
Please consider donating at

https://desec.io/

deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-bootstrapping

2024-01-19 Thread Peter Thomassen


For the record, Paul and I sorted these out off-list (for real, this time!), 
and I'll push a new revision of the draft shortly.

~Peter

On 11/20/23 16:49, Peter Thomassen wrote:

Hi Paul,  (off-list)

To keep the ball rolling, may I nudge you for your opinion on the below? :)

Thank you very much for your input,
Peter


On 11/13/23 22:30, Peter Thomassen wrote:

Hi Paul,

Thanks for your thoughts. I'd like to address your points below and would very 
much appreciate your follow-up response.

On 11/11/23 12:55, Paul Wouters wrote:

I have read the document and I am supportive of the idea, but I find the
document not ready. Some issues I have with the document in the current form:

- It "deprecates" RFC8078 but does not offer a solution for all cases of
   8078, such as when all nameservers are in-domain of the child.


That is correct. This deprecation was requested to be clarified (but not 
challenged) in the Dnsdir review [1].

During the subsequent considerations on the list, nobody objected, which I read as 
"the WG prefers deprecation".

If the WG feels differently, let's change the text. Perhaps one or two people 
could speak up if they would prefer such a change.

The question at hand is whether, given the cryptographically secure method of 
this document, we want to continue endorsing an insecure method, even if only 
for in-domain nameservers.

I can imagine three kinds of things to say in the draft without continuing to 
endorse insecure bootstrapping:

1.) discourage the insecure method (by deprecating it);
2.) perhaps even discourage in-domain nameservers;
3.) perhaps point out that one might perform DNSSEC bootstrapping with at least 
one out-of-domain nameserver, then switch to in-domain nameservers (e.g., via 
CSYNC).

The draft currently does the first thing, but not the other two.

In-domain nameservers cause a bunch of problems (including the orphaned glue 
saga), and are also foreseen to be incompatible with DELEG-style delegations in 
ServiceMode [2].

Reserving any judgment on the DELEG mechanism itself, it appears to me that 
in-domain nameservers are best advised against. So perhaps what we should do is 
(1) + (2).

[1]: https://mailarchive.ietf.org/arch/msg/dnsop/04LYtemBnRjOBLWzgdD6RuaD5UU/
[2]: https://mailarchive.ietf.org/arch/msg/dnsop/rUY8CJHrrZYa0Sdvi3BV10IsfiE/


- Section 4.3 is named "Triggers" but it basically only describes
   "Timers". Some of us have significant scar tissue on this matter,
   and I don't see new information or a new technology here that
   resolves this old discussion. It feels a lot like restating RFC8078.


The situation in this draft is different from the trigger conditions in in 
Section 6.1 of RFC 7344 (which I think is what you meant). That RFC lists 
conditions for *updating* a DS RRset. This one here is for *initializing*, so 
other scenarios apply.

For example, one condition listed here (but not in RFC 7344) for triggering the 
CDS authentication procedure is when the parent receives a new or updated NS 
record set for a child.

Besides scans (which of course have a timer) and the receipt of a new NS RRset 
(which doesn't), the draft also mentions walking a list of children known to be 
in need of bootstrapping, perhaps received by AXFR or extracted via NSEC walk 
of signaling zones (and the NS receipt). I don't see any relation to timers 
here.


However, this is second instance (after [3]) that someone suggests to remove 
this section, so perhaps it's time to do so. Before doing so, I'd like to point 
out the following:

The main takeaway from Section 4.3 is that the authentication mechanism 
requires reliable knowledge of the delegation's NS records, which -- depending 
on the trigger method -- may or may not be implicit in the trigger condition; 
as a result, a cross-check in the parent's database may be needed for certain 
triggers. This point is not contained in RFC 7344 (which deals with updates 
which use the child's existing chain of trust, so this point doesn't apply).

In particular, scanning the registry database or installing a new NS RRset 
gives *certain* knowledge of what the NS records are, because the trigger 
conditions directly derive from processing an NS RRset that has previously been 
accepted for delegation.

In contrast, when processing some kind of list fetched externally (e.g. walking 
the signaling domain _signal.$NS), it's possible to encounter signaling records 
pertaining to domains that are *not* delegated to $NS; therefore, the parent 
has to check that what's found in the list matches an actual delegation.

I would like to hear your opinion on whether this point warrants the existence 
of Section 4.3; if it doesn't, I'll go ahead and remove it.

[3]: https://mailarchive.ietf.org/arch/msg/dnsop/toP-e7Rc-ZLg0dR2SvzC25kAGxk/


- Style: I think the document is a lot more verbose and repetitive than
   it needs to be. Condensing this would increase clarity of the
   d

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-bootstrapping

2023-11-20 Thread Peter Thomassen


Hi Paul,  (off-list)

To keep the ball rolling, may I nudge you for your opinion on the below? :)

Thank you very much for your input,
Peter


On 11/13/23 22:30, Peter Thomassen wrote:

Hi Paul,

Thanks for your thoughts. I'd like to address your points below and would very 
much appreciate your follow-up response.

On 11/11/23 12:55, Paul Wouters wrote:

I have read the document and I am supportive of the idea, but I find the
document not ready. Some issues I have with the document in the current form:

- It "deprecates" RFC8078 but does not offer a solution for all cases of
   8078, such as when all nameservers are in-domain of the child.


That is correct. This deprecation was requested to be clarified (but not 
challenged) in the Dnsdir review [1].

During the subsequent considerations on the list, nobody objected, which I read as 
"the WG prefers deprecation".

If the WG feels differently, let's change the text. Perhaps one or two people 
could speak up if they would prefer such a change.

The question at hand is whether, given the cryptographically secure method of 
this document, we want to continue endorsing an insecure method, even if only 
for in-domain nameservers.

I can imagine three kinds of things to say in the draft without continuing to 
endorse insecure bootstrapping:

1.) discourage the insecure method (by deprecating it);
2.) perhaps even discourage in-domain nameservers;
3.) perhaps point out that one might perform DNSSEC bootstrapping with at least 
one out-of-domain nameserver, then switch to in-domain nameservers (e.g., via 
CSYNC).

The draft currently does the first thing, but not the other two.

In-domain nameservers cause a bunch of problems (including the orphaned glue 
saga), and are also foreseen to be incompatible with DELEG-style delegations in 
ServiceMode [2].

Reserving any judgment on the DELEG mechanism itself, it appears to me that 
in-domain nameservers are best advised against. So perhaps what we should do is 
(1) + (2).

[1]: https://mailarchive.ietf.org/arch/msg/dnsop/04LYtemBnRjOBLWzgdD6RuaD5UU/
[2]: https://mailarchive.ietf.org/arch/msg/dnsop/rUY8CJHrrZYa0Sdvi3BV10IsfiE/


- Section 4.3 is named "Triggers" but it basically only describes
   "Timers". Some of us have significant scar tissue on this matter,
   and I don't see new information or a new technology here that
   resolves this old discussion. It feels a lot like restating RFC8078.


The situation in this draft is different from the trigger conditions in in 
Section 6.1 of RFC 7344 (which I think is what you meant). That RFC lists 
conditions for *updating* a DS RRset. This one here is for *initializing*, so 
other scenarios apply.

For example, one condition listed here (but not in RFC 7344) for triggering the 
CDS authentication procedure is when the parent receives a new or updated NS 
record set for a child.

Besides scans (which of course have a timer) and the receipt of a new NS RRset 
(which doesn't), the draft also mentions walking a list of children known to be 
in need of bootstrapping, perhaps received by AXFR or extracted via NSEC walk 
of signaling zones (and the NS receipt). I don't see any relation to timers 
here.


However, this is second instance (after [3]) that someone suggests to remove 
this section, so perhaps it's time to do so. Before doing so, I'd like to point 
out the following:

The main takeaway from Section 4.3 is that the authentication mechanism 
requires reliable knowledge of the delegation's NS records, which -- depending 
on the trigger method -- may or may not be implicit in the trigger condition; 
as a result, a cross-check in the parent's database may be needed for certain 
triggers. This point is not contained in RFC 7344 (which deals with updates 
which use the child's existing chain of trust, so this point doesn't apply).

In particular, scanning the registry database or installing a new NS RRset 
gives *certain* knowledge of what the NS records are, because the trigger 
conditions directly derive from processing an NS RRset that has previously been 
accepted for delegation.

In contrast, when processing some kind of list fetched externally (e.g. walking 
the signaling domain _signal.$NS), it's possible to encounter signaling records 
pertaining to domains that are *not* delegated to $NS; therefore, the parent 
has to check that what's found in the list matches an actual delegation.

I would like to hear your opinion on whether this point warrants the existence 
of Section 4.3; if it doesn't, I'll go ahead and remove it.

[3]: https://mailarchive.ietf.org/arch/msg/dnsop/toP-e7Rc-ZLg0dR2SvzC25kAGxk/


- Style: I think the document is a lot more verbose and repetitive than
   it needs to be. Condensing this would increase clarity of the
   document.


It looks like opinions within the WG differ here: the only other two feedbacks on style 
asked for more examples and otherwise described it as "very clear" (both fr

Re: [DNSOP] I-D Action: draft-bellis-dnsext-multi-qtypes-08.txt

2023-11-17 Thread Peter Thomassen




On 11/14/23 12:50, internet-dra...@ietf.org wrote:

Abstract:

This document specifies a method for a DNS client to request
additional DNS record types to be delivered alongside the primary
record type specified in the question section of a DNS query.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-bellis-dnsext-multi-qtypes/


I think this draft proposal a reasonable method for requesting multiple record 
types.

Section 3.2.1 has three occurrences of "SHOULD/MUST attempt to" do things, such 
as:

   MUST attempt to return all specified RR types except where ...

Under which circumstances is the "attempt" sufficient? (Is the attempt allowed to fail 
under circumstances beyond what's in the "except" clause?)

Generally, my feeling is that both "MUST attempt" and "SHOULD attempt" actually are 
"SHOULD".


In Section 3.2.3:

   If the DNS client sets the "DNSSEC OK" (DO) bit in the query
   then the server MUST also return the related DNSSEC records
   that would have been returned in a standalone query for the
   same QTYPE.

That MUST is stronger than the "MUST attempt" for the rdata itself. I guess what's meant 
is something like "MUST return the related DNSSEC records for any returned RRsets, in the same 
way as they would have been returned ...".

Also, "for the same QTYPE" is unclear, it might be misread to refer to the QTYPE 
appearing in the question section. I guess what's meant is "for the respective QTYPE".


Regarding Section 3.1, I tend to agree with Paul's perspective on QTYPE 
encoding via bit map.

Best,
Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-bootstrapping

2023-11-15 Thread Peter Thomassen

Hi all,

Thank you for everyone's responses.

The authors have created a pull request on the draft's repo with the changes
suggested in this thread, which might get amended based on additional feedback.

Changes:
- Add Glauca registrar implementation [based on Q's input]
- Editorial changes to Security Considerations [based on Paul's input]
- Add/discuss on-demand triggers (notifications) [based on John's input]

A text rendering with the changes included is available here:
https://raw.githubusercontent.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/20231115_wglc/draft-ietf-dnsop-dnssec-bootstrapping-07.txt

Please speak up if you have additional feedback.

Thanks,
Nils + Peter

On 11/10/23 13:46, Peter Thomassen wrote:

Dear DNSOP,

(This is mainly for those who did not attend today's DNSOP session in Prague.)

The chairs announced today that the below WGLC meant to say that some reactions
in support of this draft are needed for the document to move forward. (In
contrast to only asking for objections.)

So, if you support this document, please speak up.

Thanks,
Nils + Peter

On 9/19/23 21:48, Tim Wicinski wrote:

This starts a Working Group Last Call for draft-ietf-dnsop-dnssec-bootstrapping

Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/
<https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/>

The Current Intended Status of this document is: Standards Track

This Document will update 7344 and 8078 if approved.

The Document updates brings up something I wanted to raise.
Peter and I chatted about some simple nits (remove references from the
abstract),
but I wasn't sure if the sections updating older documents was formal enough.
DNSOP has produced a few documents recently that update previous work
(8767, 8020 and 9077 come to mind), and we are advice on that.
(I may very well be overthinking this, which is what I told Peter)

Please review the draft and offer relevant comments.
If this does not seem appropriate please speak out.
If someone feels the document is *not* ready for publication, please speak out
with your reasons.

This starts a two week Working Group Last Call process, and ends on: October 3,
2023

thanks
tim

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

--
Like our community service? 
Please consider donating at

https://desec.io/

deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-bootstrapping

2023-11-15 Thread Peter Thomassen


Hi John,

On 11/14/23 20:07, John Levine wrote:

The chairs announced today that the below WGLC meant to say that some reactions 
in support of this draft are needed for the document to move
forward. (In contrast to only asking for objections.)


I think the document is ready EXCEPT that we really need to reconcile
it and the notify draft. If there's going to be notifications, we
should say so now rather than hoping people notice there's some
slightly later RFC that updates this one.


I like this suggestion; indeed, the text doesn't currently mention 
notifications. Suggest to add the following as the first or second bullet in 
Section 4.3:

NEW
   *  The Parental Agent receives a notification from the Child DNS
  Operator indicating that the Child wishes to have its CDS/CDNSKEY
  RRset processed;

... followed by a short discussion of scanning vs. notifications right after 
the bullet list:

NEW
   Timer-based trigger mechanisms (such as scans) exhibit undesirable
   properties with respect to processing delay and scaling; on-demand
   triggers (like notifications) are preferable. Whenever possible,
   Child DNS Operators and Parental Agents are thus encouraged to use
   them, reducing both delays and the amount of scanning traffic.


In the absense of notifications, scanning would be rather expensive
since the registry would need to probe all the signalling domains for
every unsigned registrant. In some cases they might have a shortcut
like being able to AXFR signalling zones but in general you can't
count on it.


The current draft is unrelated to whether a parent performs CDS/CDNSKEY 
scanning on unsigned children. https://github.com/oskar456/cds-updates 
documents 9 registries and 2 registrars who already do so today.

In fact, all of these support the insecure bootstrapping method, which requires 
them to repeat these queries multiple times over a few days, typically from 
multiple vantage points, in order to gain some (non-cryptographic) confidence 
in the integrity of the child's CDS/CDNSKEY records.

The authenticated bootstrapping protocol at hand would render these additional 
queries (which are being performed today!) unnecessary, as the CDS/CDNSKEY 
records' integrity can be verified immediately upon first discovery.

The current draft is thus expected to *reduce* the number of queries necessary 
for scanning parents.

Best,
Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-bootstrapping

2023-11-13 Thread Peter Thomassen


Hi Paul,

Thanks for your thoughts. I'd like to address your points below and would very 
much appreciate your follow-up response.

On 11/11/23 12:55, Paul Wouters wrote:

I have read the document and I am supportive of the idea, but I find the
document not ready. Some issues I have with the document in the current form:

- It "deprecates" RFC8078 but does not offer a solution for all cases of
   8078, such as when all nameservers are in-domain of the child.


That is correct. This deprecation was requested to be clarified (but not 
challenged) in the Dnsdir review [1].

During the subsequent considerations on the list, nobody objected, which I read as 
"the WG prefers deprecation".

If the WG feels differently, let's change the text. Perhaps one or two people 
could speak up if they would prefer such a change.

The question at hand is whether, given the cryptographically secure method of 
this document, we want to continue endorsing an insecure method, even if only 
for in-domain nameservers.

I can imagine three kinds of things to say in the draft without continuing to 
endorse insecure bootstrapping:

1.) discourage the insecure method (by deprecating it);
2.) perhaps even discourage in-domain nameservers;
3.) perhaps point out that one might perform DNSSEC bootstrapping with at least 
one out-of-domain nameserver, then switch to in-domain nameservers (e.g., via 
CSYNC).

The draft currently does the first thing, but not the other two.

In-domain nameservers cause a bunch of problems (including the orphaned glue 
saga), and are also foreseen to be incompatible with DELEG-style delegations in 
ServiceMode [2].

Reserving any judgment on the DELEG mechanism itself, it appears to me that 
in-domain nameservers are best advised against. So perhaps what we should do is 
(1) + (2).

[1]: https://mailarchive.ietf.org/arch/msg/dnsop/04LYtemBnRjOBLWzgdD6RuaD5UU/
[2]: https://mailarchive.ietf.org/arch/msg/dnsop/rUY8CJHrrZYa0Sdvi3BV10IsfiE/


- Section 4.3 is named "Triggers" but it basically only describes
   "Timers". Some of us have significant scar tissue on this matter,
   and I don't see new information or a new technology here that
   resolves this old discussion. It feels a lot like restating RFC8078.


The situation in this draft is different from the trigger conditions in in 
Section 6.1 of RFC 7344 (which I think is what you meant). That RFC lists 
conditions for *updating* a DS RRset. This one here is for *initializing*, so 
other scenarios apply.

For example, one condition listed here (but not in RFC 7344) for triggering the 
CDS authentication procedure is when the parent receives a new or updated NS 
record set for a child.

Besides scans (which of course have a timer) and the receipt of a new NS RRset 
(which doesn't), the draft also mentions walking a list of children known to be 
in need of bootstrapping, perhaps received by AXFR or extracted via NSEC walk 
of signaling zones (and the NS receipt). I don't see any relation to timers 
here.


However, this is second instance (after [3]) that someone suggests to remove 
this section, so perhaps it's time to do so. Before doing so, I'd like to point 
out the following:

The main takeaway from Section 4.3 is that the authentication mechanism 
requires reliable knowledge of the delegation's NS records, which -- depending 
on the trigger method -- may or may not be implicit in the trigger condition; 
as a result, a cross-check in the parent's database may be needed for certain 
triggers. This point is not contained in RFC 7344 (which deals with updates 
which use the child's existing chain of trust, so this point doesn't apply).

In particular, scanning the registry database or installing a new NS RRset 
gives *certain* knowledge of what the NS records are, because the trigger 
conditions directly derive from processing an NS RRset that has previously been 
accepted for delegation.

In contrast, when processing some kind of list fetched externally (e.g. walking 
the signaling domain _signal.$NS), it's possible to encounter signaling records 
pertaining to domains that are *not* delegated to $NS; therefore, the parent 
has to check that what's found in the list matches an actual delegation.

I would like to hear your opinion on whether this point warrants the existence 
of Section 4.3; if it doesn't, I'll go ahead and remove it.

[3]: https://mailarchive.ietf.org/arch/msg/dnsop/toP-e7Rc-ZLg0dR2SvzC25kAGxk/


- Style: I think the document is a lot more verbose and repetitive than
   it needs to be. Condensing this would increase clarity of the
   document.


It looks like opinions within the WG differ here: the only other two feedbacks on style 
asked for more examples and otherwise described it as "very clear" (both from 
Secdir, [4]), and suggested to be more verbose by adding full RRset examples [5].

I'll be happy to make adjustments, but I'm uncertain about what to change without 
"making it worse" from the perspective of others. Would you be able

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-bootstrapping

2023-11-10 Thread Peter Thomassen


Dear DNSOP,

(This is mainly for those who did not attend today's DNSOP session in Prague.)

The chairs announced today that the below WGLC meant to say that some reactions 
in support of this draft are needed for the document to move forward. (In 
contrast to only asking for objections.)

So, if you support this document, please speak up.

Thanks,
Nils + Peter


On 9/19/23 21:48, Tim Wicinski wrote:


This starts a Working Group Last Call for draft-ietf-dnsop-dnssec-bootstrapping

Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/ 



The Current Intended Status of this document is: Standards Track

This Document will update  7344 and 8078 if approved.

The Document updates brings up something I wanted to raise.
Peter and I chatted about some simple nits (remove references from the 
abstract),
but I wasn't sure if the sections updating older documents was formal enough.
DNSOP has produced a few documents recently that update previous work
(8767, 8020 and 9077 come to mind), and we are advice on that.
(I may very well be overthinking this, which is what I told Peter)


Please review the draft and offer relevant comments.
If this does not seem appropriate please speak out.
If someone feels the document is *not* ready for publication, please speak out 
with your reasons.

This starts a two week Working Group Last Call process, and ends on: October 3, 
2023


thanks
tim


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--
Like our community service? 
Please consider donating at

https://desec.io/

deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] NOTIFY: How to locate the target

2023-11-09 Thread Peter Thomassen


Hi Libor,

On 11/9/23 12:12, libor.peltan wrote:

i think this issue shall be considered in two split cases:

a) when the *registry* is to be notified. [...]

b) when the *registrar* is to be notified. [...]


The sender of the NOTIFY does not know whether, for this particular parent, the 
registry or the registrar is in charge of processing. They could keep some ugly 
list about this, but then also that list could get outdated.

In my view, it is therefore a requirement for the discovery method to cover 
both cases (so, the solution can't be derived from considering them 
independently).


The "alternative #2" would demand creating a new zone with as many records 
(mostly CNAMEs?) as there are delegations in the registry. I'd expect this would be 
operationally difficult at least from the point of adding/removing records for the zones 
that are added/removed from the registry. Aesthetically speaking, I don't like this idea.


The zone doesn't need to be statically populated. It may be a service that 
looks in the registry database and returns the corresponding data.

This is not unlike the bootstrapping signaling, which people don't statically 
provision: If you query CDS _dsboot.thomassen.io._signal.ns1.desec.io, you get 
a synthesized and dynamically signed answer with thomassen.io's CDS record 
data. Cloudflare does the same.

Perhaps we should let go of the mental model of statically configured zones.

Best,
Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] NOTIFY: How to locate the target

2023-11-08 Thread Peter Thomassen


Dear DNSOP,

As laid out at the DNSOP session on Tuesday, 
draft-ietf-dnsop-generalized-notify (and also 
draft-johani-dnsop-delegation-mgmt-via-ddns) require a method for locating the 
parent-side endpoint (target) where the child DNS operator can send a NOTIFY 
for DS update (or other kind of signal).

Locating the target via a DNS query needs a predictable qname and type. The 
feeling from the room was that for various reasons, a new rrtype with SVCB 
semantics should be used.

As for the qname, the authors would like to gather some feedback from the list regarding 
the preferred approach. The below uses the domain "child.se" for illustration:

Alternative #1(a): Look up record at se. (delegating parent's apex)
- Simple
- Clogs the apex with more records
- Likely does not cover all use cases (such as per-registrar target, when they 
want to process the NOTIFY)

Alternative #1(b): Look up record at _notify.se. (some underscore label below 
parent)
- Slightly more complex than above
- Avoids clogging the apex, at the expense of some namespace pollution
- Covers same use cases

Alternative #2: Look up record at child._notify.se. (or other magic label)
- Allows parent to publish per-child targets (e.g. the registrar's endpoint)
   * Needs maintenance or synthesis
- Magic label could be considered namespace pollution
- Unneeded complexity if parent is not a registry (e.g. a university)

Alternative #3: Try #2, and on failure fall back to #1(a) or #1(b)
- Combines simplicity and flexibility, but conceptually most complex
- Might cause two DNS queries

Please weigh in on what you think is the best approach.

Thanks,
Johan, John, Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Automated delegation management via DDNS

2023-10-27 Thread Peter Thomassen





On 10/27/23 11:51, Johan Stenstam wrote:

Extra vantage points are a mitigation for the (prevalent) lack of signatures 
during bootstrapping; once authentication is handled, there's no need for it.


I get that. But, as you know from both the draft and the presentation I made at 
OARC some weeks ago, this is really not about how to make scanners slightly 
less inefficient.


Ack


But I have to ask: is your point just that I should get my math right or is 
your point that scanners are fine, every parent should run one and there is no 
problem to solve?


Purely the former!

Scanners are, of course, inefficient, and notifications are a way to improve 
that. I just think that as we are making comparisons, with arguments whose 
strength is (in part) based on the number of queries needed, we should get the 
order of magnitude right, to make the comparisons as helpful as possible. 
That's all! :)

Best,
Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Automated delegation management via DDNS

2023-10-26 Thread Peter Thomassen

On 10/25/23 18:19, Johan Stenstam wrote:
With “scanners” I refer to CDS scanners and CSYNC scanners. These things issue a gazillion DNS queries, over and over and over, with an extremely small catch of “new CDS” or “new CSYNC” records. They get hit by rate limiting measures from the large DNS providers

If that's the case, there's a significant problem. Do you have numbers on the
extent of the problem / how much of an issue that is for your daily runs at .se?

And not only from one vantage point but from several, located around the world.

That's only needed for unauthenticated bootstrapping; both authenticated
bootstrapping and CDS-induced DS updates don't need multiple vantage points.

Extra vantage points are a mitigation for the (prevalent) lack of signatures
during bootstrapping; once authentication is handled, there's no need for it.

Furthermore, for unsigned delegations, all the nameservers are queried. Every
time. It’s a lot of DNS queries.

Where's that written?

I don't think it's correct. For example, if you find on the same nameserver
that you queried a CDS/CDNSKEY RRset that indicates no change over the existing
DS record, then there's no point in looking at other nameserver. (They would
either confirm that no update should happen, or they would be contradictory, in
which case no update should happen.)

Together with the vantage-point considerations, I think the actual number of
queries is about 10x lower than if all NS are always asked from several vantage
points.

But do I know of any real life large scale deployments of DNSSEC for corporate
internal zones?

I may be wrong, but I believe Salesforce to be an example.

Best,
Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] scanning doesn't scale, draft-thomassen-dnsop-generalized-dns-notify and draft-ietf-dnsop-dnssec-bootstrapping

2023-10-16 Thread Peter Thomassen


John,

On 10/16/23 18:19, John R Levine wrote:

On Mon, 16 Oct 2023, Peter Thomassen wrote:

3. the parent obtains a copy of a signaling zone and walks the signaling 
records published there (at _signal.$NS, such as _signal.jo.ns.cloudflare.com),


If you think about it for a moment,


I did :-)


#3 doesn't work very well, since every parent needs to scan all the signalling 
zones for all the nameservers they might be using.


For bystanders' context, we're discussing Section 4.3 of 
draft-ietf-dnsop-dnssec-bootstrapping.

No parent needs to scan anything. They might want to do so, if they think it's 
feasible for them, or they can find other solutions that are better for them, 
such as outlined below. (Or they might of course not do DS automation at all.)

A DNS operator and a parent may make an arrangement and agree on some method 
for how the parent can learn about the set of domains under the parent that 
have new signaling records. This method may be that the parent AXFR's the 
operator's signaling zone, which is but one of many options. Such an approach 
seems reasonable for large DNS operators which have many domains changing every 
day; a parent certainly wouldn't make such arrangements with every DNS operator 
in the world.

We're getting into a quite interesting topic space here, but it is entirely out 
of scope for this document. The document is concerned with how the parent can 
authenticate CDS/CDNSKEY records *after learning about their existence*; it 
does not deal with how to learn about their existence (beyond the very 
high-level, illustrative list given in Section 4.3).


Cloudflare hosts at least a million zones which I'm sure are in every public 
TLD, so that means we have a thousand TLDs and/or a thousand registrars all 
scanning Cloudflare's signalling zone which is not going to be small.  How's 
that going to scale?  For that matter, how's Cloudflare going to give the TSIG 
or whatever to the thousand scanners to let them do it?


There are a bunch of very specific assumptions in here, "to make it not work". 
Consider the following:

- DNS operators like Cloudflare could provide a copy of the contents under, 
say, se._signal.jo.ns.cloudflare.com to the .se registry. If done via a 
separate zone, there will be no pollution from other TLDs. [*]

- Alternatively, DNS operators can provide TLD-specific catalog zones, or 
CSV-like feeds, even blockchain. Actually, the method of obtaining the list 
doesn't matter for the argument in Section 4.3.

- Someone like Cloudflare could allowlist the registry's IP addresses, and 
nobody needs to set up TSIG.

- The parties can agree to restrict this to only keep entries younger than a 
certain time period (e.g. 1 day + buffer), and in turn process it regularly. 
This makes a very well-tailored list of bootstrapping requests.

- It is conceivable that the processing be done by the registry, not the 
registrar (as is the case for today's deployments), so there is only one 
ingesting party that needs to be allowlisted (per parent).

- Alternatively, if the registrar does the processing, some registrar endpoint 
signaling is needed (as is pondered in the NOTIFY draft). But surely this is 
not in scope of this document.

The main point here is that *none* of this has anything to do with what the 
parent does *after* the trigger (whichever one) has fired -- which is what the 
document describes.


Why talk about triggers at all in Section 4.3? -- The parent needs to consider 
that, depending on the trigger mechanism, the trigger context will or will not 
convey reliable knowledge of the delegation's NS RRset, so for some trigger 
types it will have to match against its local delegation database before 
proceeding. Pointing this out is relevant for the authentication process, and 
is the purpose of Section 4.3.


We've digressed quite a bit from your criticism, which was your cognitive dissonance that 
this document "says to scan for DS bootstrap", which it clearly does not. I 
hope the cognitive dissonance has been cleared up :-)

As for how to learn about which are appropriate triggers, this indeed seems to 
be a gap where additional standards development could help, and I share some 
(not all) of your opinions. Let's put it into the NOTIFY draft, or a more 
general one that discusses other triggers as well (e.g. the feed-like mechanism 
hinted at above, or something based on catalog zones). But please let's not do 
it here.


2. the parent chooses to do a scan,


This is no better.  For CDS scanning the scan is a single query to a single 
known server only for zones that are already signed.  But for this, it has to 
scan all the unsigned zones, and since the NS can be anywhere, each scan is a 
full recursive lookup.  That's a lot of traffic to a lot of servers all over 
the net.


This does not seem to make sense to me: For a conventional CDS lookup, you have 
to query the child's nameserver(s), which you need to reso

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-bootstrapping

2023-10-16 Thread Peter Thomassen


Hi all,

For others following along: Upon Tim's suggestion towards the end of this WGLC, 
I had sent notes to a handful of ICANN folks who are involved with DNSSEC, but 
who may not be subscribed this list. I forwarded the WGLC message to them on 
Sep 29 and extended Tim's invitation to offer relevant comments. This did not 
elicit any concerns (neither privately nor publicly).

If the chairs could advise on the next step(s), the authors would appreciate it.

Thanks,
Peter


On 9/19/23 21:48, Tim Wicinski wrote:


This starts a Working Group Last Call for draft-ietf-dnsop-dnssec-bootstrapping

Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/ 



The Current Intended Status of this document is: Standards Track

This Document will update  7344 and 8078 if approved.

The Document updates brings up something I wanted to raise.
Peter and I chatted about some simple nits (remove references from the 
abstract),
but I wasn't sure if the sections updating older documents was formal enough.
DNSOP has produced a few documents recently that update previous work
(8767, 8020 and 9077 come to mind), and we are advice on that.
(I may very well be overthinking this, which is what I told Peter)


Please review the draft and offer relevant comments.
If this does not seem appropriate please speak out.
If someone feels the document is *not* ready for publication, please speak out 
with your reasons.

This starts a two week Working Group Last Call process, and ends on: October 3, 
2023


thanks
tim


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--
Like our community service? 
Please consider donating at

https://desec.io/

deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-structured-dns-error-06.txt

2023-10-16 Thread Peter Thomassen


Nargh, I forgot my main point, which was on the suggestion in the security considerations to only diepslay 
"c"/"j"/"o" iff the resolver has sufficient

reputation, according to some local policy (e.g., user configuration,
administrative configuration, or a built-in list of respectable
resolvers).

I think this needs to be fleshed out more to be helpful.

For example, when my resolver is configured dynamically as I switch networks, 
how can users (or even administrators, for mobile devices) be expected to 
assess and configure a resolver's reputation?

And if we expect this to not be configured in most cases, with "c"/"j"/"o" not 
being used as a consequence, then why bother?

Regarding the built-in list of respectable resolvers, who should maintain this 
list, and why? And how often is updated in browser? etc.pp. Smells like a PSL 
kind of problem ...

Thanks,
Peter


On 10/16/23 12:37, Peter Thomassen wrote:



On 10/13/23 10:05, tirumal reddy wrote:

The above attack and possible mitigation is discussed in the security 
considerations section of the draft, please see the snip below:


    A client might choose to display the information in the "c", "j", and
    "o" fields if and only if the encrypted resolver has sufficient
    reputation, according to some local policy (e.g., user configuration,
    administrative configuration, or a built-in list of respectable
    resolvers).  This limits the ability of a malicious encrypted
    resolver to cause harm.  For example, an end user can use the details
    in the "c" field to contact an attacker to solve the problem of being
    unable to reach a domain.  The attacker can mislead the end user to
    install malware or spyware to compromise the device security posture
    or mislead the end user to reveal personal data.  If the client
    decides not to display all of the information in the EXTRA-TEXT
    field, it can be logged for diagnostics purpose and the client can
    only display the resolver hostname that blocked the domain, error
    description for the EDE code and the suberror description for the "s"
    field to the end-user.




I share this concern (and Eric's, where the error page is an impersonation of 
the target page!), and am not convinced that the potential benefit is larger 
than the harm.

An alternate route could be to make the error page "well-known", based on the 
encrypted resolver's hostname (e.g. https://dns.adguard.com/?malw.scalone.eu.), and have the 
browser display a big warning ("This content does not come from the page you requested.).

This could be combined with disabling redirects and/or form submissions on the 
resolver's domain origin, so that the resolver server itself has to be able to 
serve the page, without redirecting anywhere to make the domain name look 
differently and without collecting login credentials à la phishing. For a 
branded error page with nice UX, that should be completely sufficient. (Are 
there any known use cases not accommodated by this?)

I'm not sure this would alleviate all concerns (and perhaps it's not much 
better), but *at least* it would prevent trivial attacks where the error page 
would redirect me from twitter.com to twítter.com, even though I typed the 
former, but the latter has a proper TLS certificate, so I couldn't otherwise 
notice a problem.

Thanks,
Peter



--
Like our community service? 
Please consider donating at

https://desec.io/

deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-structured-dns-error-06.txt

2023-10-16 Thread Peter Thomassen




On 10/13/23 10:05, tirumal reddy wrote:

The above attack and possible mitigation is discussed in the security 
considerations section of the draft, please see the snip below:


A client might choose to display the information in the "c", "j", and
"o" fields if and only if the encrypted resolver has sufficient
reputation, according to some local policy (e.g., user configuration,
administrative configuration, or a built-in list of respectable
resolvers).  This limits the ability of a malicious encrypted
resolver to cause harm.  For example, an end user can use the details
in the "c" field to contact an attacker to solve the problem of being
unable to reach a domain.  The attacker can mislead the end user to
install malware or spyware to compromise the device security posture
or mislead the end user to reveal personal data.  If the client
decides not to display all of the information in the EXTRA-TEXT
field, it can be logged for diagnostics purpose and the client can
only display the resolver hostname that blocked the domain, error
description for the EDE code and the suberror description for the "s"
field to the end-user.




I share this concern (and Eric's, where the error page is an impersonation of 
the target page!), and am not convinced that the potential benefit is larger 
than the harm.

An alternate route could be to make the error page "well-known", based on the 
encrypted resolver's hostname (e.g. https://dns.adguard.com/?malw.scalone.eu.), and have the 
browser display a big warning ("This content does not come from the page you requested.).

This could be combined with disabling redirects and/or form submissions on the 
resolver's domain origin, so that the resolver server itself has to be able to 
serve the page, without redirecting anywhere to make the domain name look 
differently and without collecting login credentials à la phishing. For a 
branded error page with nice UX, that should be completely sufficient. (Are 
there any known use cases not accommodated by this?)

I'm not sure this would alleviate all concerns (and perhaps it's not much 
better), but *at least* it would prevent trivial attacks where the error page 
would redirect me from twitter.com to twítter.com, even though I typed the 
former, but the latter has a proper TLS certificate, so I couldn't otherwise 
notice a problem.

Thanks,
Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-thomassen-dnsop-generalized-dns-notify and draft-ietf-dnsop-dnssec-bootstrapping

2023-10-16 Thread Peter Thomassen

John,

On 10/13/23 19:48, John Levine wrote:

I was looking at these two drafts. The first one says that scanning
for CDS updates is bad, so use NOTIFY(CDS) rather than scanning. The
second one says to scan for DS bootstrap.

No, draft-ietf-dnsop-dnssec-bootstrapping doesn't say that at all.

The word "scan" indeed does appear in Section 4.3 ("Triggers"), which says that the
parent SHOULD trigger the DNSSEC bootstrapping process "once one of the following conditions is
fulfilled". It then lists a bunch of possible such conditions, including

1. the parent receives an updated NS RRset,
2. the parent chooses to do a scan,
3. the parent obtains a copy of a signaling zone and walks the signaling
records published there (at _signal.$NS, such as _signal.jo.ns.cloudflare.com),
4. any other condition deemed appropriate,

with the latter one capturing some kind of notification like you suggest, and
method 2 reflecting the existence of corresponding deployments at various
ccTLDs and at RIPE NCC.

I don't see anything here that recommends scanning in particular or otherwise
makes any kind of judgment on what kind of condition is appropriate. It just
says, *if* any such conditions appear to be fulfilled, then please use the
specified procedure for authenticating CDS/CDNSKEY records.

("Scan" also appears in section 5.2 on operational recommendations, where it
says that you shouldn't carry over authentication information between scans, but that
doesn't mean that you should scan. Happy to improve that sentence if you think it's
ambiguous.)

I suggest adjusting the bootstrap draft saying to send NOTIFY(DS) to
the parent of a delegated name to tell it to do the bootstrap rather
than scanning.

The draft is not at all concerned about how the child triggers the parent, but
only with what the parent does *once the parent has determined* that it is
going to attempt DS initialization.

The NOTIFY issue you're raising is very much worthwhile (and I care for it, as you
can see by the fact that we're both co-authors of the NOTIFY(CDS) draft), but that
doesn't mean that it needs to be intermingled with the parent's authentication
mechanism for CDS/CDNSKEY records. KISS, divide & conquer etc.

Bonus update: if we do this, in the bootstrap draft take out section
4.3 on triggers and instead say to use notify.

Besides acknowledging that various trigger mechanisms exist, the takeaway from
Section 4.3 is that the authentication mechanism requires reliable knowledge of
the delegation's NS records; however, depending on the trigger method, this
piece of information may or may not be conveyed directly through the trigger
condition, so a cross-check in the parent's database may be needed.

In particular, methods 1 and 2 above give certain knowledge of what the NS
records are, because the trigger conditions directly derive from processing an
NS RRset that has previously been accepted for delegation.

In contrast, when using method 3 (walking the signaling domain _signal.$NS),
it's possible to encounter signaling records pertaining to domains that are not
delegated to $NS; therefore, the parent has to check that what's found in a
signaling zone matches an actual delegation, and not accept authentication
information from potentially fraudulent signaling records.

This discussion is independent of the notification problem, and I don't think
that it would be helpful to remove it.

The authors also don't see why one should not point out that various triggers
methods exist, and as a result prefer that the section remain in the document.

Thanks,
Nils and Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-bootstrapping-06.txt

2023-10-02 Thread Peter Thomassen


Dear DNSOP,

This revision

- addresses editorial feedback from Secdir review (circulated on this list 
earlier);
- improves the description of RFC updates, as suggested by Tim in his WGLC 
message;
- fixes a nit in the abstract which Tim had found.

Thanks,
Nils & Peter


On 10/2/23 23:56, internet-dra...@ietf.org wrote:

Internet-Draft draft-ietf-dnsop-dnssec-bootstrapping-06.txt is now available.
It is a work item of the Domain Name System Operations (DNSOP) WG of the IETF.

Title:   Automatic DNSSEC Bootstrapping using Authenticated Signals from 
the Zone's Operator
Authors: Peter Thomassen
 Nils Wisiol
Name:draft-ietf-dnsop-dnssec-bootstrapping-06.txt
Pages:   17
Dates:   2023-10-02

Abstract:

This document introduces an in-band method for DNS operators to
publish arbitrary information about the zones they are authoritative
for, in an authenticated fashion and on a per-zone basis.  The
mechanism allows managed DNS operators to securely announce DNSSEC
key parameters for zones under their management, including for zones
that are not currently securely delegated.

Whenever DS records are absent for a zone's delegation, this signal
enables the parent's registry or registrar to cryptographically
validate the CDS/CDNSKEY records found at the child's apex.  The
parent can then provision DS records for the delegation without
resorting to out-of-band validation or weaker types of cross-checks
such as "Accept after Delay".

This document deprecates the DS enrollment methods described in
Section 3 of RFC 8078 in favor of Section 4 of this document, and
also updates RFC 7344.

[ Ed note: This document is being collaborated on at
https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/
(https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/).
The authors gratefully accept pull requests. ]

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-dnsop-dnssec-bootstrapping-06.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-dnssec-bootstrapping-06

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--
Like our community service? 
Please consider donating at

https://desec.io/

deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-bootstrapping

2023-10-02 Thread Peter Thomassen




On 9/19/23 21:48, Tim Wicinski wrote:

This Document will update  7344 and 8078 if approved.

The Document updates brings up something I wanted to raise.
Peter and I chatted about some simple nits (remove references from the 
abstract),
but I wasn't sure if the sections updating older documents was formal enough.
DNSOP has produced a few documents recently that update previous work
(8767, 8020 and 9077 come to mind), and we are advice on that.
(I may very well be overthinking this, which is what I told Peter)


Thank you for suggesting this.

We've added a section on these RFC updates. It reads as follows (the first 
paragraph was just moved up from another section, and the second is a 
clarification):

2.  Updates to RFCs

   The DS enrollment methods described in Section 3 of [RFC8078] are
   deprecated and SHOULD NOT be used.  Child DNS Operators and Parental
   Agents who wish to use CDS/CDNSKEY records for initial DS enrollment
   SHOULD instead support the authentication protocol described in
   Section 4 of this document.

   In order to facilitate publication of signaling records for the
   purpose of DNSSEC bootstrapping (see Section 4.1), the first bullet
   ("Location") of [RFC7344] Section 4.1 is removed.

Best,
Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-cds-consistency-04.txt

2023-10-02 Thread Peter Thomassen


Dear DNSOP,

This revision has changes in response to David Blacka's Dnsdir review. 
Changelog:

  * Clean up "multi-homing" and define "multi-provider"/"multi-signer"
  * Clarify that existing CSYNC NS and glue processing rules remain in place
  * Minor editorial changes

Thanks,
Peter


On 10/2/23 13:33, internet-dra...@ietf.org wrote:

Internet-Draft draft-ietf-dnsop-cds-consistency-04.txt is now available. It is
a work item of the Domain Name System Operations (DNSOP) WG of the IETF.

Title:   Consistency for CDS/CDNSKEY and CSYNC is Mandatory
Author:  Peter Thomassen
Name:draft-ietf-dnsop-cds-consistency-04.txt
Pages:   13
Dates:   2023-10-02

Abstract:

Maintenance of DNS delegations requires occasional changes of the DS
and NS record sets on the parent side of the delegation.  RFC 7344
automates this for DS records by having the child publish CDS and/or
CDNSKEY records which hold the prospective DS parameters.  Similarly,
RFC 7477 specifies CSYNC records to indicate a desired update of the
delegation's NS (and glue) records.  Parent-side entities (e.g.
Registries, Registrars) typically discover these records by querying
them from the child, and then use them to update the parent-side
RRsets of the delegation accordingly.

This document specifies that when performing such queries, parent-
side entities MUST ensure that updates triggered via CDS/CDNSKEY and
CSYNC records are consistent across the child's authoritative
nameservers, before taking any action based on these records.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-cds-consistency/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-dnsop-cds-consistency-04.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-cds-consistency-04

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--
Like our community service? 
Please consider donating at

https://desec.io/

deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Dnsdir early review of draft-ietf-dnsop-cds-consistency-03

2023-10-02 Thread Peter Thomassen


Hi David,

I've merged the below changes into the draft, now available on the datatracker 
as -04.

Thanks,
Peter


On 9/7/23 18:52, Peter Thomassen wrote:

Hi David,

First of all, thanks for the review!

The changes made in response to it (plus a few minor editorial changes I found 
useful) are recorded here:
https://github.com/peterthomassen/draft-ietf-dnsop-cds-consistency/pull/4

I'd appreciate if you can let me know if you agree with them, so I can merge 
them. -- Further comments inline.

On 8/30/23 15:58, David Blacka via Datatracker wrote:

From a specification-purity point of view, the concept of multiple providers is

actually not needed or relevant to this draft.  Nameservers could be out of
sync for a variety of reasons.  This draft could be written without a single
mention of multi-provider (multi-homed?) or multi-signer situations and be
shorter and perhaps clearer.  Although, it might be important to point out that
there are more reasons than just being out-of-sync from a single primary source.

On the other hand, knowing that multiple provider setups exist is a strong
motivator for this specification.  Without considering multiple provider
setups, we are prone to imagining that all setups are synced from a single
source, and all deviation is temporal and temporary.


Exactly -- in multi-provider setup, the source is diverse. What's more: before 
joining a multi-signer constellation, each party has a different set of 
DNSKEYs, and they'll need to converge on a merged set that has everyone's 
relevant keys (namely, those KSKs that will later be referenced via DS records, 
but no cross-provider ZSKs), before publishing corresponding CDS/CDNSKEY RRsets 
to update the delegation's DS RRset.

There's a lot of potential for error here, particularly when it's not 
automated, or when automation software is new and hasn't yet stood the test of 
time (as is expected to be the case). It was in this context that this draft 
was conceived, and I think it's a much stronger motivator than merely being 
out-of-sync by replication lag (which would only cause benign DS flapping 
unless other things are broken, too).

I'd thus like to keep mention of this in the Introduction and Security Considerations. -- 
The third occurrence of "multi-signer" is in the appendix describing the 
various failure modes. I hoped that would be enlightening, but I don't mind dropping it. 
Is that what you are proposing?


If the draft is not recast to just not directly mention
multi-homing/multi-provider/multi-signing setups, it should define the term
near the start of the draft.  I would prefer using "multi-provider" because I
believe it is both clearer and less encumbered with other meanings in nearby
subjects (like networking), and perhaps covers more situations than
"multi-signer".


I agree with your sentiments about multi-homing, and I've changed them to 
"multi-provider".

"Multi-provider" emphasizes the redundancy aspect; the DNSSEC status of the 
domain is not relevant. (For example, github.com has a non-DNSSEC multi-provider setup 
between NS1 and AWS.)

"Multi-signer", OTOH, describes the special case of multiple signing entities, 
which in turn contains the special case of glitch-free provider change (which isn't about 
redundancy, but about continuity of operation).

I therefore think there is reason to keep these two terms (but "multi-homing" 
can be dropped). The relevant paragraph in the Introduction now says:

    [...] adverse consequences can arise in conjunction with the
    multi-signer scenarios laid out in [RFC8901], both when deployed
    temporarily (during a provider change) and permanently (in a
    redundant multi-provider setup).

I also added definitions to the Terminology section:

    Multi-provider setup:  A constellation where several providers
   independently operate authoritative DNS service for a domain,
   usually for purposes of redundancy.  This includes setups both
   with and without DNSSEC.

    Multi-signer setup:  A multi-provider setup for a DNSSEC-enabled
   domain with multiple independent signing entities [RFC8901].  Such
   a setup may be permanent (for redundancy) or temporary (for
   continuity of DNSSEC operation while changing the provider of a
   domain that normally uses a single one).

Does this address your concern?


My last major concern is with section 2.2, CSYNC.  RFC 7477 has many rules that
a parental agent must consider before accepting a CSYNC update.  It is unclear
how those rules interact with the rules specified in section 2.2.  I think what
is meant is this:

 Each parent-side nameserver is queried for the CSYNC RRset and the synced
 (NS, A, ) RRsets, and that unless all of the CSYNC type map bits and
 sync data match, syncing must be aborted.

I think some discussion of how this interacts with the existing rules is
warranted.  For exampl

Re: [DNSOP] Call for Adoption: draft-bellis-dnsop-qdcount-is-one

2023-09-29 Thread Peter Thomassen


Hi,

On 9/28/23 18:59, Tim Wicinski wrote:

Please review this draft to see if you think it is suitable for adoption
by DNSOP, and send any comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.


I support adoption and am willing to review.

Best,
Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-thomassen-dnsop-generalized-dns-notify

2023-09-24 Thread Peter Thomassen


Hi Patrick,

On 9/20/23 23:12, pmev...@godaddy.com wrote:

I will probably not be able to contribute a lot, but reading it make me think 
of the following points:


Thank you very much for your feedback; even if you don't feel able to 
contribute a lot, that's VERY helpful :)


- I didn't see discussion about the possible return codes for the NOTIFY 
message, and in which case which DNS error code would happen and what would it 
mean (or is §3.12 of RFC1996 enough?)


Good point. I'm not sure if doing anything beyond that would add any reliable 
benefit, as the return code cannot be signed.

For example, if one would specify REFUSED for when a parent-side rate limit is 
exceeded, an suitable attacker could trick the child into thinking that a DS 
rollover cannot currently be triggered, which may mislead the child about what 
to do next.

Perhaps it's better to not send such signals, and rather have the child 
determine its next steps by assessing the actual situation (i.e., observing 
which DS records are deployed etc.).

It would be interesting to learn what you think about this.

This is tracked at 
https://github.com/peterthomassen/draft-thomassen-dnsop-generalized-dns-notify/issues/11.


- maybe I missed it but didn't find clear indications that the NOTIFY message 
should (or should not) be with ANCOUNT>0 and the answer section having the 
relevant records to sync, or in contrary forbidding this to force retrieval by 
usual DNS queries enforced by DNSSEC protections


Section 4 says:

   [...]  Upon receipt of NOTIFY(CDS), the parent SHOULD initiate the
   same scan that would otherwise be triggered based on a timer.

In other words, records provided in the NOTIFY message are not to be used.

Some more thoughts on this topic are here: 
https://github.com/peterthomassen/draft-thomassen-dnsop-generalized-dns-notify/issues/13


- SRV instead of new record type is discussed in §9.1 but then rejected: was 
SVCB discussed? I think it could be used without having to override anything, 
as you can write a proper profile for it (as HTTPS does), and have more 
SvcParamKeys


I'm deferring to Johan.


- it is a different use case, but the same mechanism could be useful in another 
case, so even if not discussed in the draft, maybe having it in mind could 
allow to easily work on it later: instead of manual/web based way to ask 
recursive resolvers to flush a given (name, rdtype) entry (because of some 
emergency switch wanted), use some kind of NOTIFY to send that signal (with of 
course the problem of authenticating the source, but it is similar for 
CDS/CDNSKEY and in part discussed in §11)


Neat idea! I think this needs some input from resolver people.


- while not creating an amplification problem, I think some explanations should be given 
around the case of some attacker trying to disrupt by sending lots of notify, which can 
be rate-limited or ignored, but my worries is if the notify receiver then just decides to 
"ignore" all notifies for a given zone (not taking into account emitter IPs, or 
just seeing too many of them), which would then prevent the real owner to send notify, or 
more precisely to make them worth. Of course nothing breaks but convergence may then go 
back to slower agenda, which means the attacker succeeded somehow to disrupt the real 
owner operations.


Yes. Some extra thoughts are here: 
https://github.com/peterthomassen/draft-thomassen-dnsop-generalized-dns-notify/issues/17#issuecomment-1513789295

Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] RFC 9476 on The .alt Special-Use Top-Level Domain

2023-09-14 Thread Peter Thomassen





On 9/15/23 00:19, rfc-edi...@rfc-editor.org wrote:

A new Request for Comments is now available in online RFC libraries.

 
 RFC 9476


 Title:  The .alt Special-Use Top-Level Domain
 Author: W. Kumari,
 P. Hoffman


Finally! Congratulations.

~Peter

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-rfc8109bis

2023-09-14 Thread Peter Thomassen


Hi Benno,

On 9/14/23 10:14, Benno Overeinder wrote:

As Tim mentioned, the chairs paused WGLC or WG Call for Adoptions in August and 
are now starting the chairs action points in September.  Your 
draft-ietf-dnsop-dnssec-bootstrapping document is scheduled immediately after 
this WGLC.  We will contact you and Nils next week before sending the WGLC to 
the DNSOP mailing list.


I must have missed Tim's mention regarding August; besides, the confusion 
really was more about the order of things (in the light of the order announce 
after IETF 117), and less about a break overall.

Thank you very much for the clarification!


Apologies for the delays.  While balancing the work in the DNSOP WG, your draft 
was delayed during the summer months.

Sure, no question about that at all! We certainly appreciate the work you're 
doing!

Cheers,
Peter

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-rfc8109bis

2023-09-14 Thread Peter Thomassen


Missing reference:
[1]: https://mailarchive.ietf.org/arch/msg/dnsop/vHltEr8mlxsy2nyscqcCF2ZGz8U/

On 9/14/23 09:53, Peter Thomassen wrote:

Hi Tim,

On 9/13/23 23:05, Tim Wicinski wrote:

We Chairs are back and catching up, and want to get things moving again.

This starts a Working Group Last Call for draft-ietf-dnsop-rfc8109bis
"Initializing a DNS Resolver with Priming Queries"

Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8109bis/ 
<https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8109bis/>

While others have commented that this draft is not ready for WGLC, Nils and I 
would like to note that the Chairs Actions after IETF 117 [1] listed an order 
for upcoming WGLC, with this draft listed second and 
draft-ietf-dnsop-dnssec-bootstrapping listed first.

Unlike draft-ietf-dnsop-rfc8109bis which has been adopted only in June 2023, 
draft-ietf-dnsop-dnssec-bootstrapping has been sitting there, with several 
implementations and without any modifications (beyond minor editorial), for 
over a year.

The authors have been interacting with the chairs a few times since the 
beginning of the year, to see if anything needs to be done for the draft to 
advance. In the process, we have been told (in May) that an announcement for 
WGLC readiness would be sent to the WG list, and later that WGLC would be 
started before IETF 118. Once IETF 118 was over, the draft was listed first in 
the Chairs Actions. Now it's been postponed again.

We'd like to take the opportunity of this WGLC thread to express our confusion 
about the situation. We would be grateful if the chairs could clarify the 
situation, and identify, on the list, any potential issues that might keep 
draft-ietf-dnsop-dnssec-bootstrapping from advancing so that they can be 
addressed properly (if any).

Thanks,
Nils and Peter



--
Like our community service? 
Please consider donating at

https://desec.io/

deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-rfc8109bis

2023-09-14 Thread Peter Thomassen


Hi Tim,

On 9/13/23 23:05, Tim Wicinski wrote:

We Chairs are back and catching up, and want to get things moving again.

This starts a Working Group Last Call for draft-ietf-dnsop-rfc8109bis
"Initializing a DNS Resolver with Priming Queries"

Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8109bis/ 


While others have commented that this draft is not ready for WGLC, Nils and I 
would like to note that the Chairs Actions after IETF 117 [1] listed an order 
for upcoming WGLC, with this draft listed second and 
draft-ietf-dnsop-dnssec-bootstrapping listed first.

Unlike draft-ietf-dnsop-rfc8109bis which has been adopted only in June 2023, 
draft-ietf-dnsop-dnssec-bootstrapping has been sitting there, with several 
implementations and without any modifications (beyond minor editorial), for 
over a year.

The authors have been interacting with the chairs a few times since the 
beginning of the year, to see if anything needs to be done for the draft to 
advance. In the process, we have been told (in May) that an announcement for 
WGLC readiness would be sent to the WG list, and later that WGLC would be 
started before IETF 118. Once IETF 118 was over, the draft was listed first in 
the Chairs Actions. Now it's been postponed again.

We'd like to take the opportunity of this WGLC thread to express our confusion 
about the situation. We would be grateful if the chairs could clarify the 
situation, and identify, on the list, any potential issues that might keep 
draft-ietf-dnsop-dnssec-bootstrapping from advancing so that they can be 
addressed properly (if any).

Thanks,
Nils and Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Dnsdir early review of draft-ietf-dnsop-cds-consistency-03

2023-09-07 Thread Peter Thomassen


Hi David,

First of all, thanks for the review!

The changes made in response to it (plus a few minor editorial changes I found 
useful) are recorded here:
https://github.com/peterthomassen/draft-ietf-dnsop-cds-consistency/pull/4

I'd appreciate if you can let me know if you agree with them, so I can merge 
them. -- Further comments inline.

On 8/30/23 15:58, David Blacka via Datatracker wrote:

From a specification-purity point of view, the concept of multiple providers is

actually not needed or relevant to this draft.  Nameservers could be out of
sync for a variety of reasons.  This draft could be written without a single
mention of multi-provider (multi-homed?) or multi-signer situations and be
shorter and perhaps clearer.  Although, it might be important to point out that
there are more reasons than just being out-of-sync from a single primary source.

On the other hand, knowing that multiple provider setups exist is a strong
motivator for this specification.  Without considering multiple provider
setups, we are prone to imagining that all setups are synced from a single
source, and all deviation is temporal and temporary.


Exactly -- in multi-provider setup, the source is diverse. What's more: before 
joining a multi-signer constellation, each party has a different set of 
DNSKEYs, and they'll need to converge on a merged set that has everyone's 
relevant keys (namely, those KSKs that will later be referenced via DS records, 
but no cross-provider ZSKs), before publishing corresponding CDS/CDNSKEY RRsets 
to update the delegation's DS RRset.

There's a lot of potential for error here, particularly when it's not 
automated, or when automation software is new and hasn't yet stood the test of 
time (as is expected to be the case). It was in this context that this draft 
was conceived, and I think it's a much stronger motivator than merely being 
out-of-sync by replication lag (which would only cause benign DS flapping 
unless other things are broken, too).

I'd thus like to keep mention of this in the Introduction and Security Considerations. -- 
The third occurrence of "multi-signer" is in the appendix describing the 
various failure modes. I hoped that would be enlightening, but I don't mind dropping it. 
Is that what you are proposing?


If the draft is not recast to just not directly mention
multi-homing/multi-provider/multi-signing setups, it should define the term
near the start of the draft.  I would prefer using "multi-provider" because I
believe it is both clearer and less encumbered with other meanings in nearby
subjects (like networking), and perhaps covers more situations than
"multi-signer".


I agree with your sentiments about multi-homing, and I've changed them to 
"multi-provider".

"Multi-provider" emphasizes the redundancy aspect; the DNSSEC status of the 
domain is not relevant. (For example, github.com has a non-DNSSEC multi-provider setup 
between NS1 and AWS.)

"Multi-signer", OTOH, describes the special case of multiple signing entities, 
which in turn contains the special case of glitch-free provider change (which isn't about 
redundancy, but about continuity of operation).

I therefore think there is reason to keep these two terms (but "multi-homing" 
can be dropped). The relevant paragraph in the Introduction now says:

   [...] adverse consequences can arise in conjunction with the
   multi-signer scenarios laid out in [RFC8901], both when deployed
   temporarily (during a provider change) and permanently (in a
   redundant multi-provider setup).

I also added definitions to the Terminology section:

   Multi-provider setup:  A constellation where several providers
  independently operate authoritative DNS service for a domain,
  usually for purposes of redundancy.  This includes setups both
  with and without DNSSEC.

   Multi-signer setup:  A multi-provider setup for a DNSSEC-enabled
  domain with multiple independent signing entities [RFC8901].  Such
  a setup may be permanent (for redundancy) or temporary (for
  continuity of DNSSEC operation while changing the provider of a
  domain that normally uses a single one).

Does this address your concern?


My last major concern is with section 2.2, CSYNC.  RFC 7477 has many rules that
a parental agent must consider before accepting a CSYNC update.  It is unclear
how those rules interact with the rules specified in section 2.2.  I think what
is meant is this:

 Each parent-side nameserver is queried for the CSYNC RRset and the synced
 (NS, A, ) RRsets, and that unless all of the CSYNC type map bits and
 sync data match, syncing must be aborted.

I think some discussion of how this interacts with the existing rules is
warranted.  For example, the type bitmap indicates "A", but the nameservers are
not at/below the delegation, so are ignored.  Does it matter to the algorithm
if the child nameservers have different data for the glue records?


The draft does not touch any existing

Re: [DNSOP] I-D Action: draft-thomassen-dnsop-generalized-dns-notify-02.txt

2023-08-07 Thread Peter Thomassen


For now, minor changes only:

- added John as an author
- explained why using an in-band message format is reasonable (as explained in 
Johan's talk SFO)

Thanks,
Peter


On 8/7/23 11:52, internet-dra...@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the Domain Name System
Operations (DNSOP) WG of the IETF.

Title   : Generalized DNS Notifications
Authors : Johan Stenstam
  Peter Thomassen
  John Levine
Filename: draft-thomassen-dnsop-generalized-dns-notify-02.txt
Pages   : 17
Date: 2023-08-07

Abstract:
Changes in CDS/CDNSKEY, CSYNC, and other records related to
delegation maintenance are usually detected through scheduled scans
run by the consuming party (e.g. top-level domain registry),
incurring an uncomfortable trade-off between scanning cost and update
latency.

A similar problem exists when scheduling zone transfers, and has been
solved using the well-known DNS NOTIFY mechanism ([RFC1996]).  This
mechanism enables a primary nameserver to proactively inform
secondaries about zone changes, allowing the secondary to initiate an
ad-hoc transfer independently of when the next SOA check would be
due.

This document extends the use of DNS NOTIFY beyond conventional zone
transfer hints, bringing the benefits of ad-hoc notifications to DNS
delegation maintenance in general.  Use cases include DNSSEC key
rollovers hints via NOTIFY(CDS) and NOTIFY(DNSKEY) messages, and
quicker changes to a delegation's NS record set via NOTIFY(CSYNC)
messages.

Furthermore, this document proposes a new DNS record type,
tentatively referred to as "NOTIFY record", which is used to publish
details about where generalized notifications should be sent.

TO BE REMOVED: This document is being collaborated on in Github at:
https://github.com/peterthomassen/draft-thomassen-dnsop-generalized-
dns-notify (https://github.com/peterthomassen/draft-thomassen-dnsop-
generalized-dns-notify).  The most recent working version of the
document, open issues, etc. should all be available there.  The
authors (gratefully) accept pull requests.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-thomassen-dnsop-generalized-dns-notify/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-thomassen-dnsop-generalized-dns-notify-02.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-thomassen-dnsop-generalized-dns-notify-02

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--
Like our community service? 
Please consider donating at

https://desec.io/

deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Cache refreshes like in DNS over CoAP

2023-08-04 Thread Peter Thomassen




On 8/4/23 01:29, Petr Menšík wrote:

I started thinking, what if we used EDNS0 extension sending version at the 
client and asked the server if that has changed in the mean time. Lets call the 
extension cache-refresh for example. It might use SOA version number, which I 
think common authoritative servers use to to mark zone version somehow. But 
almost any binary id would be sufficient. The server may provide any 
alternative like timestamp. For a client, it does not matter. It would just 
store whatever the server used on last reply.


In addition to what Ray pointed out, the SOA serial might not only be an 
unreliable piece of data for synthesized zones, but also in multi-provider 
setups etc. Freshness-checking on the zone level might not be a stable concept.

A hash over the RRset in question might work, assuming some canonical form is 
used (e.g. as used for RRSIG calculation). OTOH, that would limit efficiency 
benefits to the specific (qname,type) and not allow freshness checking for the 
rest of the zone. It's unclear whether the implementation complexity is worth 
the benefit if it can only be exercised on some responses.

Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-cds-consistency-03.txt

2023-08-01 Thread Peter Thomassen


Dear DNSOP,

At the San Francisco meeting, I mentioned two outstanding issues with this 
draft. I've addressed them in this revision.

Changes:

  * Editorial changes
  * Describe consistency requirements for CSYNC soaminimum
  * Clarify that CSYNC updates should not break delegations

Any feedback / review / implementation update is welcome. -- I'll next gather 
some feedback from parents implementing RFC 7344.

Peter


On 8/1/23 18:10, internet-dra...@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the Domain Name System
Operations (DNSOP) WG of the IETF.

Title   : Consistency for CDS/CDNSKEY and CSYNC is Mandatory
Author  : Peter Thomassen
Filename: draft-ietf-dnsop-cds-consistency-03.txt
Pages   : 12
Date: 2023-08-01

Abstract:
Maintenance of DNS delegations requires occasional changes of the DS
and NS record sets on the parent side of the delegation.  RFC 7344
automates this for DS records by having the child publish CDS and/or
CDNSKEY records which hold the prospective DS parameters.  Similarly,
RFC 7477 specifies CSYNC records to indicate a desired update of the
delegation's NS (and glue) records.  Parent-side entities (e.g.
Registries, Registrars) typically discover these records by querying
them from the child, and then use them to update the delegation's DS
RRset accordingly.

This document specifies that when performing such queries, parent-
side entities MUST ensure that updates triggered via CDS/CDNSKEY and
CSYNC records are consistent across the child's authoritative
nameservers, before taking any action based on these records.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-cds-consistency/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-dnsop-cds-consistency-03.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-cds-consistency-03

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--
Like our community service? 
Please consider donating at

https://desec.io/

deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-zoneversion-03.txt

2023-07-31 Thread Peter Thomassen


Thank you; I think the changes look good. Just one nit: "COULD" is not an RFC 
2119 key word.

Also, I like the new expansion of the SOA record in the abstract ("Star Of 
Authority") ;-)

Best,
Peter

On 7/31/23 03:24, Hugo Salgado wrote:

Dear Group.
Here's the last version of Zoneversion draft.
The most important change is to add a new field "number of labels", to
disambiguate the name of the zone that the serial refers to. With this
we believe that the comments of a few months ago by Joe and Brian are
resolved. Thanks for the feedback.

There are also text improvements and expansion of some abbreviations,
according to DNS directorate feedback. Regarding a comment in IETF-LC
that this document should update 1035 and/or 6891, we also understand
that this is not the case and we'll talk with the commenter to see if
any clarification is necessary in the text.

The unofficial NSD implementation was updated with the latest changes,
with its live server, and we'll be updating the rest of the libraries
and clients in these weeks.

Thanks and regards,

Hugo

On 18:09 30/07, internet-dra...@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the Domain Name System
Operations (DNSOP) WG of the IETF.

Title   : The "ZONEVERSION" EDNS option for the version token of a 
Resource Record's zone
Authors : Hugo Salgado
  Mauricio Vergara Ereche
Filename: draft-ietf-dnsop-zoneversion-03.txt
Pages   : 11
Date: 2023-07-30

Abstract:
The "ZONEVERSION" EDNS option allows a DNS querier to request a DNS
authoritative server to add an EDNS option in the answer of such
query with a token field representing the version of the zone which
contains the answered Resource Record, such as the Star Of Authority
("SOA") serial field in zones when this number corresponds to the
zone version.

This "ZONEVERSION" data allows to debug and diagnose problems by
helping to recognize the data source of an answer in an atomic single
query, by associating the response with a respective zone version.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-zoneversion/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-dnsop-zoneversion-03.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-zoneversion-03

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--
Like our community service? 
Please consider donating at

https://desec.io/

deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] should all ccTLD be on the Public Suffix list?

2023-07-19 Thread Peter Thomassen





On 7/19/23 02:42, George Michaelson wrote:

So, given it exists, systems
are coded to behave against it, and not having SOME ccTLD (and I would
posit gTLD) on it, means they don't match as "first class citizens"
the behaviour the PSL brings.

Actually, the PSL matching algorithm is such that all TLDs are considered 
public suffixes:

| Match domain against all rules and take note of the matching ones.
| If no rules match, the prevailing rule is "*".
https://github.com/publicsuffix/list/wiki/Format#algorithm

Thus, absent a negative rule that would declare a TLD a private suffix, the 
algorithm labels TLD suffixes public.

However, there are no top-level exemptions defined:

$ grep '^!' public_suffix_list.dat
!www.ck
!city.kawasaki.jp
!city.kitakyushu.jp
!city.kobe.jp
!city.nagoya.jp
!city.sapporo.jp
!city.sendai.jp
!city.yokohama.jp

Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Secdir early review of draft-ietf-dnsop-dnssec-bootstrapping-05

2023-07-17 Thread Peter Thomassen


Linda,

On 7/18/23 01:58, Linda Dunbar wrote:

Thanks for the reply. It is very helpful to better understand the draft.
See my suggestions below:

[...]

[Linda] It would be very helpful if you can include those examples in the draft because 
the information is not really "arbitrary".


It's difficult to mention the specific examples of my earlier email in the 
draft, because those documents are not yet standards documents (just I-Ds).

However, I added a more generic perspective on other use cases, including a 
hypothetical example.


[Linda] Your description is very helpful. Can you it to the draft? Thank you.


I added a paragraph in the opening of Section 3 (which introduces the 
bootstrapping protocol) to clarify that this method is not intended to be used 
for rollovers, just for bootstrapping.

The changes are here: 
https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/pull/10/files#diff-356ec8c295379536ae015166d01de308455cded000afc5476019b3effbb2ae43

Please let me know if these address your concerns!

Thanks,
Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Secdir early review of draft-ietf-dnsop-dnssec-bootstrapping-05

2023-07-17 Thread Peter Thomassen

Hi Linda,

Thank you very much for your review! Comments below.

On 7/17/23 22:32, Linda Dunbar via Datatracker wrote:

Here are some minor issues with the draft:
- What kind of "arbitrary information about the zones"? any examples?

I'm not sure if the objective of your question is to have such examples here on
the list, or to have additional text included in the draft. I'll give some
answers here; if any of it should be included in the text, please let me know.

In general, ._signal. is the "home" for whatever
the DNS operator wants to securely publish about the child, with the information living within a
signed zone under the operator's control (e.g. nameserver zone), and not in the customer's zone.

This signaling mechanism is specified in general terms (Section 2),
independently of its applications. The use case is then determined by the
prefix and the record type.

In the case of DNSSEC bootstrapping (specified in Section 3), the prefix
"_dsboot" is used together with CDS/CDNSKEY-type records.

Currently, no other use cases are defined, but future use cases can simply
reference the signaling mechanism from Section 2 if they use it.

One potential such use case is the key exchange that DNS providers need to perform
between each other when multiple DNS providers sign and serve the same zone
("multi-signer key exchange", see
https://datatracker.ietf.org/doc/draft-thomassen-dnsop-mske/).

Another one is the discovery of NOTIFY targets for generalized notifications,
https://mailarchive.ietf.org/arch/msg/dnsop/J9Ib8BhTHIwJByIA32O6i_jqDLY/ In the context discussed
there, the parent would use the mechanism to announce who is the child's registrar. For the domain
"example.org", this could be done at "_notify.example._signal.org" or similar.

- Section 3.2 (Page 6). The first step is not intuitive. does it mean nothing
needs to be performed if the child is "securely delegated"? How does the
"securely delegated" child publish information?

The protocol enables bootstrapping of secure delegations, that is, it allows
the parent to validate the child's CDS or CDNSKEY records at a time where the
child does not have a DNSSEC chain of trust yet.

When the child is already securely delegated, bootstrapping is no longer
necessary. To update the delegation's DS records, the parent can then simply
use the child's CDS/CDNSKEY records directly, as they will be accompanied by
signatures that can be validated using the already established chain of trust
(RFC 7344).

So, yes, if the child is securely delegated, nothing needs to be performed
because the delegation does not need bootstrapping anymore. -- If the operator
wants to publish information about the child in a signaling zone, that's still
possible, of course (see other use cases above). However, that doesn't concern
the steps described in Section 3.2, as those only relate to how the parent can
perform bootstrapping for the child domain.

If you have further questions, please let me know.

Thanks,
Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-cds-consistency-02.txt

2023-07-10 Thread Peter Thomassen


Hi,

In preparation for the SFO meeting, this is to address the feedback that was 
still open.

Changes:
- Retry before assuming a nameserver is permanently unreachable

Thanks,
Peter


On 7/10/23 22:24, internet-dra...@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the Domain Name System
Operations (DNSOP) WG of the IETF.

Title   : Consistency for CDS/CDNSKEY and CSYNC is Mandatory
Author  : Peter Thomassen
Filename: draft-ietf-dnsop-cds-consistency-02.txt
Pages   : 11
Date: 2023-07-10

Abstract:
Maintenance of DNS delegations requires occasional changes of the DS
and NS record sets on the parent side of the delegation.  RFC 7344
automates this for DS records by having the child publish CDS and/or
CDNSKEY records which hold the prospective DS parameters.  Similarly,
RFC 7477 specifies CSYNC records to indicate a desired update of the
delegation's NS (and glue) records.  Parent-side entities (e.g.
Registries, Registrars) typically discover these records by querying
them from the child, and then use them to update the delegation's DS
RRset accordingly.

This document specifies that when performing such queries, parent-
side entities MUST ensure that updates triggered via CDS/CDNSKEY and
CSYNC records are consistent across the child's authoritative
nameservers, before taking any action based on these records.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-cds-consistency/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-dnsop-cds-consistency-02.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-cds-consistency-02

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--
Like our community service? 
Please consider donating at

https://desec.io/

deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-bootstrapping-05.txt

2023-07-10 Thread Peter Thomassen


Hi all,

This revision only contains editorial changes from Scott's dnsdir review (plus 
an unclear sentence that I found and fixed).

Thanks,
Peter


On 7/10/23 22:05, internet-dra...@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the Domain Name System
Operations (DNSOP) WG of the IETF.

Title   : Automatic DNSSEC Bootstrapping using Authenticated 
Signals from the Zone's Operator
Authors : Peter Thomassen
  Nils Wisiol
Filename: draft-ietf-dnsop-dnssec-bootstrapping-05.txt
Pages   : 16
Date: 2023-07-10

Abstract:
This document introduces an in-band method for DNS operators to
publish arbitrary information about the zones they are authoritative
for, in an authenticated fashion and on a per-zone basis.  The
mechanism allows managed DNS operators to securely announce DNSSEC
key parameters for zones under their management, including for zones
that are not currently securely delegated.

Whenever DS records are absent for a zone's delegation, this signal
enables the parent's registry or registrar to cryptographically
validate the CDS/CDNSKEY records found at the child's apex.  The
parent can then provision DS records for the delegation without
resorting to out-of-band validation or weaker types of cross-checks
such as "Accept after Delay" ([RFC8078]).

This document deprecates the DS enrollment methods described in
Section 3 of [RFC8078] in favor of Section 3 of this document.

[ Ed note: This document is being collaborated on at
https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/
(https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/).
The authors gratefully accept pull requests. ]

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-dnsop-dnssec-bootstrapping-05.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-dnssec-bootstrapping-05

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--
Like our community service? 
Please consider donating at

https://desec.io/

deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Dnsdir early review of draft-ietf-dnsop-dnssec-bootstrapping-04

2023-07-10 Thread Peter Thomassen


Hi Scott,

On 7/5/23 21:59, Rose, Scott W. (Fed) wrote:

Coming up with this terminology was really challenging. The reason that the 
Signaling Name is only the prefix, without the Signaling Domain, is that it 
makes the rest of the spec easier. For example, from Section 3.1:

To [...]
authenticate the Child's CDS/CDNSKEY RRsets, the Child DNS Operator
MUST co-publish them at the corresponding Signaling Name under each
out-of-bailiwick Signaling Domain [...]

With your definition, one would have to say

To [...]
authenticate the Child's CDS/CDNSKEY RRsets, the Child DNS Operator
MUST co-publish them at each corresponding out-of-bailiwick Signaling
Name [...]

Do you feel that's an improvement?



I honestly don’t have a good solution so maybe the original wording is best.

I was thinking maybe changing it to “Signaling Name Prefix” but that isn’t an 
improvement either.

I would be fine in leaving the text as-is since there doesn’t seem to be a 
better wording that is apparent. The rest of the doc is clear as to how the 
name is formed and used and that is the important part.

I am fine with the other changes. I can update the review to “Ready” to 
finalize things for this version.

In case some better way of resolving the above occurs to you, please let me 
know.

For now, I've posted the revision (-05) that includes your feedback. Thank you 
very much!

Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: Consistency for CDS/CDNSKEY and CSYNC is Mandatory

2023-07-05 Thread Peter Thomassen

Hi Libor,

On 6/26/23 13:56, libor.peltan wrote:

My concerns are based on following situation. Imagine that:

- two servers publish inconsistent CDNSKEY+CDS records for some reason, e.g.
misconfiguration. This is the exact thing that the draft tries to address.

- this persists for quite some time, which is highly probable, as DNS is
usually a slowly-changing environment.

- the parent queries both servers and detects the inconsistency. So it does
nothing and tries later. It is the same. It tries again, but still the same.

- it tries once more and it happens that some stumble on the network causes
that one of the queries/responses/connections times out and one of the
CDNSKEY+CDS scans fails.

- the parent concludes that one of the servers in unreachable and the other
one is consistent with itself, accepting his CDNSKEY+CDS. This is the very
thing that your draft is trying to defend against, but fails in this case.

I would think about defining some form of "permanent unreachability" and ignore
the servers only in that case. Everything would become much more complicated, but I think
it is the right thing to do. And if not, it should be argumented that the risk is
reasonably acceptable.

That's a fair point that I had not appreciated -- thank you for raising it!
Viktor told me off list that it is also in line with his thoughts on
reachability (he had commented on related aspects earlier, so I reached out).

So, how about replacing the second paragraph of Section 2 with the following:

OLD:
In all cases, consistency is REQUIRED across received responses only.
Nameservers that appear to be unavailable SHOULD be disregarded as if
they were not part of the NS record set.

NEW:
In all cases, consistency is REQUIRED across received responses only.
When a response cannot be obtained from a given nameserver, the
Parental Agent SHOULD attempt obtaining it at a later time, before
concluding that the nameserver is permanently unreachable and
removing it from further consideration. A retry schedule with
exponential back-off is RECOMMENDED.

This leaves the duration of the retry period to the operator. I'm fine with
specifying something (it may actually help interoperability across TLDs), I'm
just not sure what's a good value. Three days?

I labeled the retry mechanism "SHOULD", not "MUST", because even without this mechanism,
the consistency requirements provide *some* protection. Do we want to say that
"better-than-nothing" implementations that don't keep this state are in violation of the spec?

It would be great if someone who has a CDS scanner could comment.

Thanks,
Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Dnsdir early review of draft-ietf-dnsop-dnssec-bootstrapping-04

2023-07-04 Thread Peter Thomassen

Hi Scott,

Thank you very much for your feedback -- responses inline.

You can find the changes here (will submit to datatracker before the upcoming
cut-off):
https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/commit/dcb914737342184c503fbb23fc37c7d3b6e363d1#diff-356ec8c295379536ae015166d01de308455cded000afc5476019b3effbb2ae43

On 6/27/23 19:33, Scott Rose via Datatracker wrote:

Reviewer: Scott Rose
Review result: Ready with Issues

Review of dnssec-bootstrapping

The draft is likely OK to proceed as there are only a few nits that do not
change the overall contents. I am confused about if it adds to methods in RFC
8078 or replaces methods in RFC 8078.

1. Abstract:
The Abstract says that this draft deprecates the DS enrollment methods in RFC
8078, which implies this draft will replace that text. However the Security
Considerations section implies that this draft only adds a new method and
removes none of the existing ones (possible just phrasing issue?). If this
draft intends to only add a new secure method, the abstract could be changed to
say “This document adds the new DS enrollment method to the list of methods
described in Section 3 of [RFC8078].” If this is to replace the CDS/CDNSKEY
based methods in RFC 8078, then perhaps the first sentence in the Security
Considerations section should be updated to say

“This draft document replaces the methods described in RFC 8078 Section 3 with
a method that adds authentication. Its security level is therefore…” To make
it explicit that this draft replaces that section rather than just add another
method while retaining the methods previously described in RFC 8078.

The abstract is correct.

The confusing sentence in the Security Considerations was supposed to be about the
security model (not about the set of methods), where all existing security properties
(e.g. CDS validation) remain in place (= removes nothing), but authentication is
"added".

I agree this was phrased in a confusing way, and I made changes along the lines
you proposed.

That is the only potentially confusing issue. The rest are nits:

2. Section 1.1 Terminology: “Parent” and “Child” are defined the same way in
the most recent version of the DNS Terminology RFC 8499, so a reference could
be used instead of repeating the definition.

Done. (I thought it would be nice to "inline" the actual definition, but that
was just a feeling.)

Also, “Signaling Name” sounds
confusing compared to the Signaling Domain. Would it be easier to write it as:

“Signaling Name The owner name of comprised of a prefix, the Child zone name
and the Signaling domain name. Used by the Parental Agent to identify and
retrieve the Signaling Type used by the Child zone (See Section 2.2). “

To stress it is a name in the Signaling Domain, but contains the child zone
name.

Coming up with this terminology was really challenging. The reason that the
Signaling Name is only the prefix, without the Signaling Domain, is that it
makes the rest of the spec easier. For example, from Section 3.1:

To [...]
authenticate the Child's CDS/CDNSKEY RRsets, the Child DNS Operator
MUST co-publish them at the corresponding Signaling Name under each
out-of-bailiwick Signaling Domain [...]

With your definition, one would have to say

To [...]
authenticate the Child's CDS/CDNSKEY RRsets, the Child DNS Operator
MUST co-publish them at each corresponding out-of-bailiwick Signaling
Name [...]

Do you feel that's an improvement?

I appreciate that "Signaling Name" is not ideal. Perhaps instead of making this term the
FQDN including the full domain, we should rename "Signaling Name" to something else.

Unfortunately, "Signaling Prefix" runs the risk of being mistaken for the "Signaling
Type" (which is really a prefix, it's the first label).

Taking all this into account, do you have any more suggestions?

3. Section 2.1
Strictly speaking, would the Signaling Zone really need a secure delegation? I
could even be an island but the Parental Agent has the Signaling Zone’s SEP key
(KSK or ZSK) as an installed trust anchor. If the Parental Agent really only
needs to be able to validate RRSIGs in the Signaling Zone, the zone doesn’t
necessarily need to have a secure delegation, as it is up to the Parental Agent
to validate signatures. Not saying that is easier (it has other problems), just
possible so the MUST may be unnecessarily strict.

Done

4. Section 4.2 Parental Agent:
Last sentence in paragraph ends “…the cache does not need to get cleared in
between.)”. Might be expanded to “…cache does not need be be cleared in
between queries to unique Child Zone names.)” for clarity.

Done (along those lines).

Thanks,
Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] With multi-algo DS, what to do if an RRSIG is missing?

2023-07-03 Thread Peter Thomassen

Dear DNSOP,

It's well-known that DNSSEC multi-signer setups are problematic when providers
want to sign with different algorithms.

In a hypothetical scenario where signing requirements would be relaxed, I have
a very specific question about how resolvers should behave. Apologies for the
length of the message, and thank you for reading it.

To lay out the problem fully, here's an appetizer from the spec. RFC 6840
Section 5.11 says (emphasizing a point from RFC 4035 Section 2.2):

A signed zone MUST include a DNSKEY for each algorithm present in
the zone's DS RRset and expected trust anchors for the zone. The
zone MUST also be signed with each algorithm (though not each key)
present in the DNSKEY RRset. [...]

This requirement applies to servers, not validators. Validators
SHOULD accept any single valid path. They SHOULD NOT insist that all
algorithms signaled in the DS RRset work, [...]

The second rule is not contentious. It basically says that validators SHOULD NOT apply a
"logical AND" on algorithms offered by the DS record set; instead, "logical OR"
is encouraged. There was an issue with this in Unbound, but that's been solved ages ago. (Well,*
...)

However, the first rule is incompatible with certain use cases. In particular,
it is not possible to have the same zone served by several operators, each
signing with their own key and choice of algorithm.

A special case of this is the glitch-free transfer of a domain name from one
DNS provider to another, while retaining DNSSEC validation. During the
transition, a multi-signer phase will be in effect, and if the old and new
provider don't support overlapping sets of algorithms, you'll run into the
aforementioned problem.

For the sake of argument, let's replace the first rule by something like:

Independent of the number of signing algorithms appearing in it, the
DS RRset MUST reference at least one DNSKEY that signs theDNSKEY
RRset. Other RRsets MUST be signed with at least one DNSKEY whose
algorithm appears in the DS RRset.

More casually, "it's sufficient to sign with one algorithm from DS, as long as it
allows for authenticating along some valid path".

(Note that from the resolver perspective, this is compatible with rule 2, as
long as all announced algorithms are supported.)

Next, consider that Red Hat turned off SHA-1-based signing algorithms in Red
Hat Enterprise Linux 9 and related distributions. As this is a system-wide
policy, it affects validation of DNSSEC algorithms 5 and 7 in resolvers. In
response, Unbound [1], Knot Resolver [2] and PowerDNS Recursor [3] all have
implemented ways to detect whether these algorithms work, and disable them if
not supported.

That works great for zones that use algorithm 5 or 7 *only*: corresponding DS
records will be dropped from consideration, and as nothing is left, the zone is
treated as insure.

Now, assume a multi-signer setup of, say, algorithms 7 and 13. This is not an
uncommon transition (ietf.org did it last month, except that they went
unsigned). In such a scenario, a resolver on Red Hat would only consider the
algo 13 DS records.

Under the relaxed RRSIG presence rule, it would be fine to serve signatures of
*one* algorithm only (either 7 or 13). If only 7 is served, my understanding is
that this would lead to SERVFAIL, because signatures are missing for the only
supported algorithm. There is no valid path.

This situation looks exactly like a double-algorithm setup where an on-wire
attacker stripped RRSIGs for algorithm 13 so they can mess with the response
(knowing that 7 is not going to get validated). -- This removes all of the
DNSSEC security guarantees, despite of algorithm 13 being advertised in the DS
RRset.

Here are the questions:

1.) Is SERVFAIL the correct behavior in the above scenario?

2.) Does anyone think that "insecure" is the right behavior? ("I can see another
signature of algorithm 7 which I can't validate; it might match, so I'll pass this.")

3.) If anyone thinks that "insecure" is fine: Why should the resolver assume
that things are fine, and that the lack of signature is not an indication of a
downgrade-to-insecure attack?

4.) In fact, how would the resolver distinguish this from a
downgrade-to-insecure attack?

5.) If the authoritative server can't know what the resolver supports, how
could it ever be safe, by not sending RRSIGs for all algorithms, to introduce
the confusion of question (4)?

It is sometimes noted that Rule 1 above (signer requirement) and Rule 2
(validator requirement) are contradictory. I'd like to point out that the
questions raised here have nothing to do with rule 2: Validators should accept
*any* valid path. This rule stands regardless of whether any signatures missing
or not.

The issue is whether there's a supported path, and a safe response when a valid
path is lacking although one could expect one based on DS. This is not about

Re: [DNSOP] Review of draft-ietf-dnsop-dnssec-validator-requirements-06

2023-07-03 Thread Peter Thomassen




On 6/30/23 22:15, Paul Wouters wrote:

Section 13:

[...]

 an attacker being able to provide a rogue trust anchor is potentially

This is not a very realistic attack.


The same section says:

   On the other hand,
   mishandling Trust Anchor is likely resulting in a validator unable to
   validate most of the traffic under the TA.

I don't think this argument is particularly relevant, as an attacker with write 
access to the trust anchors would likely not replace any existing legitimate 
ones, but rather add the rogue one so that compromised traffic can be injected 
without causing validation errors otherwise.


I don't think this document contains much valuable content for a DNSSEC
operator. I think this document needs to have resolver vendors with
their customer support experiences involved in evolving this document.

Noting that only one of the people supporting adoption back in 2020 and 
offering reviews have contributed such reviews in the last three years (if I 
looked correctly), and considering that most feedback in the last 12 months has 
been in opposition to many of the recommendations given in the document 
(including several times due to serious inaccuracies about how DNSSEC works), 
I'm wondering if it is still on track.

The draft was born almost 10 years ago and adopted more than three years ago; 
still, as Paul said, it's not clear that it contains much valuable content for 
a DNSSEC resolver operator. Perhaps the WG should consider abandoning it 
(although I'm not sure about the process).

Best,
Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-cds-consistency-01.txt

2023-06-26 Thread Peter Thomassen


Dear DNSOP,

This revision of the draft addresses comments received by Wes, Libor, and Tim 
(changelog below).

I'm inviting the WG to take another read of the document and share your 
concerns.

In particular, please re-raise any concerns you might have voiced at a recent 
IETF meeting. Tim has listed some of those (at the bottom of [1]), but I'm not 
sure which of those are still current or considered settled by those who raised 
them.

To make sure everything is discussed with "mail trail", please speak up. Thanks!

[1]: https://mailarchive.ietf.org/arch/msg/dnsop/pocl2z9HwySssCzEyFudg7qm7_E/
[2]: https://mailarchive.ietf.org/arch/msg/dnsop/0eZKEQDzMnkeIDV0qkgY_xT_Kmc/

Changelog:
- Moved Failure Scenarios to appendix
- New failure scenario: DS Breakage due to Replication Lag
- Point out zero overhead if nothing changed, and need to retain manual 
out-of-band interface
- Editorial changes
- Make nits tool happy

There's outstanding editorial feedback from Libor [2] which I'll address later 
this week.

Thanks,
Peter


On 6/26/23 09:43, internet-dra...@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the Domain Name System
Operations (DNSOP) WG of the IETF.

Title   : Consistency for CDS/CDNSKEY and CSYNC is Mandatory
Author      : Peter Thomassen
Filename: draft-ietf-dnsop-cds-consistency-01.txt
Pages   : 11
Date: 2023-06-26

Abstract:
Maintenance of DNS delegations requires occasional changes of the DS
and NS record sets on the parent side of the delegation.  RFC 7344
automates this for DS records by having the child publish CDS and/or
CDNSKEY records which hold the prospective DS parameters.  Similarly,
RFC 7477 specifies CSYNC records to indicate a desired update of the
delegation's NS (and glue) records.  Parent-side entities (e.g.
Registries, Registrars) typically discover these records by querying
them from the child, and then use them to update the delegation's DS
RRset accordingly.

This document specifies that when performing such queries, parent-
side entities MUST ensure that updates triggered via CDS/CDNSKEY and
CSYNC records are consistent across the child's authoritative
nameservers, before taking any action based on these records.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-cds-consistency/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-dnsop-cds-consistency-01.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-cds-consistency-01

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--
Like our community service? 
Please consider donating at

https://desec.io/

deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: Consistency for CDS/CDNSKEY and CSYNC is Mandatory

2023-06-23 Thread Peter Thomassen


Hi Libor,

On 6/23/23 17:21, libor.peltan wrote:

I would expect the combination of a nameserver not being reachable and the 
other party being malicious to be quite a rare event.

A combination of a nameserver being unreachable and an other one being 
misconfigured e.g. in the sense of Section 2.2.1 (in the -03 version of the 
doc) does not seem too inprobable to me.


My take is that the likelihoods multiply, so the combination is much more 
unlikely than an isolated event of either type.

That said, it's possible I'm mis-estimating the severity of such a situation, 
like an operator not only serving compromised content (e.g. server hack, 
expired hostname hijack), but in addition blocking traffic to another operator.

I guess if you have this combination, you're out of luck: Multi-homing protects 
against failure of an operator, and indeed the draft is intended to protect 
against accidental mess-ups by multi-singer peers (as reported by Matthijs) or 
server takeover. OTOH, it cannot protect against an omnipresent on-the-wire DoS 
attacker (in fact, nothing can) who colludes with a DNS operator.

But risk assessments may vary, and if people think this needs to be addressed, 
I'm happy to (suggestions welcome!).


Given the probably much more frequent "price" of blocking DS maintenance, I 
think this is the right trade-off.

If you think this is the right trade-off, you should write into the document 
that this is the right trade-off, and that this consideration has been made. I 
would kindly leave the exact wording on you.


I'll wait for a few days to see if there are more comments, and will then try 
to find some words.


I'm not sure. Anyway, the Security Considerations section also claims "ensuring that 
an operator in a multi-homing setup cannot unilaterally modify the delegation", 
which is not entirely true according to me, considering the above discussion. If one 
nameserver becomes (even temporarily!) unreachable, the inability of unilateral 
modification is not ensured. It's only trade-off-ed :)


Point taken! I'll fix that accordingly.


Also, I addressed all other comments received so far in response to the 
adoption call (commits in same repo). For convenience, see the editor's copy: 
https://peterthomassen.github.io/draft-ietf-dnsop-cds-consistency/

Ouch, it seems that in your newest version, Section 2 disappeared completely. 
I'd vote for keeping the motivational prose present. Disclosing the motivations 
and goals of a standard is a good habit among RFCs.


Oh yeah, I agree. It's just that the section got longer and longer, and I felt 
like it takes forever until the reader arrives at the actual spec -- so I 
turned that section into an appendix.

Cheers,
Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: Consistency for CDS/CDNSKEY and CSYNC is Mandatory

2023-06-22 Thread Peter Thomassen

Hi Libor, all,

On 6/22/23 11:42, libor.peltan wrote:

here are my comments to draft-thomassen-dnsop-cds-consistency-03.

Thank you very much!

"In all cases, consistency is REQUIRED across received responses only. Nameservers
that appear to be unavailable SHOULD be disregarded as if they were not part of the NS
record set."

I don't feel confident about the consequences of this cathegorical statement.
What if you have two DNSSEC providers, one has an outage (or just network
breakage between them and the polling entity), and the other one maliciously
takes over by publishing new CDNSKEYs? The polling entity might re-query
several times from different locations, but this is usually only performed when
bootstrapping the scure delegation, not when already established. And even if,
it's not clear if (when) this would be enough. I understand, on the other hand,
that relying on permanently disfunctional (or lame in any meaning of that word)
child NSs might be problematic. To sum this up, if this is an issue in the
proposed method, it should be fixed, and if it isn't, it should be more
verbosely described why. The document seems too brief in this regard.

The SHOULD statement was added based on a concern Viktor voiced at one of the
last IETF meetings, saying that if a nameserver is unreachable from the parent,
this would permanently block DS maintenance. (A well-taken point, I think.)

I would expect the combination of a nameserver not being reachable and the other party
being malicious to be quite a rare event. Given the probably much more frequent
"price" of blocking DS maintenance, I think this is the right trade-off.

Where would you suggest to put more words about that? (Right there, or in the
Security Considerations? Which words?)

"CDS/CDNSKEY records at the Child zone apex MUST be fetched ... with DNSSEC
validation enforced."

Isn't this sentence disabling secure delegation bootstrapping?

Yes, good catch! I addressed it in this commit:
https://github.com/peterthomassen/draft-ietf-dnsop-cds-consistency/commit/7939107aebb4e4963367e1d7fd831d14f98dab27#diff-d3398566f77572362e657e31e035a0effbe92148ba122be28de37a177732f318

Also, I addressed all other comments received so far in response to the
adoption call (commits in same repo). For convenience, see the editor's copy:
https://peterthomassen.github.io/draft-ietf-dnsop-cds-consistency/

Best,
Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: Consistency for CDS/CDNSKEY and CSYNC is Mandatory

2023-06-22 Thread Peter Thomassen





On 6/21/23 17:04, Peter Thomassen wrote:

The existing documents lack any words on where specifically to query for 
CDS/CDNSKEY, and also what to do in case of inconsistencies.


Section 3.1 says:

[...]

Does that clarify the issue?


To avoid leaving this "hanging open": After an off-list chat with Matthijs, I 
realize I had misread the above, and there is actually no question -- his point was just 
that existing documents (current RFCs) lack certain guidance which the draft now 
clarifies.

Peter

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: Consistency for CDS/CDNSKEY and CSYNC is Mandatory

2023-06-21 Thread Peter Thomassen


Hi Matthijs,

On 6/20/23 07:30, Matthijs Mekking wrote:

 From the draft:

    For example, a single provider may (accidentally or
    maliciously) cause another provider's trust anchors and/or
    nameservers to be removed from the delegation.

This is exactly what happened in my test environment


Interesting to hear that it is not a hypothetical problem!


The existing documents lack any words on where specifically to query for 
CDS/CDNSKEY, and also what to do in case of inconsistencies.


Section 3.1 says:
   To retrieve a Child's CDS/CDNSKEY RRset for DNSSEC delegation trust
   maintenance, the Parental Agent, knowing both the Child zone name and
   its NS hostnames, MUST ascertain that queries are made against all of
   the nameservers listed in the Child's delegation from the Parent

That is: once from each NS hostname, but not necessarily from all IP addresses 
(we can discuss that), and even less from all Anycast instances (there's no way 
to do that).

Does that clarify the issue?

Thanks,
Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Generalized DNS Notifications (draft-thomassen-dnsop-generalized-dns-notify-01)

2023-06-21 Thread Peter Thomassen


Hi John,

On 6/20/23 20:27, John Levine wrote:

It appears that Peter Thomassen   said:

My take is that the parent should create a _signal subdomain (preferably as a 
delegation). The per-child target can be queried by prepending, e.g.

   _notify.example._signal.parent.  IN NOTIFY  CDS scheme port 
scanner.registrar.example.

This way, the parent can announce the registrar's NOTIFY endpoint. This can be 
synthesized dynamically, no need to maintain a large zone.
As _signal can be delegated, only one (rather normal) NS RRset is required in 
the parent, and the magic can be done on a different
nameserver.


While I can see how that might work in principle, I find it hard to
imagine registries and registrars making it work. At the least it'd
need new EPP stuff to tell the registry what signal records to add or
delete.


Do you mean that there needs to be a way for registrars to tell a registry what 
their NOTIFY listening endpoint is?

EPP, to my knowledge, is for management of domain registrations, while that 
endpoint is a global property of the registrar's account with the registry. It 
need not necessarily be conveyed via EPP: one could use whatever other channel 
is available for account changes. I guess there would usually be a web portal 
for filling in details like your EPP client net ranges, billing details, tax 
number etc.

It would be really interesting to hear from a registry. I'll reach out to some 
and try to figure out what they think.


I guess if the targets are fairly static, then putting it in the configuration 
rather than sticking it in the DNS will be good enough.


How would a random DNS operator know the registrar of their customer zones? How 
would they learn when it changes?


They'd ask the customer "who's your registrar" when they set up the
zone.


Ah, but then that's not what we're trying to do, which is improving CDS 
processing. So far, it's done via CDS scanning which does not involve the 
registrant but is automatic (that's already in the title of RFC 7344).

Unfortunately, the timing of the scanning queries does not align well with when 
a CDS change is actually happening. The NOTIFY mechanism is trying to improve 
on that, but without turning the automated method back into one that requires 
manual steps by the customer.


If the customer changes registrars, they have to tell the DNS operator


I wouldn't bet that this wouldn't be forgotten except for < 10% of cases. 
Realistically, the DNS operator would have to ask again -- but how would they know 
when it would be good to ask? Perhaps the DNS operator could ask daily *scnr*

Cheers,
Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNSOPCall for Adoption: Consistency for CDS/CDNSKEY and CSYNC is Mandatory

2023-06-20 Thread Peter Thomassen


Hi Wes,

On 6/9/23 19:43, Wes Hardaker wrote:

For lame delegations, I think discussion is needed further.  It's
unclear from the draft at the moment (and I think it needs to be very
clear) about what to do with servers that are lame.  It discusses
whether or not CDS/CDNSKEY/CSYNC are supposed to do when the server is
unresponsive, but not with respect to other errors or situations and I
think some clarity would be helpful here.

I think it's important that we deal with the multi-signer case, and that
point is very clear (and correct).  But we also do need to be able, as a
child, to update a parent's records when a nameserver has gone offline
or stopped responding appropriately.  This is very different than one NS
taking over -- IE, I agree that this is the principle thing to defend
against.  But we also need to be able to efficiently recover from
operational situations.


Nameservers that went offline are taken care of because the mechanism only 
requires that the received responses are consistent (not that responses are 
received from all nameservers).

Lame delegations and otherwise inappropriately responding nameservers are indeed 
problematic, and I'm looking forward to explore more. However, my current gut feeling is 
that such kinds of mess-ups cannot sufficiently reliably be detected and dealt with 
automatically. For example, you cannot reliably detect the cause of REFUSED (including 
"expired from nameserver" during provider change, or on-wire manipulation 
suppressing a conflicting response, or whatever else).

As such, I'd think that the goal of the document should be automation of the 
"proper" case, with broken cases continuing to require manual intervention.


Nits as long as I was reading it with a red pen:

- Introduction: CSYNC updates both NS *and glue* records


Section 3.2 mentions "data records" and lists NS as an example -- but yes, that 
could be more clear. I'll make a note.


- Lame delegations: "on the other hand, if the delegation is not
   protected by DNSSEC," -- I don't understand this because all three
   record types require DNSSEC to be in place and valid for any of the
   records to work.  No changes should ever be permitted without both
   present and valid signatures.  Maybe I'm misunderstanding the
   paragraph though.


RFC 8078 Section 3.3 allows turning on DNSSEC without a pre-existing chain of 
trust.

An attacker how hijacked on the nameserver hostnames (after its domain expired) 
can exploit this mechanism. The delay prescribed there doesn't help in the 
situation at hand. If consistency across NS is not checked, you'll just have to 
wait long enough until the parent hits the attacker's nameserver several days 
in a row, and then DNSSEC is enabled.


- Section 3 is likely where service failure / error conditions need to
   be discussed more fully (IMHO).


Ack.


- 3.2 CSYNC: There are a few things to check here and all the servers
   should be consistent with all the records for changes to be made: the
   CSYNC record itself, the NS records and the glue records.  (or since
   CSYNC is generic: the CSYNC record and any records it is referring
   to).  IE, the CSYNC records could be equal but the NS records need to
   be checked for equivalence at each server too.


This is what the last paragraph of Section 3.2 is trying to say, but apparently 
it's not clear enough. I'll make a note.

Thanks for the feedback.

Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Multiple drafts discussing the use of DNS NOTIFY

2023-06-20 Thread Peter Thomassen


Hi Mark,

On 6/13/23 16:43, Mark Elkins wrote:

There are registries doing CDS scanning now, and registrars testing
it. I agree that the flow back to the registrar if the registry does
it is ugly so registrar is better where possible. We'll probably end
up with both since some registrars aren't up to it.

[...]


My thoughts on this as in how to decide who does what, is...

in EPP, there is a section that I've coded to look like...

The usual drop downs are Yes/No and may require a reason

Create a new action, "DS Managed by", give it three options
Y=the registrY should manage the CDS scanning (Polling whatever)
R=the registraR should manage...
N=Implicit management by the Registrar.

This would be a change / an extension to the EPP protocol, correct?

If so, there's probably not much DNSOP can do about it, but if I'm not 
mistaken, the REGEXT WG is chartered to address such things.

Best,
Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Generalized DNS Notifications (draft-thomassen-dnsop-generalized-dns-notify-01)

2023-06-20 Thread Peter Thomassen





On 6/20/23 17:48, Paul Wouters wrote:

I like this draft because of it tackles the issues of wasteful CDS
polling and it uses NOTIFY, a mechanism that is well known, already
exists in implementations, and actually feels like a good fit (as
opposed to overloading).


Agreed.


That's not what the TLDs said during "timers vs triggers". They did not
want NOTIFY's towards their production nameservers.


The draft does not propose that.


That might have
changed, but I would like to hear from the big TLDs that they are now
in favour of this and would deploy.


The drive is this time not coming from the parent side, but from discussions 
around DS automation at recent ICANN DNSSEC workshops, and DNSSEC multi-signer 
scenarios.

The main two arguments made there were scaling concerns for large parent zones 
(although I don't think these concerns are supported by data), and better 
predictability (for child-side entities) of when C* records can be expected to 
be discovered and processed.

It would indeed be interesting to learn what TLD registries have to say, 
specifically those who already have quite advanced CDS scanners (e.g. SWITCH, 
who also have implemented authenticated bootstrapping).


If not, perhaps a level of indirection via service record should be
used to point to a specific server (which could still accept NOTIFY)
outside of the parental NS RRset.


That's the point of the NOTIFY record (whose field list may be reduced, perhaps 
eventually to a CNAME, see other postings).


Also the registrars did not like being circumvented. While now some
registars might have changed their mind (or don't care since they
are both registrar and dns hosting for most of their domains), it
would be good to hear from them.


Agreed; there are various good arguments for why the scanning should be done by 
the registrar (if there is one). But I don't see why this would be a problem 
with regards to NOTIFY (we can make it work by prepending the child label to 
the service record qname).

Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Generalized DNS Notifications (draft-thomassen-dnsop-generalized-dns-notify-01)

2023-06-20 Thread Peter Thomassen




On 6/20/23 17:51, Paul Wouters wrote:

   parent.   IN NOTIFY CDS   scheme port scanner.parent.


Why a new RRtype ?
Why more stuff in the APEX?
Why not:

 _notify_cds.parent. IN CNAME targetservice.parent.
 targetservice.parent. IN A .
 targetservice.parent. IN  .


Personally, I'm fine with simplifying to your approach; I would only add the 
child label prefix to allow for per-child flexibility (and if you don't need 
that, just set a wildcard).

The authors' thinking was that a new record type would allow both specifying 
the port and a scheme field, anticipating that people might appreciate 
flexibility for future mechanisms and stir discussion about that. But if it's 
not needed -- the simpler the better!

Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Generalized DNS Notifications (draft-thomassen-dnsop-generalized-dns-notify-01)

2023-06-20 Thread Peter Thomassen


Hi,

On 6/20/23 17:37, Matthijs Mekking wrote:

A note on where to send CDS and CSYNC notifications. I sort of
understand why the NOTIFY record includes a RRtype field, but will
parental entities really have a different target for receiving notifies
for CDS and CSYNC?


I've talked to Peter at some length.  The problem is that you will often have
different targets for different children of the same parent, i.e., registrars
rather than registries, and I don't see any good way of putting per-child
info in the parent, particularly a large parent like .ORG or .COM.


If there are different targets for different children of the same parent, then 
a generic NOTIFY record like below won't work anyway.

     parent.   IN NOTIFY CDS   scheme port scanner.parent.


My take is that the parent should create a _signal subdomain (preferably as a 
delegation). The per-child target can be queried by prepending, e.g.

  _notify.example._signal.parent.  IN NOTIFY  CDS scheme port 
scanner.registrar.example.

This way, the parent can announce the registrar's NOTIFY endpoint. This can be 
synthesized dynamically, no need to maintain a large zone. As _signal can be 
delegated, only one (rather normal) NS RRset is required in the parent, and the 
magic can be done on a different nameserver.

Alternatively, the parent can deploy a static wildcard:

  *._signal.parent.  IN NOTIFY  CDS scheme scanner.parent.

That would be a very small, static zone. This applies when the parent does the 
scanning themself, or when they want to forward the NOTIFY to the registrar 
behind the scenes. (I'm not saying this should be done; I'm saying that this 
method is suitable for all kinds of scenarios.)


The existing NOTIFY for AXFR is perfectly usable without a mechanical
way to say where to send the notifications, so my proposal is to
continue not to have one. All of the existing AXFR NOTIFY receivers I
know have ACLs to only accept notifications from relevant primary
servers, often hidden ones not visible in the DNS, so even if the
proposal in 5.1 didn't have scaling problems, it only addresses half
the problem. So take it out.


I guess if the targets are fairly static, then putting it in the configuration 
rather than sticking it in the DNS will be good enough.


How would a random DNS operator know the registrar of their customer zones? How 
would they learn when it changes?

Cheers,
Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Current status of draft-ietf-dnsop-dnssec-validator-requirements

2023-06-15 Thread Peter Thomassen





On 6/15/23 15:32, Viktor Dukhovni wrote:

I agree that client-side validation would be ideal. One important
aspect here is to save on the latency caused by extra queries; my
impression is that this extra cost is generally considered
prohibitive.


Not sure what you mean by "generally" (is that the browser use case)?


Oh, yes, or in a smartphone app and things like that. Shouldn't have said 
"generally", though.


Experimental protocols for this have been published. Specifically, RFC
7901 and RFC 9102 come to mind.


These are not always needed.  A local resolver is a good option anywhere
where last-mile middleboxes don't MiTM and break access to DNSSEC.


Right, but where available, those mechanisms also don't hurt.

(If you already have such a library available because you run *some* 
latency-sensitive application, I don't see why one wouldn't also use it where 
not strictly needed; doing so saves you the overhead of running the local 
resolver.)


I'm not aware of any implementations of these protocols -- I think
having software support, perhaps experimental, in some of the common
software packages would be REALLY cool.


Some folks at NLNetLabs had implementations in progress IIRC.


Right, getdns returns the chain if requested: 
https://getdnsapi.net/documentation/spec/#31-extensions-for-dnssec -- If there 
are applications making use of this to perform the validation themselves, I'd 
be curious to know.

Best,
Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Current status of draft-ietf-dnsop-dnssec-validator-requirements

2023-06-14 Thread Peter Thomassen


Hi Christian,

On 6/14/23 11:55, Christian Huitema wrote:

In the old model, we are very concerned about third parties spoofing responses 
and polluting resolver caches. In a secure transport model, the only parties 
that can spoof responses are the resolvers themselves: authoritative resolvers 
abusing their authority to add falsehoods in additional sections, recursive 
resolvers abusing the client trust to send false responses.


I'm not sure what you mean by "authoritative resolver", but another attack 
vector definitely is to compromise a secondary nameserver and modify the zone content it 
serves.

That is still possible with encrypted transport, unless DNSSEC is used (and 
signing is not done on the same machine).


I do think that DNSSEC is still useful, even in a secure transport world. But the focus 
changes. For example, if we consider that "spoofing by recursive server" is a 
threat, then having the recursive set bits to affirm that the response is verified is not 
much of a protection -- the emphasis should move to verification by the client. I would 
love to see this discussed.


I agree that client-side validation would be ideal. One important aspect here 
is to save on the latency caused by extra queries; my impression is that this 
extra cost is generally considered prohibitive.

Experimental protocols for this have been published. Specifically, RFC 7901 and 
RFC 9102 come to mind.

I'm not aware of any implementations of these protocols -- I think having 
software support, perhaps experimental, in some of the common software packages 
would be REALLY cool.

Cheers,
Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-validator-requirements

2023-05-19 Thread Peter Thomassen


Hi Daniel,

On 5/18/23 02:26, Daniel Migault wrote:

On 5/17/23 22:01, Daniel Migault wrote:
 > I agree but as far as can see the cap of the TTL with a revalidation 
will only resync the resolver and the zone more often than could be expected 
otherwise but does not result in the cached RRsets differing from those provided 
by the zone.

These two things are not the responsibility of the resolver. It is 
precisely the task of the TTL to set the expectation for expiry and, when 
changes are made, for the convergence time to eventual consistency.

I agree but if a DRO can implement some mechanism that avoids the cache to 
remain incoherent,


No, it is almost a defining feature of the DNS that it only gives eventually 
consistent responses. The DNS is not a real-time database.


I think that is good - especially in a situation where many different zones are 
involved. Typically, the DRO remains the one serving responses and if one says: 
the cache does not reflect what I see on the authoritative side...


Some may find that unfortunate, but capping TTLs at the lowest value in the 
trust chain harms scalability.

In addition, when resolvers apply various ways of "fixing" the auth's TTls, 
behavior will end up differing across the Internet. That harms interoperability and makes 
debugging harder.


this is seen by many MNOs as an issue.


How can it be an issue if the zone operator declares that this is the TTL they 
want?

It's completely legit for an auth to set a TTL of (say) 1 day, at the cost of 
slow updates, but with the benefit of more resiliency against short period of 
auth unreachability. Why take that flexibility away from them?


Then, do we have an easy way to implement Viktor's revalidation ? TTL cap is at 
least a (costly) way to implement it.


That said, I still don't understand what it's needed for: it seems that 
it's just not necessary to do revalidation / refetches (= early expiry) after 
the minimum of TTL_RRset and all of the TTL_DNSKEY, TTL_DS in the chain; you 
can achieve the same output reliability by doing it when a change in the trust 
chain is detected and validation would otherwise fail.

Then I might be missing how this could be implemented. How do we check that the 
validation will fail? Does the resolver check the key tags for every response ?


There is no extra check. Imagine the following situation:

Day 1
- DS/DNSKEY TTL 1 hour, records fetched at 10:30am UTC
- MX TTL 24 hrs, record fetched at 10:30am UTC
- cache otherwise empty

Day 2
- DS/DNSKEY not currently in cache (expired 1 hour after the fetch on Day 1)
- MX TTL is still valid! (until 10:30am)

Imagine that some time in the morning of Day 2, the  record is queried, 
let's say at 06:00am UTC. The DS/DNSKEY records are have long expired from the 
cache (on Day 1), so they will also be re-fetched in order to validate the  
response.

If the DS and DNSKEY records turn out are the same as before, no problem. But 
let's say that the re-fetched the keys have changed completely since yesterday, 
for whatever reason. The resolver will then use the new key information to 
validate the  response.

And it is *now* that the resolver could say "oh, actually, I still have this MX 
record cached until 10:30am, but I know that the keys I used for its validation are no 
longer there". The resolver COULD then remove the MX record from the cache.

This is very different from applying the minimum of the various TTLs: when you 
do that, the MX record would already have expired on Day 1 at 11:10am.

I'm fine with resolvers doing that, but I'm not in favor of a general 
recommendation. It's primarily the zone maintainer's task to get their zone 
content in order.

Best,
Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

1 2 3 >

1 - 100 of 205 matches

Mail list logo