OK, thanks for the explanation. That helps me understand the scenario where this would be needed, but it seems like simpler solutions are possible. For example, the resolver could be configured to restrict the use of PRIVATEDNS keys to specific subtrees where their usage is known.
This draft effectively turns PRIVATEDNS into a general-purpose extension point for _public_ DNSSEC algorithms. These algorithms could be used interoperably in public, so they would be quite different from normal Private Use range values in an IANA registry. That's an interesting idea, but it seems like a significant revolution in DNSSEC algorithm registration without an obvious motivation. --Ben ________________________________ From: Mark Andrews <ma...@isc.org> Sent: Tuesday, July 23, 2024 12:28 PM To: Ben Schwartz <bem...@meta.com> Cc: dnsop <dnsop@ietf.org> Subject: Re: [DNSOP] Fwd: New Version Notification for draft-andrews-private-ds-digest-types-00.txt At the moment you can only have one private algorithm per key type world wide. This is all to do with how you prove a zone is to be treated as insecure. If example. com is using private. example. com and example. net is using private. example. net At the moment you can only have one private algorithm per key type world wide. This is all to do with how you prove a zone is to be treated as insecure. If example.com is using private.example.com and example.net is using private.example.net how done validator that knows about private.example.com prove that example.net response are to be treated as insecure when there is a DS with PRIVATEDNS returned? -- Mark Andrews On 23 Jul 2024, at 07:46, Ben Schwartz <bem...@meta.com> wrote: Two questions I didn't see addressed: Why would a zone need to be signed with multiple private algorithms? Why isn't it sufficient to treat all private algorithms as a single algorithm for DS purposes, and distinguish by the Key Tag and/or trial hashing? --Ben Schwartz ________________________________ From: Mark Andrews <ma...@isc.org> Sent: Monday, July 22, 2024 1:08 PM To: dnsop <dnsop@ietf.org> Subject: [DNSOP] Fwd: New Version Notification for draft-andrews-private-ds-digest-types-00.txt This addresses a gap in the DNSSEC specification. DS records need to identify specific DNSSEC algorithms rather than a set of DNSSEC algorithms. Begin forwarded message: From: internet-drafts@ ietf. org Subject: New Version Notification for draft-andrews-private-ds-digest-types-00. txt This addresses a gap in the DNSSEC specification. DS records need to identify specific DNSSEC algorithms rather than a set of DNSSEC algorithms. Begin forwarded message: From: internet-dra...@ietf.org Subject: New Version Notification for draft-andrews-private-ds-digest-types-00.txt Date: 22 July 2024 at 10:05:24 GMT-7 To: "M. Andrews" <ma...@isc.org>, "Mark Andrews" <ma...@isc.org> A new version of Internet-Draft draft-andrews-private-ds-digest-types-00.txt has been successfully submitted by Mark Andrews and posted to the IETF repository. Name: draft-andrews-private-ds-digest-types Revision: 00 Title: Private DS Digest Types Date: 2024-07-22 Group: Individual Submission Pages: 5 URL: https://www.ietf.org/archive/id/draft-andrews-private-ds-digest-types-00.txt<https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-andrews-private-ds-digest-types-00.txt__;!!Bt8RZUm9aw!8QIT18AIL9ewonmo3nayaXnt_PX8h4hi70SPJjNzLRWNe6kEEmiVeLvmEm6RBqxGA5SwNi0$> Status: https://datatracker.ietf.org/doc/draft-andrews-private-ds-digest-types/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-andrews-private-ds-digest-types/__;!!Bt8RZUm9aw!8QIT18AIL9ewonmo3nayaXnt_PX8h4hi70SPJjNzLRWNe6kEEmiVeLvmEm6RBqxG78jzG2E$> HTMLized: https://datatracker.ietf.org/doc/html/draft-andrews-private-ds-digest-types<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-andrews-private-ds-digest-types__;!!Bt8RZUm9aw!8QIT18AIL9ewonmo3nayaXnt_PX8h4hi70SPJjNzLRWNe6kEEmiVeLvmEm6RBqxGSCgFVBk$> Abstract: When DS records where defined the ability to fully identify the DNSSEC algorithms using PRIVATEDNS and PRIVATEOID was overlooked. This documents specifies 2 DS Algorithm Types which allow the DNSSEC algorithm sub type to be encoded in the DS record. The IETF Secretariat -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
