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

[Randy Bush <[e-mail]>]

> You posed a MITM attack.

i did not think i described a middle for a monkey to inhabit.  when the
monkey uses its CA access credentials to cause the CA to sign some
document/object, it is the primary actor trying to fool you into
believing it is a rabbit.  so is the CA your middle?

> You instantiated it as a bank account fraud.  I tried to decompose
> your koan to identify the parties, and I draw the conclusion that the
> risk of fraud exists irrespective of the nature of the signed object,
> can be trivially instantiated from abuse of things signed, and demands
> the receiver and sender be naive respecting MITM risk, and draw false
> conclusions from the provable INR part of the signing.

i have absolutely no idea what that just said

> It is likely a ROA only harms the creator if abused.

depends on the form of abuse.  i think we have discussed a few hunred
times the problem where
  X owns 1.2.0.0/16 and announces that /16 from AS1
  X allocates 1.2.3.0/24 to their customer Y which Y announces from AS2
  neither creates a roa for 1.2.3.0/24-AS2
  X creates a roa for 1.2.0.0/16-AS1
  customer's announcement of 1.2.3.0/24-AS2 is now invalid

i.e. X's roa creation harms their customer, Y

> There is a risk an RTA or RSC signed statement harms the receiver or
> some third party.

like a roa, only if they foolishly believe it applies to anything other
than the inrs whose certs were used to sign the statement/roa.

> If the transaction is like BYOip, and the receiver defines the form of
> data to be signed and some suitable nonce or hash to be over-signed, I
> think its starting to look safer.

i am not sure what over-signing means.  but yes, if i can convince a CA
to sign something using the key for some inr, then you can probably
trust that something to speak for that inr.  e.g. if you sign a document
with the key for AS42, you can probably trust what it says about AS42;
although not anything about the unidentified 'owner' of AS42 or her
wife.

> I believe we all agree the RPKI does not prove identity.

i said nothing about prove.  imiho, the rpki can not authenticate real
world identities at all beyond than the inrs in the 3779 glorp.  this is
not supposed to be a complex concept.

> I would say that use of RTA and RSC, is to bridge signed provable
> assertions about INR, to some other space. What that space is, and how
> it is proved, lies between the receiver and the sender (of that
> bridged, signed assertion).

and if you believe that, i have this bridge

> Ideally defining new signed object types would be easy. I don't think
> it is, the initial proposing is fine, its closure to a registry in
> process which takes forever.

i have no idea what that means.  i think we have all had the fun of
defining a new object type, see RFC6488

> RTA and RSC also help bootstrap ideas which probably emerge as
> specific ASN1 defined objects with structure fit for purpose.

> There is an argument to be made that the hard test of what should be
> in the ASN1 and what it means is the necessary cost to avoiding risk
> like the MITM threat.

lost me again; but the bar is low

are you trying to say that rta and rsc are low cost hacks for avoiding
the pain of making 6488 derivative rfcs?

maybe so.  as long as we keep in mind that those hacks only authenticate
statements about the INRs whose certs were used to sign.

randy