Subject: [Rats] Quantum-safe attestation

From: Laurence Lundblade <[email-masked]>
Date: Mon, 24 Aug 2020 11:04:48 -0700

We probably want RATS architecture to be able to use quantum-safe algorithms. On low cost and low speed devices that might mean HMAC is used since SHA-2 and such seem to be quantum-safe. On higher cost and higher speed devices there may be alternatives that look more like PKI.

Comments?

LL

---

From: Michael Richardson <[email-masked]>
Date: Mon, 24 Aug 2020 17:16:55 -0400

Laurence Lundblade <[email-masked]> wrote:
    > We probably want RATS architecture to be able to use quantum-safe
    > algorithms. On low cost and low speed devices that might mean HMAC is
    > used since SHA-2 and such seem to be quantum-safe. On higher cost and
    > higher speed devices there may be alternatives that look more like
    > PKI.

Yes/no.

Use of a keyed HMAC requires a symmetric key, which will be a hassle to
provision the verifier, and effectively locks the device to a single (likely
manufacturer provided) verifier.   It will also raise questions of
non-repudiation.
Better *might* be RFC8778 HSS/LMS Hash-Based Signature Algorithms.
They are bigger, and have a limited number of uses.

I would say that the architecture does not need to say anything about the
algorithms.  These are functional requirements, not design requirements.

There will have to be firmware updates to the Attesting Environment once
either we have quantum-safe asymmetric algorithms, or when we have a QM
breach.  That can be done with SUIT signed by RFC8778.
I don't think that our architecture need worry about that.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 24 Aug 2020 21:24:42 +0000

>    I don't think that our architecture need worry about that.

Agree.

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 24 Aug 2020 15:23:23 -0700

I don’t want the RATS architecture to pick one algorithm or go into detail about algorithms.

I expect the RATS architecture to be fully flexible to use what ever algorithms can do the job. In particular it must not assume PKI. Most other crypto-using IETF standards do not assume PKI. They often work better with PKI, but they allow for other algorithms. RATS needs to be the same.

The particular manifestation I can think of for RATS is that Endorsements must support confidentiality. If endorsements do not support confidentiality an assumption that only PKI-based attestation can be used is made. 

I don’t know of any other manifestations that moving to quantum-safe crypto would have on the architecture, but it seems worth thinking through.

LL

> On Aug 24, 2020, at 2:16 PM, Michael Richardson <[email-masked]> wrote:
> 
> 
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats

---

From: "Panwei (William)" <[email-masked]>
Date: Tue, 25 Aug 2020 02:22:01 +0000

> I expect the RATS architecture to be fully flexible to use what ever
> algorithms can do the job. In particular it must not assume PKI. Most other
> crypto-using IETF standards do not assume PKI. They often work better with
> PKI, but they allow for other algorithms. RATS needs to be the same.
> 
> The particular manifestation I can think of for RATS is that Endorsements
> must support confidentiality. If endorsements do not support
> confidentiality an assumption that only PKI-based attestation can be used
> is made.

The characteristics of Endorsement depend on what the Endorsement is. I don't feel current architecture assumes the Endorsements are PKI-based or limits the algorithms to only use PKI.

Regards & Thanks!
Wei Pan

> 
> I don’t know of any other manifestations that moving to quantum-safe
> crypto would have on the architecture, but it seems worth thinking
> through.
> 
> LL
> 
> 
> 
> > Use of a keyed HMAC requires a symmetric key, which will be a hassle
> > to provision the verifier, and effectively locks the device to a single (likely
> > I would say that the architecture does not need to say anything about
> > the algorithms.  These are functional requirements, not design
> requirements.
> >
> > There will have to be firmware updates to the Attesting Environment
> > once either we have quantum-safe asymmetric algorithms, or when we
> > have a QM breach.  That can be done with SUIT signed by RFC8778.