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

From: Valery Smyslov via Datatracker <[email-masked]>
Date: Wed, 30 Mar 2022 06:51:29 -0700

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?

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.

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). 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?

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.

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.

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?

I also wonder how algorithm agility property is achieved for broadcast RID
messages.

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 30 Mar 2022 10:47:13 -0400

I am taking a quick response here, and will have to go over it more 
closely for a second pass.

> 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

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.

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.

So recapping, change first SHOULD to MUST.  Other SHOULDs are correct.

> 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.

> 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.

> Finding another key pair that hashes to the same hash

Unfortunately you have to see:

draft-ietf-drip-rid-17 sec 10.

> 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.

> suggest to discuss physical security in a separate subsection of Section 9.

? other authors?  chairs? advise please.

> 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.

> I also wonder how algorithm agility property is achieved for broadcast RID

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.

I hope this helps.

---

From: <[email-masked]>
Date: Wed, 30 Mar 2022 15:45:02 +0000

Hi Valery, Bob, 

Many thanks to Valery for the review. 

(focusing on point 3) 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Robert Moskowitz <[email-masked]>
> Envoyé : mercredi 30 mars 2022 16:47
> À : Valery Smyslov <[email-masked]>; [email-masked]
> Cc : [email-masked]; [email-masked]; tm-
> [email-masked]
> Objet : Re: Secdir last call review of draft-ietf-drip-arch-22
> 
> > 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.
> >

> > If I understand the draft correctly, the size of public key hash is 20
> > or 19 octets (Section 3.1).
> 

[Med] The initial point was to record the potential security consideration that should be further examined in the solution spec. I'm not convinced we need to call out solution-specific details (e.g., 64 bits) here or call out ietf-drip-rid.  

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 30 Mar 2022 15:15:40 -0400

> the directions in which they are planned to be determined should be present.

Revocation is done with a hammer.
(Insert picture of Hulk smashing drone...)

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 31 Mar 2022 11:12:21 +0300

Hi Bob,

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

> Broadcast RID MUST be provisioned

OK.

> 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...

> does diagram validation services.

Agree.

> be able to include this as an example for revocation, but only an

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.

> 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.  

> 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.

> made to consider what other results would look like.

OK.

> 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.

---

From: "Card, Stu" <[email-masked]>
Date: Thu, 31 Mar 2022 20:50:18 -0400

Valery --

Thanks for the review! As you have already seen from the preliminary
responses, we are collectively working on addressing all your points. Here,
I would like to address just one, from a different perspective. So below I
will snip your mail down to just that one point.

We included, in the Security Considerations section, the idea of a large
malicious UA carrying a small and seemingly harmless UA as a false flag. We
did not put this idea in there because we felt that mitigating such
vulnerabilities was in scope of IETF. We put it there to forestall some of
the discussion that would otherwise ensue about protecting private keys
that could be used for spoofing. As a device (small UA) containing a
private key can be physically carried by another device (large UA), there
is no way clever key distribution/management/protection can prevent one
device spoofing generally as another such readily available device. This is
quite distinct from preventing a device from spoofing as a _specific_ other
device: with DRIP, Carol's UA cannot successfully pretend to be Bob's UA.

Your review suggests, to me, that we should make the above reasoning
explicit in the draft.

On Wed, Mar 30, 2022 at 9:51 AM Valery Smyslov via Datatracker <
[email-masked]> wrote:

> ...

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 1 Apr 2022 09:16:31 +0300

Hi Card,

I don’t disagree with you. My point was that it’s better to discuss scenarios involving physical actions with devices

in a separate subsection in the Security Considerations section. Just because they are very different from security

point of view. And it will also be helpful if you make your reasoning explicit.

Regards,

Valery.

From: Card, Stu [mailto:[email-masked]] 
Sent: Friday, April 01, 2022 3:50 AM
To: Valery Smyslov
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Secdir last call review of draft-ietf-drip-arch-22

Valery --

Thanks for the review! As you have already seen from the preliminary responses, we are collectively working on addressing all your points. Here, I would like to address just one, from a different perspective. So below I will snip your mail down to just that one point.

We included, in the Security Considerations section, the idea of a large malicious UA carrying a small and seemingly harmless UA as a false flag. We did not put this idea in there because we felt that mitigating such vulnerabilities was in scope of IETF. We put it there to forestall some of the discussion that would otherwise ensue about protecting private keys that could be used for spoofing. As a device (small UA) containing a private key can be physically carried by another device (large UA), there is no way clever key distribution/management/protection can prevent one device spoofing generally as another such readily available device. This is quite distinct from preventing a device from spoofing as a _specific_ other device: with DRIP, Carol's UA cannot successfully pretend to be Bob's UA.

Your review suggests, to me, that we should make the above reasoning explicit in the draft.

On Wed, Mar 30, 2022 at 9:51 AM Valery Smyslov via Datatracker <[email-masked]> wrote:

...