On 15. 07. 22 14:36, George Thessalonikefs wrote:
Hi Libor,
Thanks for the time and feedback!
If you prefer the dry-run DS to have a static length maybe then you are
more interested in the dry-run equivalent algorithm per actual algorithm
timeline?
It would be interesting to know if your concern for static length arises
from a registry point of view (as also mentioned in section 5.1.1), or
something else.
Although security is unlikely to be an issue currently, it still means
that whichever number we choose today may not work in the future.
If collisions could happen then a dry-run zone could be spoofed.
Although that would not matter for the DNSSEC adoption case as the zone
was unsigned in the first place, the other cases (sections 3.1.2 and
3.1.3) would weaken the security of an already DNSSEC signed zone.
But apart from security, I am also worried about the extra steps needed
to handle the contents of the DS record and using it for DNSSEC (need to
also crop/stretch the key digests while validating).
I would prefer the DNSSEC part to be mostly intact when dry running so
that there is confidence on the reported results and expect the same
behavior when advancing from a dry-run state.
Do my concerns make sense?
They do make sense to me. I think constant DS length is not worth the
trouble doing it _this_ "crazy" way.
Burning one bit in DS type field sounds more sensible to me and it also
solves problem "Registry supports only fixed sized hashes per hash
algorithm".
It's not like we are forever bound to 8 bits here: E.g. we can easily
use a magic value 255 to signal that next octet is continuation of the
type field, if the need ever comes. Every new codepoint requires new
code anyway so I can't see a problem with this approach.
If burning one bit does not have consensus I'm not totally opposed to
the variable length approach but see 5.1.1.
Aside from that, here is my feedback:
3. Overview
Validating resolvers that don't support the DS Type Digest algorithm
ignore it as per [RFC6840], Section 5.2. Validating resolvers that
support dry-run DNSSEC are signaled to treat the zone as a dry-run
zone. Validating resolvers that support dry-run DNSSEC MUST support
[DNS-ERROR-REPORTING].
I would like to get rid of this requirement. First, having support for
error reporting != feature being enabled so this MUST does nothing
useful anyway.
Secondly, there is no technical reason for this. There might be other
ways to instrument the client side.
3.2. Opt-in end-to-end DNSSEC testing
Out of curiosity, do you have an implementation for Unbound? I'm bit
worried about complexity of this...
4.1.1. Hash is created from DNSKEY (or CDNSKEY)
* Feedback from Gavin Brown from CentralNIC.
* DNSKEYs do have space for flags which are ignored. There was a
suggestion to use the flags in the DNSKEY to signal Dry-run, but
we do not like it, because it makes the move to actual DNSSEC
impossible without also changing the DNSKEY RRset.
Unfortunately this does not work. Unknown DNSKEY flags are ignored, so
resolvers not aware of DRY-RUN will just use them as if the flag was not
present.
4.1.3. Idea from Petr: Normalize the different DS hacks
Well, if you are ready to push more parent-side RRs count me in!
Petr Špaček
Best regards,
-- Yorgos
On 13/07/2022 13:26, libor.peltan wrote:
Hi Willem, Yorgos, Roy, dnsop,
I dare to repeat my support for the ideas in dry-run-dnssec draft.
However, I still don't like the suggested format of dry-run DS record.
Another alternative idea: how about putting the Digest Type into the
first octet of Digest field like in the draft, but cropping (or
stretching) the rest of the actual digest in a way that the overall
size of the resulting Digest field is something "normal" (e.g. 32
octets), and does not differ based on actual Digest Type? I assume
that for dry-run, the weakened actual security of cropped Digest is
not a big deal.
Please consider my thought and employ/deny it as needed.
Best,
Libor
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
