Re: [Sidrops] adopt draft-ymbk-sidrops-rpki-has-no-identity please

[George Michaelson <[e-mail]>]

On Wed, Mar 24, 2021 at 12:25 PM Randy Bush <[e-mail]> wrote:
>
> >>> When someone asks me to put a string into a webserver file or into my
> >>> DNS zone file to "prove" I have administration access, they don't want
> >>> to identify me, they just want me to prove I already have access to
> >>> the resource at the "business end" of it.
> >>
> >> usually because dns is the purpose of the exercise
> >>
> >>> RSC is the same thing, I prove I can create ROAs and/or RSCs
> >>
> >> as sra would say, you can demonstrate that the same unknown attacker
> >> can create objects.
> >
> > The attacker has access to private keys behind the specific INR. We
> > have bigger problems than the one here, Surely?
>
> indeed.  some are proposing to grant them access to someone's bank
> account because they can sign some roa

I think what you are asked to sign over should be crafted either along
with, or by the person who is going to have to act on it. If you need
the statement to be conditional on proof of control of some INR, you
would want a cryptographic test of the proof of control of the INR.

"Randy say's he's your agent in this transaction. I need to see an INR
signed assertion you want Randy, identified by this information <here>
to be the one who says what is to be done wth this INR"

If you, the signer didn't check what the <here> was and what the INR
was, and who was saying this, You're being gamed all the way along the
path. This had to be in a trustable channel surely?

Remember this starts in BYO. You're deep inside AWS provisioning with
a bPKI keypair anchored in AWS, doing JSON/Post stuff, when you're
asked to assert an RSC or RTA signed blob back inside that protocol so
they can have high confidence. To be the MITM, you've owned the entire
supply chain bootstrapping into AWS.

>
> > (or, can you show me the attack vector, which does not imply loss of
> > privacy over a public-private keypair?)
>
> we have been over this multiple times, george.  read the draft

It's helpful to be explicit. The MITM risk flows two possible ways.
There is the signer, the person who makes the RTA/RSC, and there is
the recipient. A MITM can be attacking either or both.

The case you appear to be arguing, is the attack on the bank: the bank
is led to believe the MITM is authorised to do things, because they
show the signer countersigned a token, which they passed over to be
signed, claiming some spurious reasoning why the signer should sign.

I am wondering how this differs from a MITM asking a signer to make a
specific ROA, and presenting it forward as proof to some entity (the
bank in this case) -And the only part I can see which differs is the
public nature of how ROA are currently made: that it appears on a
Manifest, and is in a repository. But I don't understand how that
mitigates the attack.

Unless I've missed something, you can do this MITM attack with ROAs,
if you take a ROA as proof of agency over resources right now: Which,
is what BYO does for some people.

This reduces to the statement "its only applicable to BGP" but doesn't
actually remove the MITM risk: a MITM can make people believe you want
an outcome by mediating the dialogue leading to the making of the
outcome.  Are there no attacks on the integrity of routing, which
leverage the "wrong" ROA being asserted? At a guess, the primary ones
go to the INR holder, So, its the "other" party in the MITM attack.
That's the difference.

Otherwise, its an attack on the integrity of the supply chain bPKI, or
it is completely absent, its an insecure supply chain transaction.  I
don't see that RSC or RTA increased risks, of choosing to do a
provisioning exchange relevant to INR over an insecure path.

cheers

-G


>
> randy