Subject: [Rats] sensitivity of trust anchor store for RP and Verifier

From: Michael Richardson <[email-masked]>
Date: Sun, 05 Dec 2021 22:49:29 -0500

Romans' review of the architecture document asked the question:

  Section 12.4. Is there any read sensitivity for the trust anchor store?
  https://github.com/ietf-rats-wg/architecture/issues/384

https://www.ietf.org/archive/id/draft-ietf-rats-architecture-13.html#name-trust-anchor-protection

The question is, does anything think that there is a risk if the list of
trust anchors in a Verifier or Relying Party was disclosed?

This could happen by an unprivledged process on the same system reading (the
equivalent of) /etc/ssl/certs.  Or by examining a software update (an RPM,
DEB, APK or RAR) that updated the trust anchor store.

This is *not* about modifying what's there.
I also remind that this is about Relying Parties and Verifiers.

Such systems, presumably, might also be subject to various kinds of audit
trails (depending upon what they do) which might actually require that the
reasoning for why some system was admitted by recorded.

It was unclear to the group what the document might say here.
We think it's probably out of scope, and that no single answer fits.

If the document were to say, SHOULD maintain confidentiality of the trust
anchor store, then that would put a very complex requirement on RPs and Verifiers.
Of course, if some sector required it, then they could put that requirement
in place.

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

---

From: "Smith, Ned" <[email-masked]>
Date: Mon, 6 Dec 2021 04:39:47 +0000

(not speaking as chair)
I think the question needs to be qualified in terms of who is taking the risk. If it's the Endorser or RVP, then no. We expect their privacy is not at risk. If it is the (entities implementing the) Roles, then the advice the arch draft should give is less clear, but not universally one way of another. 

I think it is best to be silent.
-Ned

On 12/5/21, 7:50 PM, "RATS on behalf of Michael Richardson" <[email-masked] on behalf of [email-masked]> wrote:

---

From: Thomas Fossati <[email-masked]>
Date: Thu, 9 Dec 2021 20:11:45 +0000

> Of course, if some sector required it, then they could put that requirement

When using public key cryptography there may be a privacy angle to the
question.  But I think it is not clear whether we can give a generally
applicable recommendation here, it really depends on the local /
application specific policy.

Obviously when the attestation uses symmetric encryption (BTW, a pure
nightmare for Verifiers) -- e.g., TCG MARS, but also some envisaged
modes of DICE, PSA and maybe others -- confidentiality is strictly a
MUST end-to-end.

> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats

-- 
Thomas

---

From: Michael Richardson <[email-masked]>
Date: Thu, 09 Dec 2021 17:50:01 -0500

> application specific policy.

Agreed.

    > modes of DICE, PSA and maybe others -- confidentiality is strictly a

Well, assume that these symmetric keys were bound into kerberos tickets and
so the secrets were safe, then there might be a list of the principals
attached to those tickets.

---

From: Thomas Fossati <[email-masked]>
Date: Fri, 10 Dec 2021 10:27:20 +0000

hi Michael,

> attached to those tickets.

I am not sure I understand the point you are trying to make here.
I am talking about the symmetric keys that need to be revealed to the
Verifier (likely by some supply chain entity) in order to check the
MAC on the presented evidence.
Not sure how Kerberos fits in this equation.

cheers,
--
Thomas

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 10 Dec 2021 10:45:43 -0800

I’m with Ned. Best to be silent on this one. The trust anchors are generally public keys so it’s OK for them to be public.

Maybe there’s very some odd system architecture where there is an issue, but I don’t really see how we can anticipate it to write anything useful.

If a symmetric key is used for signing and verifying (e.g. COSE_MAC) or there is encryption, then of course the Verifier or RP must do a good job of protection of they key they use to verify or decrypt.

LL

> On Dec 5, 2021, at 8:39 PM, Smith, Ned <[email-masked]> wrote:
> 
> (not speaking as chair)

---

From: Michael Richardson <[email-masked]>
Date: Fri, 10 Dec 2021 20:40:12 -0500

> Not sure how Kerberos fits in this equation.

Kerberos lets the "supply chain entity" encrypt the symmetric key to the
Verifier in a standard way.  The resulting ticket can have a visible label,
and can be listed, in much the same way that the contents of a trust anchor
store can be listed.

---

From: Thomas Fossati <[email-masked]>
Date: Sat, 11 Dec 2021 08:47:22 +0000

> and can be listed, in much the same way that the contents of a trust anchor

OK. I'd rather use a stand-alone key wrap format -- for example
something like PKCS#12 or COSE -- which I can compose easily with a
REST underlay.  But this is an implementation detail.

Going back to your original question, what we could do, rather than
staying completely silent, is sticking an informative reference to
§6.2 of NIST SP 800-57 Part 1 [1], which contains a comprehensive
treatment of the topic.

[1] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf

cheers,
-- 
Thomas

---

From: Laurence Lundblade <[email-masked]>
Date: Sat, 11 Dec 2021 12:07:57 -0800

> [1] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf

There’s a large variety of ways different systems may protect different trust anchors, private keys and such.

- Many system will use an HSM; how that works will depend on the HSM manufacturer
- Some systems will really be low security and not need much
- A particular OS may have a particular facility (Maybe MacOS let’s you use the T2 security chip, or you use something in an SGX container)
- Cloud services probably have lots of facilities for stuff like this.

Some of these might use Kerberos and some might use NIST.SP.800-57 and others will be completely different and just fine.

This seems like implementation architecture, not protocol, so at most we should be write security considerations.

LL

---

From: Thomas Fossati <[email-masked]>
Date: Sat, 11 Dec 2021 21:51:33 +0000

> Some of these might use Kerberos and some might use NIST.SP.800-57 and others will be completely different and just fine.

NIST SP 800-57 does not define or recommend any specific protocol.
Section 6 discusses at a high level the requirements for key
protection, which are likely to be relevant (also) to attestation
protocol and system designers.

-- 
Thomas

---

From: Ira McDonald <[email-masked]>
Date: Sat, 11 Dec 2021 17:12:43 -0500

Hi,

+1 to Thomas's recommendation for an SP800-57 reference.

Cheers,
- Ira

*Ira McDonald (Musician / Software Architect)*

*Chair - SAE Trust Anchors and Authentication TF*
*Co-Chair - TCG Trusted Mobility Solutions WG*

*Co-Chair - TCG Metadata Access Protocol SG*

*Chair - Linux Foundation Open Printing WGSecretary - IEEE-ISTO Printer
Working GroupCo-Chair - IEEE-ISTO PWG Internet Printing Protocol WGIETF
Designated Expert - IPP & Printer MIBBlue Roof Music / High North
Inchttp://sites.google.com/site/blueroofmusic
<http://sites.google.com/site/blueroofmusic>http://sites.google.com/site/highnorthinc
<http://sites.google.com/site/highnorthinc>mailto: [email-masked]
<[email-masked]>(permanent) PO Box 221  Grand Marais, MI 49839
906-494-2434*

On Sat, Dec 11, 2021 at 4:51 PM Thomas Fossati <[email-masked]> wrote:

> > > [1]
> https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf
> >
> > - A particular OS may have a particular facility (Maybe MacOS let’s you
> use the T2 security chip, or you use something in an SGX container)
> > Some of these might use Kerberos and some might use NIST.SP.800-57 and
> others will be completely different and just fine.
>

---

From: Laurence Lundblade <[email-masked]>
Date: Sat, 11 Dec 2021 15:44:43 -0800

> On Dec 11, 2021, at 1:51 PM, Thomas Fossati <[email-masked]> wrote:
> 
> <[email-masked] <mailto:[email-masked]>> wrote:
>> 

But it’s still just a security consideration, and it is qualified by the security requirements of the use case, right?

Also, if you apply this here, it should be applied to every IETF standard that uses keys and crypto, right? For example, COSE, CoSWID, SUIT… 

LL

---

From: Thomas Fossati <[email-masked]>
Date: Sat, 11 Dec 2021 23:56:39 +0000

> But it’s still just a security consideration, and it is qualified by the security requirements of the use case, right?

Yes, we are talking about adding text (or not) to Section 12.4 [1],
which is part of the security considerations.

[1] https://www.ietf.org/archive/id/draft-ietf-rats-architecture-13.html#section-12.4

-- 
Thomas

---

From: Ira McDonald <[email-masked]>
Date: Sat, 11 Dec 2021 19:30:02 -0500

Hi Laurence,

Yes - there are sorely missing up-to-date security considerations in many
IETF specs.

That's why the IAB Model-T Program was started - to define new threat
models and to
replace the old recommendations for writing security considerations in the
18-year-old
RFC 3552.

Cheers,
- Ira

On Sat, Dec 11, 2021 at 6:57 PM Thomas Fossati <[email-masked]> wrote:

> > But it’s still just a security consideration, and it is qualified by the
> security requirements of the use case, right?
>
> https://www.ietf.org/archive/id/draft-ietf-rats-architecture-13.html#section-12.4
>
> > Also, if you apply this here, it should be applied to every IETF
> standard that uses keys and crypto, right? For example, COSE, CoSWID, SUIT…
> >
> > LL
>
>
>
> --
> Thomas
>

---

From: Michael Richardson <[email-masked]>
Date: Sun, 12 Dec 2021 11:07:43 -0500

> REST underlay.  But this is an implementation detail.

I'm not telling you to use anything specific.
I'm saying that there are many systems that you could use, which could
still safely present a visible label.

The question was whether or not the ability to read that label is a concern.

---

From: Thomas Fossati <[email-masked]>
Date: Sun, 12 Dec 2021 17:54:06 +0000

ISTM we are giving different interpretations of Roman's comment:

> ** Section 12.4.  Is there any read sensitivity for the trust anchor store?

To me this applies more generally to the "read sensitivity" of the TAs
rather than just to their labels (or any other metadata associated
with the TA itself).

As I said upthread, I don't think there is anything we can say in
absolute terms in the architecture regarding the privacy of the
metadata -- including labels -- or of the public key data.

But there is obviously a read sensitivity associated with the raw key
material in attestation schemes based on symmetric crypto that is
worth pointing out.  And here's another potential source of disconnect
that I just realized exists: Section 12.4 seems to use TA only to mean
"public key cryptosystem based" (as per RFC6024), which is
unfortunately too narrow.

-- 
Thomas

---

From: Michael Richardson <[email-masked]>
Date: Sun, 12 Dec 2021 14:20:00 -0500

> ISTM we are giving different interpretations of Roman's comment:

I think that we are pretty close in understanding.

    > worth pointing out.

Yes, clearly one shouldn't disclose private key material, whether it's from
symmetric crypto or asymmetric crypto.
How many places do you think this needs to be said?

*Aside* from that concern, what are the considerations with being able to
 list what key material is present? (without seeing anything private)

---

From: Thomas Fossati <[email-masked]>
Date: Sun, 12 Dec 2021 21:53:09 +0000

> How many places do you think this needs to be said?

I think there is a problem with the current definition of "trust
anchor" that doesn't cover the symmetric case, and that trickles a bit
through the document.  I have opened
https://github.com/ietf-rats-wg/architecture/issues/392 to further
discuss this point.

>  list what key material is present? (without seeing anything private)

It depends on the application specific application threat model, and
also on the nature of the underlying attester identification scheme:
one key per device, one key per group of devices, one key for all the
devices from an endorser (in order of decreasing privacy concern).  I
don't think there is anything we could say that applies generally,
except "take privacy seriously".

-- 
Thomas