On 02. 08. 24 16:40, Paul Hoffman wrote:
THanks for keeping in on this!
On Aug 2, 2024, at 02:14, Petr Špaček <pspa...@isc.org> wrote:
On 02. 08. 24 2:41, Paul Hoffman wrote:
On Aug 1, 2024, at 06:37, Petr Špaček <pspa...@isc.org> wrote:
snip <<< I removed the parts where we understood each other.
On 01. 08. 24 2:28, Paul Hoffman wrote:
2.4. Converting from XML to DNSKEY Records
The published trust anchor does not provide values for DNSKEY protocol or
flags. For the purpose of this mechanism, clients can assume valid trust
anchors will be have the ZONE and SEP flag bits set to 1.
I think it is extremely bad idea to ignore fields, especially Flags. There are
various proposals for new DNSKEY flag usage in the DD WG.
Even if we say that DD WG will go down in flames before it produces anything I
think it's_extremely_ bad idea to omit pieces of information and assume that
client can reliably fill in missing pieces with constants. I would say that the
missing DNSKEY fields really really must be represented explicitly. (E.g. I
don't want to go down the rabbit hole of all REVOKE flag corner cases.)
I don't understand how the quoted text suggests that users of the zone file
ignore fields or flags. Can you suggest text to fix your concern?
Specifically:
clients can assume valid trust anchors will be have the ZONE and SEP flag bits
set to 1.
This text ignores all non-{ZONE,SEP} flags. Readers have no instruction about
the _other_ flags, and in a hypothetical future, TA can conceivably have one or
more of these extra flags set. E.g. a new flag for DELEG downgrade resistance
which is under discussion in the DD WG. Will we need update the format again?
(I think that would be wrong.)
I think absence of explicit Flags field is unnecessary shortcut which will just
bite us down the road (or force document & software update).
I'm still not understanding the need here. The flags are included in the
calculation for the DS record, which is mandatory in the file format.
Here are two examples where missing Flags cause trouble:
Example 1. Imagine that one of the historical TAs will get revoked. Revocation
sets REVOKE bit=1, along with a validUntil date set to the past. Now the
current format would contain DS hash which does not match the reconstructed
DNSKEY RR.
It sounds like you assuming that IANA would change the DNSKEY by setting the
Revoke bit, but not update the trust anchor. That is possible, but it seems
unlikely to me.
Would it be sufficient for you if the document was updated to say "If IANA
makes any change to the DNSKEY record for a trust anchor, such as a change in a
flag, IANA MUST update the trust anchor file to reflect this change.
No, I think there's still a misunderstanding.
I'm trying to say that the format as proposed currently _does not have
the ability_ to express REVOKE or any other non-{ZONE,SEP} bits - and
this causes internal consistency issues in the data format between DS
and the DNSKEYs _regenerated_ from individual XML elements.
Perhaps I'm missing something...
Could you please share an example of XML which shows one TA with bits
ZONE+SEP+REVOKE set to 1 such that all data fields of the XML are
internally consistent? I.e. DS hash must match the DNSKEY reconstructed
according to the current text.
That example would clearly demonstrate that I'm wrong.
Standardizing a format which by definition leads to internally inconsistent
data fields sounds like a had idea to me.
Fully agree.
Example 2. Non-REVOKEd flag - based on draft-ietf-dnsop-delegation-only-02.txt:
Say that a future TA has DNSKEY flags ZONE + SEP + DELEGATION_ONLY set to 1.
Such TA cannot be represented correctly as DNSKEY using the proposed format
because the proposal assumes only ZONE + SEP bits are ever set to 1. Again, DS
hash and the reconstructed DNSKEY would not match.
In other words, the current proposed format ossifies DNSKEY flags for TAs.
...only if IANA doesn't update the trust anchor file, I believe. Please see the
above proposed addition.
No, I'm trying to say that IANA has no way to publish such TA in the
currently proposed format. Of course unless IANA decides to not publish
publicKey element, but doing so would be contrary to the implicit
requirement of supporting software which needs full DNSKEY format.
Again - if this _can_ be done please share a XML excerpt to demonstrate
it. I promise I will shut up when I see fully consistent XML which can
represent such TA.
My proposal is to do one of:
a) get rid of PublicKey element completely (see below)
b) include explicit XML element with Flags - and when we are at it we can add
Protocol element as well for completeness.
On high level I also find confusing that the new element is optional - that
makes it unreliable for consumers because there are no rules for when it might
or might not be present.
It is optional because some signing mechanisms don't automatically generate
DNSKEY values. For example, the current trust anchor file only has the DS of
KSK-2024 because IANA needs to make a software change to get the DNSKEY (which
it will do in a few months). Other HSMs might be similar. A DS has always been
sufficient; a DNSKEY would be an upgrade, but is not necessary.
A trust anchor with nonexistent DNSKEY representation is not usable in DNSSEC
because nobody can validate signatures made with it, is that correct? If so,
why such keys need to be represented in this format?
An alternative angle:
Why is the new PublicKey element even needed? There's no guarantee it will be
ever present which makes it unusable - no software can _rely_ on it's presence.
I.e. it does not seem useful while it introduces new nasty corner cases.
Or yet another wording of the same problem:
Under what conditions software reading file in this format _needs_ the
PublicKey element and cannot do with the mandatory fields?
Some software vendors complained that they needed the full DNSKEY for the trust
anchors. They could not use the file: they had to wait for the DNSKEY records
to appear in the root zone. At least one of those vendors scraped the ceremony
materials to find the DNSKEY to use as their trust anchor before the record
appeared in the root zone.
Fair enough, I can imagine that. But then the question is:
Why is the field _optional_ (besides problem with missing Flags)? That renders
the proposed format potentially unusable (or at least unreliable) for the
software which cannot work with DS only.
It is optional because there is no guarantee that IANA will know the DNSKEY for
a trust anchor when it first knows the DS. That is true today, and will be true
until mid-October this year. It could be true again in the future.
I find
It can be useful when IANA has a trust anchor that has not yet been published
in the DNS root.
too vague to justify that we need the _optional_ PublicKey element which might
or might not be present, with and all the trouble it adds.
That might be true for your own implementation, but it was requested and
accepted by the WG.
Or maybe it was just an oversight? dnsop archives here:
https://mailarchive.ietf.org/arch/browse/dnsop/?q=rfc7958bis*20publickey do not
show any discussion of publicKey element _semantics_, or it's purpose, or when
and why it should be present.
Perhaps my dnsop filter is incomplete and there was a discussion I could not
find?
I thought it was requested earlier than us starting this draft, which is why it
appeared in the -00 draft.
I don't want to be seen as a formalist, but that probably caused the WG
to just glance over it. There's no sign of anyone discussing the
publicKey field - so we are having the discussion now.
--
Petr Špaček
Internet Systems Consortium
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
