Subject: [Rats] RATS security considerations

From: Laurence Lundblade <[email-masked]>
Date: Sun, 12 Dec 2021 14:19:11 -0800

Branching this off from the trust anchor discussion, a couple of thoughts.

If we’re going to recommend NIST SP 800-57 in RATS architecture security considerations, do we also need it in UCCS, EAT, AR, TUDA...?  Most of the content in UCCS is security considerations in spirit. Just about every RATS document authenticates and/or encrypts data using involve keys that need to be kept private.

(I don’t know about the IAT Model-T program Ira mentioned nor have I read NIST SP 800-57 yet, so I’m just commenting on RATS work, thought the COSE update and CoSWID are also obvious upcoming candidates).

Personally, I think it would be efficient and cool to be able to put just about all the security considerations for all RATS attestation documents in one place. For example, maybe all of it could go into RATS Architecture and then UCCS, EAT, TUDA and such could have minimal security considerations sections that just reference RATS Architecture.

I also think it critical that security considerations sections allow for varying security strength. The cost of “strong” state of the art security (certified HW that defends against invasive HW attacks and the like) is just too high for lots of devices.

LL

---

From: Ira McDonald <[email-masked]>
Date: Mon, 13 Dec 2021 11:49:27 -0500

Hi Laurence and RATS folks,

Here's the Datatracker link for the IAB (Internet Activities Board) Model-T
Program:

https://datatracker.ietf.org/group/model-t/about/

And here's the link for the rich set of Internet-Drafts generated over the
past two years:

https://datatracker.ietf.org/group/model-t/documents/

And here are the links for the video recording and draft minutes of last
week's excellent Model-T call:

https://youtu.be/bO_OVl0HjXE

https://github.com/intarchboard/program-model-t/blob/master/notes/notes-2021-12-07.md

I encourage anyone working on *any( RFC-to-be in any IETF WG to think about
participating
in the IAB Model-T (Internet Threat Models) activity.

Cheers,
- Ira

On Sun, Dec 12, 2021 at 5:19 PM Laurence Lundblade <[email-masked]>
wrote:

> If we’re going to recommend NIST SP 800-57 in RATS architecture security
> considerations, do we also need it in UCCS, EAT, AR, TUDA...?  Most of the
> content in UCCS is security considerations in spirit. Just about every RATS
> document authenticates and/or encrypts data using involve keys that need to
> be kept private.
>
> (I don’t know about the IAT Model-T program Ira mentioned nor have I read
> NIST SP 800-57 yet, so I’m just commenting on RATS work, thought the COSE
> update and CoSWID are also obvious upcoming candidates).
>
> Personally, I think it would be efficient and cool to be able to put just
> about all the security considerations for all RATS attestation documents in
> one place. For example, maybe all of it could go into RATS Architecture and
> then UCCS, EAT, TUDA and such could have minimal security considerations
> sections that just reference RATS Architecture.
>
> I also think it critical that security considerations sections allow for
> varying security strength. The cost of “strong” state of the art security
> (certified HW that defends against invasive HW attacks and the like) is
> just too high for lots of devices.
>
> LL
>
>
>
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats
>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 13 Dec 2021 12:03:58 -0500

Laurence Lundblade <[email-masked]> wrote:
    > If we’re going to recommend NIST SP 800-57 in RATS architecture
    > security considerations, do we also need it in UCCS, EAT, AR, TUDA...?
    > Most of the content in UCCS is security considerations in spirit. Just
    > about every RATS document authenticates and/or encrypts data using
    > involve keys that need to be kept private.

Yes, I agree with you here.

    > (I don’t know about the IAT Model-T program Ira mentioned nor have I
    > read NIST SP 800-57 yet, so I’m just commenting on RATS work, thought
    > the COSE update and CoSWID are also obvious upcoming candidates).

Model-T is about protocols which do not have active WGs.

    > Personally, I think it would be efficient and cool to be able to put
    > just about all the security considerations for all RATS attestation
    > documents in one place. For example, maybe all of it could go into RATS
    > Architecture and then UCCS, EAT, TUDA and such could have minimal
    > security considerations sections that just reference RATS
    > Architecture.

I don't want to do this.
The considerations that go into the Architecture need to say things about
requirements upon implementations of the architecture.
Implementations of the architecture need to then say things like,

  "The privacy requirements of [ARCH, section FOO] are satisfied by the
   mechanism in section BAR.  Note that if the option BAZ is implemented,
   then the resulting BLOG must also be FLORGED, as per Section ZUMMER"

    > I also think it critical that security considerations sections allow
    > for varying security strength. The cost of “strong” state of the art
    > security (certified HW that defends against invasive HW attacks and the
    > like) is just too high for lots of devices.

  "When the option GALGADOT is used, the resulting EAT claims may not have
   privacy against active on-path attacks unless the WONDER-WOMEN invisible
   plane is equiped with a GPS locator"

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 13 Dec 2021 12:26:24 -0500

> Model-T is about protocols which do not have active WGs.

Not the case, I was confused with another effort :-)

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 13 Dec 2021 11:10:38 -0800

>   then the resulting BLOG must also be FLORGED, as per Section ZUMMER"

The all-important central one is the protection of the secret/private key that resides in the Attester and authenticates Attestation Evidence. That key exists for EAT, UCCS and TUDA and has pretty much the same purpose and security requirements in all three.

In EAT and UCCS all we can say are broad general things about the protection of attestation keys (less familiar with TUDA). I imagine for that key the security considerations could pretty much be the same regardless of attestation protocol. It’s more about the key’s use for attestation than it is in the particularly attestation protocol. 

COSE, JOSE, TLS and others can all be used as basis for the attestation protocol. Their security considerations have not addressed the considerations needed for attestation, but the considerations for attestation in all of these will be similar and general.

That is not to say that RATS Architecture has to address everything, but it seems really helpful and efficient that it addresses the big ones.

It is efficient as then we don’t have to have the discussion over for each attestation protocol. It is also good to get consistency between all the RATS attestation protocols. 

LL