Sorry - 1-3 new issues and commentary on the previous issue.
Expanding:
**** Please Clarify: The document does not state if this set of TAs is
additive to a relying party's existing TA set or replaces them.
**** Please Clarify: What happens if you provide a TA with a
"validUntil" in the future (say 2 years) and ICANN does not issue a
replacement? Is that TA marked as revoked at the expiration of the
validUntil? It appears to be - see both of the next quotes. This feels
like a "BAD THING".
The validFrom and validUntil attributes in the KeyDigest element
specify the range of times that the KeyDigest element can be used as
a trust anchor.
**** Please clarify:
Note that the validUntil attribute of the KeyDigest element is
optional. If the relying party is using a trust anchor that has a
KeyDigest element that does not have a validUntil attribute, it can
change to a trust anchor with a KeyDigest element that does have a
validUntil attribute, as long as that trust anchor's validUntil
attribute is in the future and the KeyTag, Algorithm, DigestType, and
Digest elements of the KeyDigest are the same as the previous trust
anchor.
I don't actually know what to do with this. Right now if you have
multiple TAs, ANY TA that is live may be used to provide the base of a
chain of trust. "change to a trust anchor..." is a no-op. This
section seems to be describing operational behavior past the first read
of the TA by a relying party which appears to be a change to how DNSSEC
operates.
Instead I suggest: "validUntil should be read as the planned last date
of signing by ICANN for that specific trust anchor. A relying party may
continue to accept validations that chain to this trust anchor past this
date unless the trust anchor is manually removed, or it is revoked."
If you want to actually revoke the key, use the 5011 scheme and include
the signature for the revoked key (by the revoked key over the revoked
DNSKEY formed as a singleton RR) in this file.
And I think "validFrom" also ought to be read as "validFrom is the
planned first date for ICANN to begin signing with this TA. A relying
party should not install this TA until the specified validFrom date, but
if it does, the relying party should treat validations that chain to
this TA that are otherwise valid, as valid regardless of the validFrom
date". e.g. We're not requiring a DNS implementation to track date/times
outside of the DNSSEC protocol.
Trimming...
On 8/15/2024 4:58 AM, Petr Špaček wrote:
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:
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?
Some preliminary stuff: RFC7958 was an independent submission - a "this
is how ICANN does this" document. This version of the document is
running through DNSOPS. The former version was discussed, but I don't
think it went through as rigorous a vetting.
1) Trust anchors in DNSSEC are the public keys, not DS or DNSKEY records
representing the public keys even though those records may be used to
carry the public keys. Among other things, the flags and tags of a
trust anchor may change (cf "revocation bit") during the lifetime of the
key and a naive implementation with only DS like trust anchors could
miss those changes. (Yes, we can argue about this and 4035 says that
DS's can be trust anchors - but 4035 assumed the flags would never
change and 4035 assumed that section 5.2 will also come into play with
respect to the DS records).
2) (1) basically implies that the hash you get from the XML may not be
comparable to an actual live key.
3) It also implies that the <KeyDigest> element needs a <Flags> element
as well - or at least for keys that are not included in the
<TrustAnchor> element. (e.g. use the KeyDigest Flags field to calculate
the digest over the public key regardless of what the DS or the live key
says).
To answer your question: The attack scenario is more a "someone screwed
up and the key we just published didn't match up with the hash in the
TrustAnchor file we published last month".
But I guess It could also be a malicious denial of service by an insider
- especially if none of the keys have been published or included, and it
*could* be an attempt to install a fake public key - harder to detect if
all you have is the hash and all you're doing is attacking a few targets
between the time the TA file is published and the keys are published.
If the party relying on the TA file just accepts it at face value (after
verifying the signature), an attacker with the related private keys and
ability to cut in between for DNS could do a pretty good job of lying to
their target.
The security considerations section should actually discuss the various
ways a third-party (ICANN) signed version of trust anchors could be used
to pollute trust anchor stores if various internal controls aren't
maintained. It should also discuss how a relying party can validate the
"consistency" of the data not just the signature over the data.
And - IMHO - a relying party should not finalize adoption of a given TA
until it sees it live.
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.
As I said a minor nit and not a hill I want to die on. But your last
comment: XML parsers either know how to do all of the xsd: stuff or none
of it. Converting from an xml parsed 2 byte field into a UINT16 is a
line of code.
Later, Mike
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
