None of those who believe that this draft is a good thing seem to have
addressed
an issue I raised a while ago; the proposed solution is ill-defined and,
the most
likely interpretation doesn't seem to work, in general. I'll try to
explain this
reasoning, again, and provide an example.
Section 2 of the I-D says:
Validation of signed resource data using a target resource
certificate, and a specific set of number resources, consists of
verifying that the digital signature of the signed resource data is
valid, using the public key of the target resource certificate, and
also validating the resource certificate in the context of the RPKI,
using the path validation process.
Personally, I have trouble understanding what that 5 1/2 line sentence
means,
in no small part because the phrase "signed resource data" is not defined
anywhere in the I-D. The text that follows reproduces, with one
exception, the
path validation description from 6487, so I assume that the text is
proposing
a change to that path validation process.
PowerPoint Presentation
The one change made to the path validation procedure in RFC 6487 arises
in step 6, which is reworded to be:
The resource extension data contained in this certificate
"encompasses" the entirety of the resources in the specific
resource set ("encompass" in this context is defined in
Section 7.1 of [RFC6487]).
PowerPoint Presentation
PowerPoint Presentation As I noted before, the phrase "_specific_
resource set" is undefined in the I-D.
I'm guessing that many folks believe this term refers to any address
space and ASN
extensions in the cert being validated. That's a simple, reasonable
interpretation
of the text, and the authors have not stated a different intent, so
let's proceed
on that assumption. Consider the following example that, WLOG, focuses
only on
address space.
Consider a cert path from a trust anchor TA, to CA1 to CA2 to an EE cert
for a ROA.
TA->CA 1->CA 2->ROA
Assume the TA cert contains address space T, U, V, W, X, Y and Z.
Assume the CA 1 cert contains address space T, U, V, and W.
Assume the CA 2 cert contains address space V and W.
Let's say that the ROA EE cert issued by CA 2 contains address space V.
CA 2 is about to receive address space Z from some other ISP, so it has
asked
CA 1 to issue a new CA cert to it, in anticipation of the transfer. CA 1
agrees,
and issues a new cert to CA 2 and that cert contains address space V and Z.
Now, under the assumption about what "specific resource set" means, when
an RP tries to validate CA 2's ROA, the "specific resource set" will be
V, and
so it will be valid, because V is in all of the certs from the TA
through CA 1
to CA 2. Even though CA 2's cert contains Z, which is not contained
in CA 1's cert, this will not be considered in the validation of the ROA
EE cert.
This is the desired outcome, because CA 2 has begun the process of
getting its
new address space (Z), but that process has not broken its CA cert. I
assume this
is an example of the reduced fragility that is so appealing.
If CA 2 issued a ROA for Z, then validation of that ROA would fail, because
the CA 1 cert does not contain Z. That's good, because the second ROA
exmaple
ought not be valid, since the transfer has not yet completed.
So far, so good. But, let's look at the implications of this revised
validation
procedure in greater depth.
What if CA 1, acting on the request from CA 2 asked the TA to add Z to
CA 2's cert,
in anticipation of the transfer? Then we have a problem, because Z is
under the
tree from this TA and if it agreed to add Z to CA 1's cert, then a ROA
for Z,
issued by CA 2, would be valid, even though the transfer had not yet
been effected.
So, when folks claim that this alg allows for transfers to not have to
follow
a strict ordering of RPKI actions, that is only partly true. Issuing a
new CA
cert with resources not yet transferred to the target can actually
enable the
target to generate bogus ROAs that will validate, unless certain precautions
are taken. Every CA has to be sure that IF it issues a cert to a
subordinate
because of an anticipated transfer, that this act does not enable the
subordinate
(or a child of the subordinate ...) to issue bogus ROAs! Right now we
have no
agreed-upon resource transfer process for the RPKI, to ensure that this
sort of
vulnerability does not arise. Yet the suggestion is to change the
validation
procedure before having such a process in place. Not such a good idea.
A bigger problem, IMHO, is that if an RP validates CA 2's (new) cert,
the "specific resource set" will be V and Z (according to the interpretation
cited above). However, using the revised step 6, validation will fail,
because CA 1's cert does not contain Z. To avoid this problem, RPs would
have
to not validate CA certs that might contain address space that is not
present
in _all_ the certs along the path.
This is a bad outcome, for two reasons. An RP should validate each CA
cert it
fetches, to minimize opportunities for DoS attacks. An RP also should
be able
to maintain a local cache where it need not walk the whole path to a TA
every time
a new cert (of any type) appears. Note, for example, that new manifest
certs
are issued daily. So, if one tries to take advantage of the reduced
fragility
promised by this change to step 6, a CA cert with resources not present
in all
if its parent certs will fal validation anyway. Not such a great outcome.
Also recall that new CRLs tend to be issued at least daily. To validate
a CRL
an RP uses the public key from the CA cert under which the CRL was
issued. That
implies the RP has validated the CA cert before using the public key
from it.
Yet, as noted above, if the CA cert has address space not contained in
all of its
parents, that cert will be invalid. So, RPs would have to treat CRL
validation
as a special case, using a public key from a CA cert that has not been
validated
relative to the revised process, to avoid this problem. Again, I see this as
not a great outcome, as it introduces additional complexity into the
validation
process.
The bottom line is that the revised path validation algorithm, as
(ill-)defined,
does not work the way many folks seem to believe. I fear folks have a
vague notion
about what the revised validation algorithm is, and they like the
benefits it
claims to offer, but they have not examined in detail exactly what the
I-D says
and what that means in practice. That's why I suggest that the new
editors of
the I-D need to revise it, address the ambiguities, and then the WG can
decide
whether the resulting document is worth pursuing.
Happy turkey day,
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
