Re: [DNSOP] [Ext] More private algorithms for DNSSEC
> On 30 Mar 2022, at 14:29, Brian Dickson wrote: > > > > On Tue, Mar 29, 2022 at 1:31 PM Mark Andrews wrote: > > > > On 30 Mar 2022, at 00:28, Peter Thomassen wrote: > > > > > > > > On 3/28/22 20:34, Mark Andrews wrote: > >> About the only part not already specified is matching DS to DNSKEY using > >> PRIVATEDNS but as you can see it is obvious to anyone with a little bit of > >> cryptographic understanding. > > > > That creates problems plus complexity, which I find very undesirable. > > Orthogonality trumps complexity. > > > > For example, zones need to have a DNSKEY for each signing algorithm given > > in the DS record set. I would expect most implementations to currently only > > look at the algorithm number in this context, and not at the 253/254 > > algorithm identifier. > > And if they don’t implement any PRIVATEDNS or PRIVATEOID algorithm this is > EXACTLY the correct behaviour. > > You (Mark) are arguing that any experimentation would turn 253 in to a MUST > IMPLEMENT. No, its experimenters need to implement. Everyone else doesn’t have to touch any code. > I think the other arguments (about having multiple algorithms allocated for > experimental usage) is more persuasive, including the nature of multiple > algorithms when experimentation is done. > > This also keeps the 253 use case (actual private production use) distinct > from experimentation usage, thus preventing any negative interaction between > experiments and production zones. Where did private (not needed to be documented) morph into not for use in experimentation? We documented how to avoid negative interactions by specifying that you MUST use a DNS namespace you control or use a OID which you have been allocated (which are free from IANA). There are no restrictions about publishing PRIVATEDNS or PRIVATEOID keys to the world. Anyone one can publish them at anytime anywhere in the DNS tree. > (It's not about whether the behavior is correct, it's about whether there is > value added in selecting the 253 mechanism rather than reserving > experiment-only code points, IMHO.) We only have a restricted number of code points that don’t require the use of an OID or a DNS name and once they have been used for an algorithm they are burned for use with any other algorithm. > > There will also be implementations which don't care to implement such > > "private algorithm peeking". For those, algorithm handling would not be > > ensured in the same way as it is for non-253/254 algorithms. > > Then they would be broken which by the way is why you run experiment. > > This presupposes that only 253 is used, rather than what Paul H has proposed > in his very small draft. It's a moot point and not contradictory to the > proposal, to not want or need to do the peeking bit (i.e. not supporting 253). > > > Last, I'm not convinced that running a PQ algorithm (or other) experiment > > to test (non-supporting) resolvers' behavior should require controlling a > > domain name or OID (as is required for 253/254). > > So rather than that you want to have to deal with potential colliding use of > code points without identifiers. > > You can’t > reliably clean up experimental code points, especially if there are a lot of > implementations. DNS has a long tail. > > > These concerns bring us back to Nils' comment that 253/254 is not a good > > basis for performing research and doing real-life experiments. > > > > > > The above headaches would be in addition to the effort of writing the > > clarification document, whereas Paul's proposal requires just the document. > > DNSSEC RFC say check the algorithm for a match. They do not say check the > number. PRIVATEDNS and PRIVATEOID are sub typed > and checking of those fields was always required once you implemented an > algorithm in those spaces. > > Everyone else is saying, we don't want this to be the way of doing > experiments (with lots of good reasoning behind that). > The "once you implemented" is a conditional that is not mandatory to > implement. There is also guidance now that sub-typing is not a good idea for > anything new in DNS. > > I'd suggest that your argument is in fact suggesting the use of sub-typing > for something new (experiments rather than just private use) in DNS. Bumpkin. If I’d thought that PRIVATEDNS or PRIVATEOID couldn’t be used for experimentation I would have argued for reservations myself 20+ years ago. Below are the ONLY restrictions applied to PRIVATEDNS or PRIVATEOID. Please highlight where it says “not for experimental use” or “can only be used for production” or “never to be published to the world”. None of those restrictions are there. They are figments of your imagination. A.1.1. Private Algorithm Types Algorithm number 253 is reserved for private use and will never be assigned to a specific algorithm. The public key area in the DNSKEY RR and the signature area in the RRSIG RR begin
Re: [DNSOP] [Ext] More private algorithms for DNSSEC
On Tue, Mar 29, 2022 at 1:31 PM Mark Andrews wrote:
>
>
> > On 30 Mar 2022, at 00:28, Peter Thomassen wrote:
> >
> >
> >
> > On 3/28/22 20:34, Mark Andrews wrote:
> >> About the only part not already specified is matching DS to DNSKEY
> using PRIVATEDNS but as you can see it is obvious to anyone with a little
> bit of cryptographic understanding.
> >
> > That creates problems plus complexity, which I find very undesirable.
> Orthogonality trumps complexity.
> >
> > For example, zones need to have a DNSKEY for each signing algorithm
> given in the DS record set. I would expect most implementations to
> currently only look at the algorithm number in this context, and not at the
> 253/254 algorithm identifier.
>
> And if they don’t implement any PRIVATEDNS or PRIVATEOID algorithm this is
> EXACTLY the correct behaviour.
>
You (Mark) are arguing that any experimentation would turn 253 in to a MUST
IMPLEMENT.
I think the other arguments (about having multiple algorithms allocated for
experimental usage) is more persuasive, including the nature of multiple
algorithms when experimentation is done.
This also keeps the 253 use case (actual private production use) distinct
from experimentation usage, thus preventing any negative interaction
between experiments and production zones.
(It's not about whether the behavior is correct, it's about whether there
is value added in selecting the 253 mechanism rather than reserving
experiment-only code points, IMHO.)
>
> > There will also be implementations which don't care to implement such
> "private algorithm peeking". For those, algorithm handling would not be
> ensured in the same way as it is for non-253/254 algorithms.
>
> Then they would be broken which by the way is why you run experiment.
This presupposes that only 253 is used, rather than what Paul H has
proposed in his very small draft. It's a moot point and not contradictory
to the proposal, to not want or need to do the peeking bit (i.e. not
supporting 253).
> > Last, I'm not convinced that running a PQ algorithm (or other)
> experiment to test (non-supporting) resolvers' behavior should require
> controlling a domain name or OID (as is required for 253/254).
>
> So rather than that you want to have to deal with potential colliding use
> of code points without identifiers.
> You can’t
> reliably clean up experimental code points, especially if there are a lot
> of implementations. DNS has a long tail.
>
> > These concerns bring us back to Nils' comment that 253/254 is not a good
> basis for performing research and doing real-life experiments.
> >
> >
> > The above headaches would be in addition to the effort of writing the
> clarification document, whereas Paul's proposal requires just the document.
>
> DNSSEC RFC say check the algorithm for a match. They do not say check the
> number. PRIVATEDNS and PRIVATEOID are sub typed
> and checking of those fields was always required once you implemented an
> algorithm in those spaces.
>
Everyone else is saying, we don't want this to be the way of doing
experiments (with lots of good reasoning behind that).
The "once you implemented" is a conditional that is not mandatory to
implement. There is also guidance now that sub-typing is not a good idea
for anything new in DNS.
I'd suggest that your argument is in fact suggesting the use of sub-typing
for something new (experiments rather than just private use) in DNS.
>
> > I therefore support the assignment of experimental algorithm numbers,
> and I think the text should mandate that they MUST be treated as unknown
> and have no special processing, unlike private ones.
>
> Stop calling for polluting of the commons. We can’t properly cleanup
> after using experimental code points.
>
I think it is sufficient to reword Paul's proposal, so that the 7 new code
points are labeled "experimental" rather than "private use".
A few words about expected behavior of implementers ("Don't release
production code with these code points in use", along with "ship production
code to explicitly disallow use of these code points".)
DNS hasn't previously had explicitly allocated experimental code points for
algorithms, so how those do and do not get used probably needs some minimal
guidance.
I don't know if that belongs in this document, or as a separate document.
My instinct is "separate", and also that such a document doesn't need to be
a blocker on Paul H's document.
Maybe it is necessary to add some sort of explicit signaling about use of
experimental code points and that software involved in a particular
conversation (server or client) is in experimental mode.
The (potentially really bad) idea that occurred to me was, there's a
currently unused bit in the header, "Z", which is a vestigial remnant of
the larger Z field of "must be zero" from 103[345]. Perhaps that bit could
be re-labeled "X" (for experimental)?
Experimentation, including interoperability is a good thing. Leaving past
experiments' code assignments
Re: [DNSOP] [Ext] More private algorithms for DNSSEC
To fix this we need to extend DS to say that for any newly allocated digest types that they must include the matching DNS name for algorithm 253 and the match IOD for algorithm 254 before actual digest in the digest field. Then allocate PRIVATE SHA256, PRIVATE SHA-384 and PRIVATE GOST R 34.11-94 which are replacements for SHA256, SHA-384 and GOST R 34.11-94 respectively that support pre-publishing DS for PRIVATEDNS and PRIVATEOID. > On 29 Mar 2022, at 08:08, Mark Andrews wrote: > > Note you can’t prepublish a DS to roll keys you need to publish the DNSKEY > first. > > -- > Mark Andrews > >> On 29 Mar 2022, at 05:33, Mark Andrews wrote: >> >> >> >>> On 29 Mar 2022, at 01:34, Paul Hoffman wrote: >>> On Mar 27, 2022, at 6:23 PM, Mark Andrews wrote: There is zero reason to reserve any ADDITIONAL space for experimentation. >>> >>> Assume that you want to experiment with creating responses that have >>> multiple as-yet-undefined algorithms. How would you do that today? >>> Differentiating in the RRdata, as is done today, would create a single >>> RRset in the response. >>> >>> --Paul Hoffman >>> >> >> You would add records of type 253 with “alg1.example.org” as the first >> algorithm name, “alg2.example.org” as the second algorithm name where >> example.org is a domain you control. If someone else is running another >> experiment they add 253 with the algorithm name specified as >> “alg1.example.net” where example.net is a domain they control. >> >> When you are checking if you support a particular instance of PRIVATEDNS you >> check the algorithm name as well as the algorithm number (253). >> >> For working out if the DS record indicates support for your PRIVATEDNS >> algorithm you need to find the matching DNSKEY based on the hash and extract >> the PRIVATEDNS algorithm name. If you can’t find a matching DNSKEY the >> DNSKEY RRset is bogus as the DS record says that the DNSKEY record exists. >> >> If you want to see how this would work add “PRIVATE-RSASHA256” using >> RSASHA256.ICANN.ORG as the first algorithm name and >> “PRIVATE-ECDSAP256SHA256” with ECDSAP256SHA256.ICANN.ORG as the second name >> as a starting point where they are reimplementations of RSASHA256 and >> ECDSAP256SHA256 respectively. Throw in “UNKNOWN.ICANN.ORG” with some random >> data as the rest of the key. >> >> About the only part not already specified is matching DS to DNSKEY using >> PRIVATEDNS but as you can see it is obvious to anyone with a little bit of >> cryptographic understanding. >> >> Mark >> -- >> 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 >> https://www.ietf.org/mailman/listinfo/dnsop > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- 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 https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] More private algorithms for DNSSEC
> On 30 Mar 2022, at 00:28, Peter Thomassen wrote: > > > > On 3/28/22 20:34, Mark Andrews wrote: >> About the only part not already specified is matching DS to DNSKEY using >> PRIVATEDNS but as you can see it is obvious to anyone with a little bit of >> cryptographic understanding. > > That creates problems plus complexity, which I find very undesirable. > Orthogonality trumps complexity. > > For example, zones need to have a DNSKEY for each signing algorithm given in > the DS record set. I would expect most implementations to currently only look > at the algorithm number in this context, and not at the 253/254 algorithm > identifier. And if they don’t implement any PRIVATEDNS or PRIVATEOID algorithm this is EXACTLY the correct behaviour. > Of course, a dedicated document may clarify this, but I don't see how this is > less complex than assigning experimental algorithm numbers. All DNSSEC > software out there would have to implement it, test/maintain it etc. This > does not only apply to resolver software; think of application-level > libraries like dnspython etc. This is like all the cries of “think of the children”. Adding support to look for a domain names at the start of the key data in code that already extract domain names from packets should be a no brainer for any piece of DNSSEC software. > There will also be implementations which don't care to implement such > "private algorithm peeking". For those, algorithm handling would not be > ensured in the same way as it is for non-253/254 algorithms. Then they would be broken which by the way is why you run experiment. > Further, if someone actually *is* using private 253/254 algorithms in > production, any experiments would not be structurally independent from > potential such private use cases. Giving the little confidence that all DNS > software would implement "253/254 algorithm disentanglement" correctly, > private-algo zone owners may be hesitant to run any experiments at all. If someone is using PRIVATEDNS or PRIVATEOID then they should be following rules for using that code point. Are the experiments that use deliberately broken DNSSEC zone “structurally” independent? > Last, I'm not convinced that running a PQ algorithm (or other) experiment to > test (non-supporting) resolvers' behavior should require controlling a domain > name or OID (as is required for 253/254). So rather than that you want to have to deal with potential colliding use of code points without identifiers. That is far worse than having to deal with PRIVATEDNS and PRIVATEOID as then you do get false validation failures. You can’t reliably clean up experimental code points, especially if there are a lot of implementations. DNS has a long tail. With PRIVATEDNS and PRIVATEOID you don’t need to cleanup the old code when the experiment is over, you just choose a new name / OID for the next experiment. To reliably run the experiments one is going to have to have a magic number for each algorithm embedded in the key data and check it. We have two code points that this do this already. We don’t need anymore. > These concerns bring us back to Nils' comment that 253/254 is not a good > basis for performing research and doing real-life experiments. > > > The above headaches would be in addition to the effort of writing the > clarification document, whereas Paul's proposal requires just the document. DNSSEC RFC say check the algorithm for a match. They do not say check the number. PRIVATEDNS and PRIVATEOID are sub typed and checking of those fields was always required once you implemented an algorithm in those spaces. > I therefore support the assignment of experimental algorithm numbers, and I > think the text should mandate that they MUST be treated as unknown and have > no special processing, unlike private ones. Stop calling for polluting of the commons. We can’t properly cleanup after using experimental code points. We have 2 mechanisms that contain the pollution to a point (name/oid) for each experimental algorithim and we should use them. This is good engineering. > Best, > Peter > > -- > https://desec.io/ -- 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 https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-wisser-dnssec-automation
(no hats) I've read this draft and I think it's a useful addition to assisting DNSSEC. tim On Fri, Mar 25, 2022 at 11:35 AM Benno Overeinder wrote: > As with the previous Call for Adoption today, at this week's DNSOP > meeting at IETF 113, we announced that we are initiating a Call for > Adoption for the draft-wisser-dnssec-automation. With the survey we > conducted for the last IETF 112, this draft was also a clear candidate. > > With this email we start a period of two weeks for the call for adoption > of draft-wisser-dnssec-automation on the mailing list. > > The draft is available here: > https://datatracker.ietf.org/doc/draft-wisser-dnssec-automation/. > > Please review this draft to see if you think it is suitable for adoption > by DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 8 April 2022 > > Thanks, > > Suzanne, Tim and Benno > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-thomassen-dnsop-dnssec-bootstrapping
(No hats) I’ve read this draft and support adoption Tim Sent from my iPhone > On Mar 25, 2022, at 11:28, Benno Overeinder wrote: > > As announced during the DNSOP meeting this week at the IETF 113, we are > starting a Call for Adoption for the > draft-thomassen-dnsop-dnssec-bootstrapping. With the survey we conducted > before the last IETF 112, this draft was a clear candidate. > > With this email we start a period of two weeks for the call for adoption of > draft-thomassen-dnsop-dnssec-bootstrapping on the mailing list. > > The draft is available here: > https://datatracker.ietf.org/doc/draft-thomassen-dnsop-dnssec-bootstrapping/ > > Please review this draft to see if you think it is suitable for adoption by > DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 8 April 2022 > > Thanks, > > Suzanne, Tim and Benno ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] More private algorithms for DNSSEC
On 3/28/22 20:34, Mark Andrews wrote: About the only part not already specified is matching DS to DNSKEY using PRIVATEDNS but as you can see it is obvious to anyone with a little bit of cryptographic understanding. That creates problems plus complexity, which I find very undesirable. Orthogonality trumps complexity. For example, zones need to have a DNSKEY for each signing algorithm given in the DS record set. I would expect most implementations to currently only look at the algorithm number in this context, and not at the 253/254 algorithm identifier. Of course, a dedicated document may clarify this, but I don't see how this is less complex than assigning experimental algorithm numbers. All DNSSEC software out there would have to implement it, test/maintain it etc. This does not only apply to resolver software; think of application-level libraries like dnspython etc. There will also be implementations which don't care to implement such "private algorithm peeking". For those, algorithm handling would not be ensured in the same way as it is for non-253/254 algorithms. Further, if someone actually *is* using private 253/254 algorithms in production, any experiments would not be structurally independent from potential such private use cases. Giving the little confidence that all DNS software would implement "253/254 algorithm disentanglement" correctly, private-algo zone owners may be hesitant to run any experiments at all. Last, I'm not convinced that running a PQ algorithm (or other) experiment to test (non-supporting) resolvers' behavior should require controlling a domain name or OID (as is required for 253/254). These concerns bring us back to Nils' comment that 253/254 is not a good basis for performing research and doing real-life experiments. The above headaches would be in addition to the effort of writing the clarification document, whereas Paul's proposal requires just the document. I therefore support the assignment of experimental algorithm numbers, and I think the text should mandate that they MUST be treated as unknown and have no special processing, unlike private ones. 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-dnssec-bootstrapping
On 16:27 25/03, Benno Overeinder wrote: > The draft is available here: > https://datatracker.ietf.org/doc/draft-thomassen-dnsop-dnssec-bootstrapping/ > > Please review this draft to see if you think it is suitable for adoption by > DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > I support the adoption of this draft in the WG. I have contributed to past revisions and will continue to do so after adoption. On the other hand, we already have an implementation on the side of a registry that will be adjusted to the final result. Hugo signature.asc Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: DNSSEC as BCP: draft-hoffman-dnssec
On 3/26/22 02:21, Paul Hoffman wrote: On Mar 25, 2022, at 5:59 PM, Joey Deng wrote: During my reading of DNS and DNSSEC, I found another RFC (RFC 7129) very helpful in understanding the motivation from NSEC to NSEC3, besides RFC 5155, but it is not listed in the draft above (maybe because it is for informational purposes?). https://datatracker.ietf.org/doc/rfc7129/ While RFC 7129 is interesting for understanding the protocol, it is background material and maybe not really part of the protocol itself or an extension to the protocol itself. I'm not sure where it would fit into this document. If The purpose is to introduce all of the RFCs in one place so that the reader can understand the many aspects of DNSSEC. (taken from the abstract), then including background material that helps understanding may be the right thing to do, perhaps in a separate section (e.g. "Additional non-normative documents" between Sections 3 and 4). Otherwise, perhaps the purpose should be re-stated as to emphasize collecting only all pieces of the protocol specification. I generally support this draft, and am willing to contribute review comments, perhaps editorial PRs etc. Best, Peter -- https://desec.io/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
