Re: [secdir] Secdir last call review of draft-ietf-drip-arch-22

[Valery Smyslov <[e-mail]>]

Hi Bob,

thank you for prompt reply, please see my comments below.

> I am taking a quick response here, and will have to go over it more
> closely for a second pass.
> 
> On 3/30/22 09:51, Valery Smyslov via Datatracker wrote:
> > Reviewer: Valery Smyslov
> > Review result: Has Issues
> >
> > The topic of the draft is complex and involves many fields which I'm not expert
> > of. The overall architecture looks secure, however it's difficult for me to
> > analyse all the details. Nevertheless, it seems to me that there are some
> > security issues with the draft.
> >
> > 1. Section 3.2
> >
> >     A UA equipped for Broadcast RID SHOULD be provisioned not only with
> >     its HHIT but also with the HI public key from which the HHIT was
> >     derived and the corresponding private key, to enable message
> >     signature.  A UAS equipped for Network RID SHOULD be provisioned
> >     likewise; the private key resides only in the ultimate source of
> >     Network RID messages (i.e., on the UA itself if the GCS is merely
> >     relaying rather than sourcing Network RID messages).  Each Observer
> >     device SHOULD be provisioned either with public keys of the DRIP
> >     identifier root registries or certificates for subordinate
> >     registries.
> >
> > I wonder why SHOULDs are used here and not MUSTs. In which cases it's OK not to
> > equip e.g. UAs with private keys and how they will perform digital signatures
> > in this case? Am I missing something?
> 
> Good catch.  Thanks.  All too often you read things so many times that
> points like this just slip by and this is why we have last calls...
> 
> Broadcast RID MUST be provisioned

OK.

> As our whole architecture is to prove the Remote ID ownership in
> messages broadcasted from the UA and that needs to private key...
> 
> Note for Network RID, it is not so simple.  It may be that the GCS does
> all the signing for NRID messages, having its own trusted link to the UA
> to get the data to proxy.  This is why SHOULD for NRID is appropriate.

I think that having "trusted link" assumes that UA has some private key to authenticate 
information it sends to GCS. Well, I understand that this may be a different key...

> And SHOULD for Observers is correct, as an Observer might be using a
> verifying service, rather than directly validating the messages. Our
> position is direct validation on by the Observer is preferred, but ASTM
> does diagram validation services.

Agree.

> So recapping, change first SHOULD to MUST.  Other SHOULDs are correct.
> 
> > 2. It is not clear for me how revocation is done in case the private key of UA
> > is compromised. While the Security considerations section states that
> > revocation procedures are yet to be determined, I think that some text about
> > the directions in which they are planned to be determined should be present.
> 
> Since these are raw keys, revocation is not directly possible.  The
> drip-registry draft may evolve various methodologies for providing
> revocation information.  At this writing, we would be really
> speculating.  Perhaps, black-holing in DNS; if a DET has been revoked, a
> DNSSEC protected response on looking up the DET would say so.  We might
> be able to include this as an example for revocation, but only an
> example at this point.

I see. I still think that architecture document should have some text
about revocation (even if the text is speculative) in the main body,
i.e. where the architecture is defined. Just to show readers that
revocation is in scope of architecture and will be addressed later.

> > 3. Section 9.
> >
> >     The size of the public key hash in the HHIT is also of concern.  It
> >     is well within current server array technology to compute another key
> >     pair that hashes to the same HHIT.
> >
> > If I understand the draft correctly, the size of public key hash is 20 or 19
> > octets (Section 3.1).
> 
> The architecture document does not detail the format of an HHIT.  It
> turns out that in draft-ietf-drip-rid, the hash size is 64 bits so this
> attack is real and details about it are in the Security Considerations
> of that draft.  Perhaps say:
> 
> The size of the public key hash in the HHIT (64 bits) is also of concern
> 
> ?  Do we need to reference ietf-drip-rid?  We really do not want to do
> that is it creates delaying dependencies.

Oh, I now see, for 64 bits it is really possible to find second preimage. 
Perhaps the text can be modified along the lines (with no specific details about solution spec
as Med advised):

   Depending on the selected size of the public key hash in the HHIT,
   it may be well within current server array technology to compute another key
   pair that hashes to the same HHIT.  

> > Finding another key pair that hashes to the same hash
> > requires second preimage attack, which must take in this case 2^160 or 2^152.
> > In my understanding of the state-of-art, it's still beyond possibilities of
> > current computers. Am I missing something?
> 
> Unfortunately you have to see:
> 
> draft-ietf-drip-rid-17 sec 10.
> 
> > 4. The Security Considerations section is silent about possible impact of
> > Cryptographically Relevant Quantum Computers. While it's not clear whether such
> > computers will be ever build, the proposed architecture looks fragile with
> > respect to them. First, from my understanding the architecture, private/public
> > key pairs in UA are relatively long-lived and difficult to update. This gives
> > an attacker plenty of time to break them and once they are broken, enough time
> > to exploit. Second, the impact of breaking can be substantial due to the nature
> > of UA (a potentially dangerous object). Third, while many protocols involved in
> > this architecture can be upgraded with quantum safe cryptographic primitives,
> > it seems to me that for some pieces it will be really challenging (e.g. the
> > draft discusses limitations on payload size for Bluetooth, which will be more
> > severe with PQ cryptography with much larger keys and signatures). I think this
> > issue must be addressed somehow, at least mentioned.
> 
> Intentionally so.  We could get lost in the weeds.  We are extremely
> size and computing constrained and current QSC is just not providing
> solutions.  IF such a crypto suite is invented, it can be slotted in, as
> we have designed for crypto-agility.  Also, we do not spell it out, but
> we do say that a DET may be used for only a single 'operation' (flight
> to us non-UAS operators).  Thus a concerned implementor could use a
> fresh DET, making the exposure for only the duration of the operation.
> We do not spell this out, as there are other operational reasons for a
> UAS operator to constantly change DETs.

I think that the document will benefit if you mention in the Security 
Considerations that quantum security is intentionally out of scope
(perhaps with some of the reasoning you provided). 
Otherwise it looks like this is overlooked.

> > 5. While an example when one UA physically steals UAS RID sender of another UA
> > is clever, I think that such scenarios (physical security) are not in scope of
> > IETF work. I believe that many others similar schemes can be invented, so I
> > suggest to discuss physical security in a separate subsection of Section 9.
> 
> ? other authors?  chairs? advise please.
> 
> > Not related to security:
> >
> > Section 3.2:
> >
> >     A self-attestation of a HHIT used as a UAS ID can be done in as
> >     little as 84 bytes when Ed25519 [RFC8032] is used, by avoiding an
> >     explicit encoding technology like ASN.1 or Concise Binary Object
> >     Representation (CBOR [RFC8949]).  This attestation consists of only
> >     the HHIT, a timestamp, and the EdDSA signature on them.
> >
> > If no encoding is used then how extensibility is achieved?
> 
> Extensibility is in the HHIT which includes the Suite ID (Ed25519/cSHAKE
> here).  A different HHIT Suite ID will result in a differently
> structured self-attestation.  None exist right now, so no attempt is
> made to consider what other results would look like.

OK.

> > I also wonder how algorithm agility property is achieved for broadcast RID
> > messages.
> 
> As above the HHIT includes the Suite ID.  Note that the HHIT is an
> extension of the HIT in rfc7401 that also provided algorithm agility
> through the included Suite ID.

OK, good to know. My concern was that with broadcasts changing 
algorithms is operationally challenging - since there is no negotiation 
you should first upgrade all the receivers and only then start 
upgrading UAs.

> I hope this helps.

Definitely.

Thank you,
Valery.