On 10. 08. 24 17:21, Michael StJohns wrote:
On 8/9/2024 5:09 PM, Paul Hoffman wrote:
On Aug 9, 2024, at 12:16, Michael StJohns<m...@nthpermutation.com> wrote:
Two comments - one major and one very minor.
Major: I'm sorry for the late comment, but I didn't realize you were planning on
starting to provide prospective DS's for unpublished keys. Telling people there's a new
trust anchor, and that the live key matches this file is one thing - easy enough for a
relying party to match up a few things and accept the TA update. Telling them there's an
unpublished key and "trust me, when you see it it will have this digest and you
should go ahead now and install it in your trust anchors" seems to be a bit more
risky.
This is unchanged from RFC 7958, published in 2016. It was done for the key
rollover to KSK-2017. If you propose to change this activity now, I propose
that you take this to IANA; the current draft and RFC 7958 reflect IANA's
long-established policies.
Paul - this is related directly to the newly specified inclusion of the
public key material in this draft (sect 3.2 last para):
A KeyDigest element can contain both a Digest and a publickeyinfo
named pattern. If the Digest element would not be a proper DS record
for a DNSKEY record represented by the publickeyinfo named pattern,
relying parties MUST NOT use that KeyDigest as a trust anchor.
Prior to this there was no check on the correctness of the offered
digest, except that a smart relying party could have looked at the
published keys and tried to find a match. After this is published as an
RFC, the relying part mostly only needs to look at the public key data
in the file if it exists and not worry about whether it was published.
This is not "unchanged from RFC 7958" IMO. Finally, reading this, why
wouldn't you explicitly specify that the hash needs to be (e.g. MUST
be) verified against either a live (published) key or the included
public key? Trust anchors require - well - trust. I would think that
the more verification I can get to avoid polluting my personal trust
anchor store, the better.
Looking at the Security Considerations - I don't think the updates to this
section made this is sufficiently evident.
That's because this part of RFC 7958 was not updated in this draft.
See above.
I'd suggest two things: 1) Talk about the above in the security
considerations, and 2) Place a disclaimer in the TA file with similar language
about the prospective key material.
From my perspective sect 3.2 last paragraph (quoted above) is
sufficient to catch errors in data representation within the XML and
with that protection we IMHO are in the same state as we were before:
The relying party has to trust content of the file (for some reason).
Maybe I'm missing something. Do you have a particular attack scenario
which have not been possible before but becomes possible with the new
format?
Minor minor minor nit - feel free to ignore this:
The flags field for the DNSKEY is represented in most DNS presentation modes as
an unsigned decimal integer - but it's actually a bit field of two bytes. The
representation is used mostly because that's what a DNS Zone File used (e.g.
either Base64 or a decimal integer) for most non-text fields. Unclear decimal
should be used for XML.
Section 2.2 of RFC 4034 says "The Flag field MUST be represented as an unsigned
decimal integer."
RFC 4034 2.2 is talking about DNS RR Presentation format, not XML. In
any event, section 2.1 represents the flag field as 2 8-bit bytes so
equal support for either approach.
It may make some sense here to use <xsd:hexBinary { length = 2 }/> is the field type the
appropriate mapping here - <Flag>0101</Flag> instead of the decimal 257. Easier to
see what bits have been set.
That would then be different than the KeyType, Algorithm, and DigestType fields
that are expressed as xsd:nonNegativeInteger. If the WG wants to make this
inconsistent, it can, but I would generally be against that.
KeyType, Algorithm and DigestType are all enums - Flags is a bit field.
What's more inconsistent is 4034 treating the flags field as an unsigned
number, but reasonable enough as few if any other RR presentation fields
are flag fields. (I can't think of one... but with all the myriad RR
types, I'm sure someone has built one).
As I said - minor nit. Sometimes when you're reencoding data from one
scheme to another you need to have these polite conversations and
actually consider the circumstances.
As an implementer I say it's easier if the format is the same as in DNS,
i.e. unsigned decimal number. It allows me to simply reformat elements
from the XML into a DNSKEY text representation and _then_ run existing
DNS code to parse the (reformatted) DNSKEY text.
Bit field represented as sequence of ASCII 0/1 would require additional
code and I don't see any benefit. Common DNS tools display Flags field
as an integer value so even for manual cross-checking by hand (say XML
text vs. dig output) it is better to use the same representation.
--
Petr Špaček
Internet Systems Consortium
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
