Re: [DNSOP] draft-dnsop-dnssec-extension-pkix

[Tim Wicinski <[e-mail]>]

All

The chairs want to thank Viktor and Mark for their comments, and
for Hyeonmin and Taekyoung for pulling their presentation for now.

I know sometimes folks have issues with some of the presentations we
accept, but our rules are "Current Work has priority, For Consideration is
first come, first serve."  Sometimes this may get us documents which may
confuse members of the working group, but we also take the approach of
acting as "DNS Dispatch".

tim
(I am sure I said this all wrong and I apologize in advance)



On Fri, Jul 21, 2023 at 5:37 AM Taekyoung Kwon <[e-mail]> wrote:

> Hi! Victor, Mark and Paul,
>
> Thank you so much for crucial comments and candid opinions.
> We have been thinking about the downgrade attacks that you mentioned.
> Right now, It is not easy to come up with a solution space for such
> attacks.
> We agree that it is better to discuss this proposal (after addressing such
> issues) in later meetings.
> So we'd like to withdraw our presentation slot this time.
>
> Thank you,
>
> Hyeonmin and Taekyoung,
>
>
> On Mon, Jul 17, 2023 at 7:38 PM <[e-mail]> wrote:
>
>> Send DNSOP mailing list submissions to
>>         [e-mail]
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>         https://www.ietf.org/mailman/listinfo/dnsop
>> or, via email, send a message with subject or body 'help' to
>>         [e-mail]
>>
>> You can reach the person managing the list at
>>         [e-mail]
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of DNSOP digest..."
>> Today's Topics:
>>
>>    1.  draft-dnsop-dnssec-extension-pkix on IETF117 dnsop agenda?
>>       (Viktor Dukhovni)
>>    2. Re:  draft-dnsop-dnssec-extension-pkix on IETF117 dnsop
>>       agenda? (Viktor Dukhovni)
>>    3. Re:  draft-dnsop-dnssec-extension-pkix on IETF117 dnsop
>>       agenda? (Mark Andrews)
>>    4. Re:  [Ext] draft-dnsop-dnssec-extension-pkix on IETF117 dnsop
>>       agenda? (Paul Hoffman)
>>    5. Re:  Best Practices for Managing Existing Delegations When
>>       Deleting a Domain or Host (Viktor Dukhovni)
>>    6. Re:  Fwd: New Version Notification -
>>       draft-ietf-dnsop-avoid-fragmentation-13.txt (Peter van Dijk)
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Viktor Dukhovni <[e-mail]>
>> To: [e-mail]
>> Cc: [e-mail]
>> Bcc:
>> Date: Sun, 16 Jul 2023 15:06:35 -0400
>> Subject: [DNSOP] draft-dnsop-dnssec-extension-pkix on IETF117 dnsop
>> agenda?
>> I see that draft-dnsop-dnssec-extension-pkix is included on the IETF117
>> dnsop agenda.
>>
>>     https://datatracker.ietf.org/doc/draft-dnsop-dnssec-extension-pkix/
>>
>> I haven't seen prior discussion of this item on the list, and,
>> personally, rather suspect it unlikely to gain meaningful support from
>> the WG and see adoption.
>>
>> Would it possible to defer discussion of this document to such time as
>> some evidence of support emerges, and in the meantime use the timeslot
>> for more realistically productive proposals?
>>
>> --
>>     Viktor.
>>
>>
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Viktor Dukhovni <[e-mail]>
>> To: [e-mail]
>> Cc:
>> Bcc:
>> Date: Sun, 16 Jul 2023 15:53:12 -0400
>> Subject: Re: [DNSOP] draft-dnsop-dnssec-extension-pkix on IETF117 dnsop
>> agenda?
>> On Sun, Jul 16, 2023 at 03:06:35PM -0400, Viktor Dukhovni wrote:
>> > I see that draft-dnsop-dnssec-extension-pkix is included on the IETF117
>> dnsop agenda.
>> >
>> >     https://datatracker.ietf.org/doc/draft-dnsop-dnssec-extension-pkix/
>> >
>> > I haven't seen prior discussion of this item on the list, and,
>> > personally, rather suspect it unlikely to gain meaningful support from
>> > the WG and see adoption.
>> >
>> > Would it possible to defer discussion of this document to such time as
>> > some evidence of support emerges, and in the meantime use the timeslot
>> > for more realistically productive proposals?
>>
>> I should perhaps have stated the technical criteria on which I consider
>> the proposal non-viable.  To whit:
>>
>>     - The proposed protocol lacks all downgrade resistance.
>>     - Without a signed delegation from the parent, the existence of the
>>       zone apex CERT MRs and associated RRSIGs is trivially denied  by
>>       an on-path attacker.
>>     - This protocol adds failure modes (CERTs and RRSIGs are available,
>>       but don't match), without adding any security.
>>
>> Since the point of DNSSEC is to thwart active attacks, and the protocol
>> in the proposed draft offers no such protection, I consider it
>> non-viable.
>>
>> There are other substantial issues, but the above is sufficient to stop
>> looking for more reasons why this is a dead-end.
>>
>> --
>>     Viktor.
>>
>>
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Mark Andrews <[e-mail]>
>> To: dnsop <[e-mail]>
>> Cc:
>> Bcc:
>> Date: Mon, 17 Jul 2023 09:47:35 +1000
>> Subject: Re: [DNSOP] draft-dnsop-dnssec-extension-pkix on IETF117 dnsop
>> agenda?
>>
>>
>> > On 17 Jul 2023, at 05:53, Viktor Dukhovni <[e-mail]>
>> wrote:
>> >
>> > On Sun, Jul 16, 2023 at 03:06:35PM -0400, Viktor Dukhovni wrote:
>> >> I see that draft-dnsop-dnssec-extension-pkix is included on the
>> IETF117 dnsop agenda.
>> >>
>> >>    https://datatracker.ietf.org/doc/draft-dnsop-dnssec-extension-pkix/
>> >>
>> >> I haven't seen prior discussion of this item on the list, and,
>> >> personally, rather suspect it unlikely to gain meaningful support from
>> >> the WG and see adoption.
>> >>
>> >> Would it possible to defer discussion of this document to such time as
>> >> some evidence of support emerges, and in the meantime use the timeslot
>> >> for more realistically productive proposals?
>> >
>> > I should perhaps have stated the technical criteria on which I consider
>> > the proposal non-viable.  To whit:
>> >
>> >    - The proposed protocol lacks all downgrade resistance.
>> >    - Without a signed delegation from the parent, the existence of the
>> >      zone apex CERT MRs and associated RRSIGs is trivially denied  by
>> >      an on-path attacker.
>> >    - This protocol adds failure modes (CERTs and RRSIGs are available,
>> >      but don't match), without adding any security.
>> >
>> > Since the point of DNSSEC is to thwart active attacks, and the protocol
>> > in the proposed draft offers no such protection, I consider it
>> > non-viable.
>> >
>> > There are other substantial issues, but the above is sufficient to stop
>> > looking for more reasons why this is a dead-end.
>> >
>> > --
>> >    Viktor.
>> >
>> > _______________________________________________
>> > DNSOP mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/dnsop
>>
>> I concur.  This is a horribly flawed proposal.
>>
>> Mark
>> --
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: [phone]              INTERNET: [e-mail]
>>
>>
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Paul Hoffman <[e-mail]>
>> To: "[e-mail]" <[e-mail]>
>> Cc: "[e-mail]" <[e-mail]>
>> Bcc:
>> Date: Sun, 16 Jul 2023 23:54:21 +0000
>> Subject: Re: [DNSOP] [Ext] draft-dnsop-dnssec-extension-pkix on IETF117
>> dnsop agenda?
>> On Jul 16, 2023, at 12:06 PM, Viktor Dukhovni <[e-mail]>
>> wrote:
>> > Would it possible to defer discussion of this document to such time as
>> > some evidence of support emerges, and in the meantime use the timeslot
>> > for more realistically productive proposals?
>>
>> +1. The 15 minutes allocated to this draft would be better spent on
>> longer mic lines for the other drafts that have a higher likelihood of
>> adoption. Once this draft has more on-list discussion, if those of us who
>> are skeptical are wrong, the discussion in Prague will be even more
>> fruitful.
>>
>> --Paul Hoffman
>>
>>
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Viktor Dukhovni <[e-mail]>
>> To: "[e-mail]" <[e-mail]>
>> Cc:
>> Bcc:
>> Date: Sun, 16 Jul 2023 22:52:52 -0400
>> Subject: Re: [DNSOP] Best Practices for Managing Existing Delegations
>> When Deleting a Domain or Host
>> On Tue, Jul 11, 2023 at 07:06:49PM +0000, Hollenbeck, Scott wrote:
>>
>> >
>> https://datatracker.ietf.org/doc/draft-hollenbeck-regext-epp-delete-bcp/
>> >
>> > The draft includes descriptions of current known practices and
>> > suggests that some should be avoided, some are candidates for "best",
>> > and there are others that haven't been used that might also be
>> > candidates for "best". The authors would like to learn if others agree
>> > with our assessments and/or can suggest improvements.
>>
>> Thanks for reaching out, I'll do my best to share what I hope is a
>> sensible perspective.  But first some followups to already posted
>> feedback.
>>
>> On Tue, Jul 11, 2023 at 03:22:40PM -0700, Brian Dickson wrote:
>>
>> > For example, the registrar for the domain that is the parent of a host
>> > entry, should be able to "disavow" a particular reference (delegation
>> > to said host). It would be the responsibility of the other registrar
>> > (for the domain being disavowed) to clean up the broken delegations.
>> > This is basically giving authority to the DNS operator as a party to
>> > the situation, even if only indirectly.
>>
>> Just checking the intent here, I think you're saying the "disavowal" is
>> potentially a case-by-case option.  So that e.g. at the time that DNS
>> service for a domain is discontinued, the DNS operator (perhaps via
>> their registrar) should be able to break drop NS records from a
>> *particular* delegation.
>>
>> This is an interesting proposal.  It reasonably aligns with the
>> operational reality that it takes mutual agreement between two parties
>> to provide working DNS for a domain that isn't self-hosted.
>>
>> In the DANE/DNSSEC survey, I am tracking almost ~350k zones (out of
>> ~22.8M) with no SEP, roughly half of which are just lame delegations
>> (the listed servers return "REFUSED"), but for various reasons it is
>> difficult for the former DNS operator to get the delegations terminated.
>>
>> The chief difficulty here is that this does not work for "external"
>> nameserver objects.  If we're really going to solve this problem, the
>> solution should I think also work for the case when the nameserver and
>> the client zone live in different registries.
>>
>> We need a protocol by which such disavowal can happen regardless of
>> where the nameserver might be found.
>>
>> Of course if that's too difficult to solve in a timely manner, and we
>> can reduce barriers in host object management within a registry, that's
>> fine too, and the larger goal need not hold up progress on the more
>> focused problem.
>>
>> > Maybe having the otherwise dangling or otherwise blocking references
>> > converted to their respective in-bailiwick names might be a solution.
>> E.g.
>> > if domain2.example had an NS record pointing to ns1.domain1.example, and
>> > domain1.example were deleted (or ns1.domain1.example were deleted),
>> having
>> > the reference converted (by whom??) to ns1.domain2.example would
>> suffice.
>> > But, that would also require picking a new IP address to use for the
>> glue
>> > for that (new) host object. It's a thorny problem, a real can of worms.
>>
>> In the most typical situation, the servers in question will have for
>> some time already discontinued DNS service for the objects to be
>> removed, and the dependent domain loses nothing (only gains!) from
>> having the no longer willing nameservers deleted.
>>
>> Therefore, my take is that the delegation NS record should be simply
>> removed from the dependent zone.  No renaming, or other steps to paper
>> over the issue.  Subsequent replacement is up to the owner of the
>> dependent zone.  Indeed if everything was done optimally, the dependent
>> delegations would have proactively switched to working nameservers
>> first.
>>
>> Now we do want to prevent accidents, and so deletion of host objects
>> that are still used as nameservers by zones not being deleted should
>> perhaps require some form of confirmation that some dependencies are
>> being forcibly broken.  How to do that, and whether confirmation should
>> actually require the requesting party to submit a second request, ...
>> is user interface design that should be discussed with care.  I don't
>> claim to have the right answer on how to balance safety vs. usability.
>>
>> > This means that unrelated glue records could point at the same IP
>> > address, even if the host records are distinct with different owners.
>> > First-to-register does not guarantee that the correct ownership could
>> > be determined by creation time (i.e.  it's a race condition without a
>> > stronger mechanism.)
>>
>> Explicit disavowal should be able to solve this too, if the IP addresses
>> targetted can be reasonably safely (multiple samples over a period of
>> time, or a confirmed request from the point of contact for the IP space,
>> ...) determined to be refusing service for the disavowed zones.
>>
>> So my own position is that:
>>
>>     - The host object owner should be able to delete it at will, with
>>       any friction solely to help avoid difficult to recover accidents,
>>       rather than prevent the nameserver owner/operator from
>>       discontinuing service.
>>
>>     - The dependent zones would then have the corresponding nameserver
>>       entries deleted (not renamed, ...).
>>
>>     - Of course nameserver operators should have a communication channel
>>       with contact persons the domains they serve, and should first prod
>>       them to move to alternative arrangements when service is slated to
>>       be discontinued.
>>
>>     - When a delegation is still listing stale nameservers, the
>>       best-practice communication process has broken down somewhere
>>       along the way, and we're no longer in the realm of
>>       "best-practice".
>>
>>     - Disavowal of specific relationships, well short of removing the
>>       host object for everyone is IMHO a good idea.  This should work
>>       across, not just within, registries.  And should work for
>>       IP-aliased servers.
>>
>>     - That is, a target nameserver whether by name or IP address should
>>       be able within a reasonable timeframe to drop a delegation to
>>       which it no longer consents.
>>
>> The last two items are of course more of a wish list for a future state
>> than a current "best-practice".  The earlier items could be practicable
>> today.
>>
>> --
>>     Viktor.
>>
>>
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Peter van Dijk <[e-mail]>
>> To: dnsop <[e-mail]>
>> Cc:
>> Bcc:
>> Date: Mon, 17 Jul 2023 12:28:07 +0200
>> Subject: Re: [DNSOP] Fwd: New Version Notification -
>> draft-ietf-dnsop-avoid-fragmentation-13.txt
>> On Wed, 2023-07-05 at 18:51 -0400, Tim Wicinski wrote:
>>
>> All
>>
>> The authors of draft-ietf-dnsop-avoid-fragmentation worked with different
>> implementers to expand upon the index of Known Implementations, and what
>> they implement specifically.
>>
>> The chairs would like to have a one week follow up Working Group Last
>> Call comment period. We are looking for substantive comments regarding the
>> changes made, and if they are enough to address concerns raised.
>>
>>
>> As Vladimir also said in his dnsdir review, this document is in way
>> better shape than it was.
>>
>> I do see one obstacle.
>>
>> In section 3.1, the draft says:
>>
>> > 2. UDP responders are RECOMMENDED to set IP "Don't Fragment flag (DF)
>> bit" [RFC0791 <https://www.rfc-editor.org/rfc/rfc791>] on IPv4.
>>
>> Then in Appendix D (Known Implementations), all implementations have
>> indicated they do *not* set the DF bit. It seems wrong to RECOMMEND
>> something, especially in a document targeted for BCP, that nobody is doing.
>>
>> This comment period will end Wednesday July 12, 2023.   If there
>> are substantive comments raised, we can address these during the meeting.
>>
>> A friendly request: please indicate Last Calls in the Subject! I missed
>> this one until now.
>>
>>
>> Kind regards,
>> --
>> Peter van Dijk
>> PowerDNS.COM BV - https://www.powerdns.com/
>> _______________________________________________
>> DNSOP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>