Subject: [Iot-directorate] Iotdir last call review of draft-ietf-drip-arch-22

From: Thomas Fossati via Datatracker <[email-masked]>
Date: Sun, 27 Mar 2022 10:44:50 -0700

Reviewer: Thomas Fossati
Review result: Ready with Issues

This is a great document and fun to read.  Thank you authors!  I have
tried to highlight a few small things that could be articulated a bit
more from an IoT perspective but overall I have no major concerns with
it, except a tangential thing around the document intended status (see
"Issues" below.)

# Issues

* The charter says: "the WG will propose a standard document that
  describes the architecture […]" but the status is informational.  I am
  pretty sure informational should be appropriate, but highlighting a
  potential disconnect.

# Comments

* In some IETF circles (e.g., RATS & TEEP) "attestation" has a precise
  meaning, which is quite distinct from the DRIP definition "[…]
  normally used when an entity asserts a relationship with another
  entity".  Specifically, unless the signing key is derived from the
  measured boot state (a la DICE), or the claims are of a certain kind,
  the process that this doc names "attestation" is not what is meant
  usually.
   => Maybe add a few words to Section 2.2 to clarify the distinction
      between DRIP attestation and RATS's, e.g., by adding a disclaimer
      similar to that already associated with DRIP certs.

* Apropos "remote attestation", I am wondering whether, given the type
  of endpoints considered in the architecture - and in particular
  provided their increased exposure to physical compromise, and the
  potentially large impact on the overall system and beyond - the
  architecture should provide explicit channels for securely conveying
  the verification of the installed and booted firmware (as well as any
  other relevant trust metrics)?

* I haven't read the rest of the DRIP docs, so I am not sure why is
  EdDSA specifically mentioned in Section 3.2.?  Is this a requirement
  or just an example?  I guess the latter, but checking just in case.
  And apropos that, in light of fault attacks on deterministic ECDSA and
  EdDSA [0] that are potentially easier to carry out against UAs (BTW,
  how cool is a fault attack w/ private key exfiltration carried out by
  a chasing drone?) maybe it's worth adding to the security
  considerations some words around physical attacks and their impact
  on the choice of signature algorithms?

* It'd seem that, given the very low bandwidth, DoS (as well as Denial
  of View) attacks on communication involving the UA should be quite
  easy to mount?  Maybe worth spending some words on the argument
  to describe what the threats are and which mitigations are available.

* This is a question more than anything else: given the constrained
  nature of UAs, I was wondering whether it is envisaged that the
  end-to-end network path will be realised with the use of more capable
  (trusted) proxy nodes?  If so, there may be a few security and privacy
  considerations to be added.

# Nits

* AAA is usually intended as "Authentication, Authorization, and
  Accounting" (see also [1]), whereas here it's got four new A's:
  Attestation, Access Control , Attribution, Audit :-)
    => Maybe change it to 7A, A7, AAA+ or similar? 

* In Section 2.1, the following terms are already in the most recent
  "RFC Editor Abbreviations List" [1] and can be removed:
    * EdDSA
    * HIP
    * HIT
    * HI

* Some typographic inconsistency around Bluetooth: Is it 4 or 4.x?
  5 or 5.x?
    => Stick to one format. (Also maybe add an explicit reference to the
       Bluetooth specs.)

[0] https://eprint.iacr.org/2020/803
[1] https://www.rfc-editor.org/materials/abbrev.expansion.txt

---

From: <[email-masked]>
Date: Mon, 28 Mar 2022 06:48:22 +0000

Hi Thomas, all,

Thank for the review. 

Will focus on the issue listed below and kindly invite the authors to reply to the other points in a timely manner.

We went for informational rather than standard as initially advised in the charter because that's the right thing to do for such a document. We don't have valid arguments to motivate why we would put this doc in  the standards track.  

Please note that IETF consensus applies for this document as per RFC8789. 

Cheers,
Med

> -----Message d'origine-----
> De : Thomas Fossati via Datatracker <[email-masked]>
> Envoyé : dimanche 27 mars 2022 19:45
> À : [email-masked]
> Cc : [email-masked]; [email-masked]; tm-
> [email-masked]
> Objet : Iotdir last call review of draft-ietf-drip-arch-22
> 
> Reviewer: Thomas Fossati

_________________________________________________________________________________________________________________________

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.