Re: [secdir] Secdir review of draft-ietf-sidr-res-certs

[Sam Hartman <[e-mail]>]

>>>>> "Paul" == Paul Hoffman <[e-mail]> writes:


    Paul> I don't think either of us is missing something, we just
    Paul> disagree about what needs to happen if a fix that changes the
    Paul> semantics of the certs needs to be made to the system as a
    Paul> whole. For changes that don't change the semantics, you change
    Paul> an existing extension or other part of the certificate; for
    Paul> changes that need to change the system's semantics, you change
    Paul> the certificates in a way that relying parties that don't
    Paul> understand the change won't accept the certificate.

    Paul> Maybe you and I are envisioning different choices being made
    Paul> about those changes. I trust the IETF not to make a change
    Paul> that will cause a lot of relying parties to fail unless the
    Paul> IETF really thinks that is necessary; you may have less faith
    Paul> than I do. (You were on the IESG, so you get to be in the
    Paul> sausage-making more than I have...)


I do trust the IETF, which is why I think the current document is very
broken.  I want to give the IETF the *future* opportunity to balance
breaking RPs against confusing behavior.

I hate to get into a specific example, because it's very easy to attack
the example without the general point. However in the interests of
trying to explore our difference, I'd like to come up with a specific
example. I may drop the discussion if I feel that we're focusing on the
example rather than the general point.

So let's pretend that we'd been much more efficient about SIDR and that
the RPKI was done prior to 32-bit ASes being a significant issue.  Let's
pretend that RFC 3779 managed to specify the AS constraint in such a way
that 32-bit ASes were excluded. Perhaps there is an ASN.1 constraint on
the size of the AS that happens to be rigorously enforced by widely
deployed RPs.
Regardless of how it happened, assume that we cannot encode 32-bit ASes
in the existing extension.

In the current model, we have to come up with a new extension.
I think this means you need a new independent CA hierarchy for the
32-bit AS certificates. New RPs can use that hierarchy for 32-bit
ASes, all RPs use the old hierarchy for the 16-bit AS certs and to
the extent they are combined IP certs.
In theory we could some day combine these hierarchies when all the RPs
support 32-bit ASes. In practice we probably wouldn't because someone
out there would implement an RP that broke when the hierarchies were
combined and even though it would simplify things the risk of breakage
would not justify combining the hierarchies.

I'm not sure if this model works: I'd need to analyze whether you can
have multiple signatures on an RPKI object, whether you need to claim
both an AS and an IP address in signing a route, etc etc.  If we're
going to go forward with the current model we need at least convince
ourselves that even if we did have to duplicate the RPKI to deploy some
feature we could do so and not also duplicate the instances of the
protocols signing RPKI objects.

However, if we had a relaxed model, we'd give the IETF another option.
The IETF could also provide a new version of the AS extension for 32-bit
ASes.  There are huge tradeoffs here.  Only new RPs will validate the
32-bit ASes. So you can get into a situation where an RP who is unaware
of 32-bit ASes accepts a certificate that a newer RP would
reject. However, the 16-bit ASes in that certificate would validate. The
IP addresses in that certificate would validate.  An appropriately
authorized trust anchor would need to create a certificate with a valid
certification path that passed all the checks in the old profile.  Such
a certificate could only be used by an old-profile RP to validate
objects permitted under the old profile. An RP that understood 32-bit
ASes would be required to understand the 32-bit AS validation.

I don't know what the right choice would be in this situation.
However in similar situations I'd prefer to make that choice in the
future when the IETF is in a position to evaluate the tradeoffs rather
than forcing our hand now.

Similarly you could imagine a desire to add information to a certificate
for auditing, debugging or the like, where validation rules were not
changed. Again, I'd prefer to allow the IETF to decide whether breaking
RPs should be required to make such changes in the future rather than
now.  

Again, because of extension criticality, we always have the option to
force RPs to reject new things they don't understand. The question is
whether we want options beyond that.