Re: [DNSOP] draft-thomassen-dnsop-mske: DNSKEYs in non-apex
I didn't explain why, so let me add just a short pointer. No need to go deeper here at this point of the draft, I think. On 28/11/2022 19.26, Peter Thomassen wrote: As such, I don't see any risk that would not be exposed immediately during implementation/testing, and the fix is also trivial. Triviality of a fully correct fix may depend on the particular implementation. Note the implications for caching, etc. These DNSKEYs will be DNSSEC-validated but must not be used for validation of other signatures. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-thomassen-dnsop-mske: DNSKEYs in non-apex
Hi Vladimir, Thanks for your feedback! Please see below. On 11/11/22 19:01, Vladimír Čunát wrote: It's not a major thing in your design, but I see a risk that DNSKEYs at non-apex might have trouble validating, so at some point I'd expect your proposal to choose a different approach (e.g. allocate a new identical RR type) or at least confirm that it won't be a major problem. I agree that this would be a significant risk if the consumers of these records were the general public, who generally use whatever resolver without paying specific attention or controlling any of the moving pieces. However, the records would only be processed by supporting DNS operators, and it is entirely in their hands to use a resolver that would allow such validation. As such, I don't see any risk that would not be exposed immediately during implementation/testing, and the fix is also trivial. IMO, this means that nothing needs to be done about it on the spec side. What do other think about the significance of that risk? Thanks, Peter -- https://desec.io/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-thomassen-dnsop-mske: DNSKEYs in non-apex
Hello. It's not a major thing in your design, but I see a risk that DNSKEYs at non-apex might have trouble validating, so at some point I'd expect your proposal to choose a different approach (e.g. allocate a new identical RR type) or at least confirm that it won't be a major problem. --Vladimir | knot-resolver.cz ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-thomassen-dnsop-mske
Hi, Yesterday, I uploaded the below set of ideas for filling in the automation gaps in DNSSEC multi-signer, in particular the key exchange problem between multi-signing peers. I'm planning to present this at the London meeting, so I wanted to give folks as chance to take a look at it. I'm not sure myself if this is how it should be done, but it will be interesting to learn what people think. Best, Peter A new version of I-D, draft-thomassen-dnsop-mske-00.txt has been successfully submitted by Peter Thomassen and posted to the IETF repository. Name: draft-thomassen-dnsop-mske Revision: 00 Title: DNSSEC Multi-Signer Key Exchange (MSKE) Document date: 2022-10-24 Group: Individual Submission Pages: 11 URL: https://www.ietf.org/archive/id/draft-thomassen-dnsop-mske-00.txt Status: https://datatracker.ietf.org/doc/draft-thomassen-dnsop-mske/ Html: https://www.ietf.org/archive/id/draft-thomassen-dnsop-mske-00.html Htmlized: https://datatracker.ietf.org/doc/html/draft-thomassen-dnsop-mske Abstract: Answering DNSKEY/CDS/CDNSKEY queries in an [RFC8901] multi-signer DNSSEC configuration requires all operators to serve not only their own public key information, but also include each other's public keys. This ensures that clients obtain a consistent view of the DNSSEC configuration regardless of who is answering a given query. In order to enable operators to import the keys needed for assembling these responses, a method for discovering them is necessary. This document specifies how DNS operators can announce which are the keys they intend to use for signing a given zone (DNSKEY) and which keys are designated for secure entry into the zone (CDS/CDNSKEY). It further introduces the CNS record type to facilitate proactive discovery of the aforementioned signals. Taken together, these parts function as an authenticated multi-signer key-exchange (MSKE) scheme. This MSKE mechanism uses the signaling mechanism introduced in [I-D.ietf-dnsop-dnssec-bootstrapping] to complete the automated workflows described in [I-D.ietf-dnsop-dnssec-automation]. -- https://desec.io/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
