Subject: [Teep] Default, mandatory-to-implement algorithm

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 24 Feb 2020 13:18:32 +0000

Hi all,

The other topic I would like to bring to your attention is about the MTI algorithm.

In OTrP RSA was the mandatory to use asymmetric algorithm (with SHA256 as the hash function) and ECC was optional to implement.
Given that OTrP was developed around 2015 this may have been a good choice at that time.

Today, I believe it is more appropriate to make ECC the mandatory-to-implement algorithm.

Thoughts?

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 24 Feb 2020 14:38:53 +0000

Yes to ECC as  mandatory-to-implement algorithm and the protocol can have more than one mandatory-to-implement algorithm (see https://tools.ietf.org/html/rfc7696).
Cheers,
-Tiru

From: TEEP <[email-masked]> On Behalf Of Hannes Tschofenig
Sent: Monday, February 24, 2020 6:49 PM
To: teep <[email-masked]>
Subject: [Teep] Default, mandatory-to-implement algorithm

CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

________________________________
Hi all,

Thoughts?

Ciao
Hannes

---

From: "Wheeler, David M" <[email-masked]>
Date: Mon, 24 Feb 2020 15:23:07 +0000

Hannes,
I am in favor of keeping RSA as the mandatory-to-implement and ECC as optional. Below is my reasoning.

In choosing a mandatory-to-implement algorithm, we need to consider both classical attacks and quantum attacks. Given TEEP is going to be a standard, and may take a few years for TEEP to begin to be adopted widely, we will find ourselves close to the 2030 horizon when quantum attacks are very relevant.

In the quantum attack model, the number of key bits is most relevant because the key must be modeled in qubits. While both RSA and ECC are both susceptible to Shor's algorithm, RSA-3K will be more resistant to quantum threats than ECC, because it will take a larger quantum computer to model the key (>10K to 100K qubits depending on logical to physical qubit mapping) than ECC. There are (optimistic?) estimates that a quantum computer with the required number of qubits to break ECC-256 will be available around 2025 to 2027.

It seems imprudent to me to put ECC as mandatory and make RSA optional at this point. I know that this is counter to many views who are not well informed on the quantum attacks, however US government recommendations have pulled Suite-B (i.e. use of ECC) as mandatory and returned to RSA and IFC algorithms over ECC due to the larger key size. This preference to RSA is only until we have fully quantum resistant algorithms, but this weill be another 3 years at least.

I could provide a more detailed briefing on this subject if necessary.
Thanks,
Dave Wheeler

From: TEEP <[email-masked]> On Behalf Of Hannes Tschofenig
Sent: Monday, February 24, 2020 6:19 AM
To: teep <[email-masked]>
Subject: [Teep] Default, mandatory-to-implement algorithm

Hi all,

Thoughts?

Ciao
Hannes

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 24 Feb 2020 16:22:35 +0000

Why not mention both RSA and ECC as mandatory-to-implement algorithms (similar to TLS 1.3 https://tools.ietf.org/html/rfc8446#section-9.1) ?

-Tiru

From: TEEP <[email-masked]> On Behalf Of Wheeler, David M
Sent: Monday, February 24, 2020 8:53 PM
To: Hannes Tschofenig <[email-masked]>; teep <[email-masked]>
Subject: Re: [Teep] Default, mandatory-to-implement algorithm

From: TEEP <[email-masked]<mailto:[email-masked]>> On Behalf Of Hannes Tschofenig
Sent: Monday, February 24, 2020 6:19 AM
To: teep <[email-masked]<mailto:[email-masked]>>
Subject: [Teep] Default, mandatory-to-implement algorithm

Hi all,

Thoughts?

Ciao
Hannes

---

From: Russ Housley <[email-masked]>
Date: Mon, 24 Feb 2020 11:37:51 -0500

In the SUIT WG, I have been advocating HSS/LMS Hash-based signature as the MTI algorithm.  This is a quantum resistant signature, and NIST has already started the process to make it a FIPS-approved algorithm (https://csrc.nist.gov/News/2019/draft-sp-800-208-stateful-hash-based-sig-schemes <https://csrc.nist.gov/News/2019/draft-sp-800-208-stateful-hash-based-sig-schemes>).  I think we want a quantum resistant signature so that we can deploy the next generation of cryptography even if a quantum computer is invented.  On the other hand, RSA, ECDSA, and EdDSA are not secure if a large-scale quantum computer is available to the adversary.

I would like to see both SUIT and TEEP select HSS/LMS Hash-based signature as the MTI algorithm.

Russ

> On Feb 24, 2020, at 8:18 AM, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi all, 
>

---

From: "Wheeler, David M" <[email-masked]>
Date: Mon, 24 Feb 2020 17:32:15 +0000

In software, this is easy ... in hardware this is prohibitive. Especially for small devices.
Also consider that most TEE's implement a single key for attestation. If you require two different types of keys for attestation, then the cost for a TEE goes way up. I am not aware of ANY TEE that supports two different algorithms for attestation.

I am opposed to requiring implementation of two different algorithms. One must be mandatory, and one must be optional.

From: Konda, Tirumaleswar Reddy <[email-masked]>
Sent: Monday, February 24, 2020 9:23 AM
To: Wheeler, David M <[email-masked]>; Hannes Tschofenig <[email-masked]>; teep <[email-masked]>
Subject: RE: Default, mandatory-to-implement algorithm

-Tiru

From: TEEP <[email-masked]<mailto:[email-masked]>> On Behalf Of Wheeler, David M
Sent: Monday, February 24, 2020 8:53 PM
To: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>; teep <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teep] Default, mandatory-to-implement algorithm

Hi all,

Thoughts?

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 24 Feb 2020 18:19:40 +0000

I agree that requiring both ECC and RSA-based keys to be present on an IoT device is not practical.

Maybe we could come up with profiles. For low-end IoT devices it is more likely to use ECC today. Non-IoT devices or high-end IoT devices may be just fine with RSA (for use today). Hash-based signatures, as Russ mentioned, is probably the story for the future when dealing with PQC.

From: TEEP <[email-masked]> On Behalf Of Wheeler, David M
Sent: Monday, February 24, 2020 6:32 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; Hannes Tschofenig <[email-masked]>; teep <[email-masked]>
Subject: Re: [Teep] Default, mandatory-to-implement algorithm

From: Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>
Sent: Monday, February 24, 2020 9:23 AM
To: Wheeler, David M <[email-masked]<mailto:[email-masked]>>; Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>; teep <[email-masked]<mailto:[email-masked]>>
Subject: RE: Default, mandatory-to-implement algorithm

-Tiru

Hi all,

Thoughts?

Ciao
Hannes

---

From: Michael Richardson <[email-masked]>
Date: Mon, 24 Feb 2020 13:30:55 -0500

{should this be CC'ed to SUIT?}

Russ Housley <[email-masked]> wrote:
    > In the SUIT WG, I have been advocating HSS/LMS Hash-based signature as
    > the MTI algorithm.  This is a quantum resistant signature, and NIST has
    > already started the process to make it a FIPS-approved algorithm

That's great news!
Once we have paid the code space and figured out the network bandwidth to
accomodate it, does it even make sense to have another MTI?

I am concerned that the MTI, if not used periodically, might rot.
Or it might be surprising when we have to use it, that the cost is too high.

I am not clear if we need HSS/LMS for the general TEEP use.
It seems that the thing that need a quantum resistant secure upgrade is for
the TEE Agent code, not the TAx.  I'm not clear that the TEE Agent code
maintenance is even part of TEEP's mandate.

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

---

From: Dave Thaler <[email-masked]>
Date: Mon, 24 Feb 2020 20:04:19 +0000

One option would be to have both MTI at a TAM, and allow a TEEP Agent to pick either one.

From: TEEP <[email-masked]> On Behalf Of Hannes Tschofenig
Sent: Monday, February 24, 2020 10:20 AM
To: Wheeler, David M <[email-masked]>; Konda, Tirumaleswar Reddy <[email-masked]>; teep <[email-masked]>
Subject: Re: [Teep] Default, mandatory-to-implement algorithm

From: TEEP <[email-masked]<mailto:[email-masked]>> On Behalf Of Wheeler, David M
Sent: Monday, February 24, 2020 6:32 PM
To: Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>; teep <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teep] Default, mandatory-to-implement algorithm

From: Konda, Tirumaleswar Reddy <[email-masked]<mailto:TirumaleswarReddy_Konda@McAfee..com>>
Sent: Monday, February 24, 2020 9:23 AM
To: Wheeler, David M <[email-masked]<mailto:[email-masked]>>; Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>; teep <[email-masked]<mailto:[email-masked]>>
Subject: RE: Default, mandatory-to-implement algorithm

Why not mention both RSA and ECC as mandatory-to-implement algorithms (similar to TLS 1.3 https://tools.ietf.org/html/rfc8446#section-9.1<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8446%23section-9.1&data=02%7C01%7Cdthaler%40microsoft.com%7C28baee707a8045c7eec208d7b9562d2f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181652096493028&sdata=u5NS93%2BFEnd3L8GnSk9auiagMP6CR2%2BY3H9shDDiqgQ%3D&reserved=0>) ?

-Tiru

Hi all,

Thoughts?

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 24 Feb 2020 20:56:45 +0000

That would be a possibility too. In the meanwhile we have three MTI algorithms: RSA, ECC, hash-based signatures
The issue with long-lived devices is a bit special given that some of that code ends up in ROM rather than code that can be updated.
It might be worthwhile to reach out to device manufactures to see what their thinking is.

From: Dave Thaler <[email-masked]>
Sent: Monday, February 24, 2020 9:04 PM
To: Hannes Tschofenig <[email-masked]>; Wheeler, David M <[email-masked]>; Konda, Tirumaleswar Reddy <[email-masked]>; teep <[email-masked]>
Subject: RE: Default, mandatory-to-implement algorithm

From: TEEP <[email-masked]<mailto:[email-masked]>> On Behalf Of Hannes Tschofenig
Sent: Monday, February 24, 2020 10:20 AM
To: Wheeler, David M <[email-masked]<mailto:[email-masked]>>; Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; teep <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teep] Default, mandatory-to-implement algorithm

-Tiru

Hi all,

Thoughts?

Ciao
Hannes

---

From: Mingliang Pei <[email-masked]>
Date: Mon, 24 Feb 2020 12:58:02 -0800

A device should have only mandatory algorithm, not two, which will be too
costly. There is a question about MTI for a TAM - should it support both
ECC and RSA as mandatory algorithms? The TAM server side mandatory support
of two are feasible and most probably will support the other one for
devices that choose to use ECC for smaller size. In OTrP discussion, we had
a consensus that a TAM in OTrP will need to only support one to meet
interoperability. I think we will need to continue to make the distinction
and explicitly specify MTI in the revised spec respectively for a TAM and a
device (TEEP Agent).

If a device chooses to support an optional algorithm, it will find out
whether a TAM supports it via the message exchange. The support algorithm
was in the initial OTrP message protocol request message, and a TAM
response signing will indicate to a client whether the TAM can support it.

Between RSA and ECC, we considered devices that can host TAs and TEEs are
capable to do RSA, and support of RSA is more readily available in
libraries and certificate issuance for implementation; therefore RSA was
chosen over ECC.

I am not sure we are ready to mandate a PQC algorithm yet for the initial
adoption, in particular, if we are counting here many IoT devices. I feel
that we will need to address this in two steps: current one and PQC one.
The QC strength between RSA and ECC may not be a factor as much when we
plan for a PQC in recommendation list for devices that are constraint for
upgrade to support algorithm agility. If we do this, ECC can become the
choice while we optimize the entire protocol to be compact, using CBOR and
COSE etc.

Thanks,

Ming

On Mon, Feb 24, 2020 at 10:20 AM Hannes Tschofenig <
[email-masked]> wrote:

> Maybe we could come up with profiles. For low-end IoT devices it is more
> likely to use ECC today. Non-IoT devices or high-end IoT devices may be
> just fine with RSA (for use today). Hash-based signatures, as Russ
> mentioned, is probably the story for the future when dealing with PQC.
>
>
>
> *From:* TEEP <[email-masked]> *On Behalf Of * Wheeler, David M
> *Sent:* Monday, February 24, 2020 6:32 PM
> *To:* Konda, Tirumaleswar Reddy <[email-masked]>;
> Hannes Tschofenig <[email-masked]>; teep <[email-masked]>
> *Subject:* Re: [Teep] Default, mandatory-to-implement algorithm
>
>
>
> In software, this is easy … in hardware this is prohibitive. Especially
> for small devices.
>
> Also consider that most TEE’s implement a single key for attestation. If
> you require two different types of keys for attestation, then the cost for
> a TEE goes way up. I am not aware of ANY TEE that supports two different
> algorithms for attestation.
>
>
>
> I am opposed to *requiring* implementation of two different algorithms.
> One must be mandatory, and one must be optional.
>
>
>
> *From:* Konda, Tirumaleswar Reddy <[email-masked]
> <TirumaleswarReddy_Konda@McAfee..com>>
> *Sent:* Monday, February 24, 2020 9:23 AM
> *To:* Wheeler, David M <[email-masked]>; Hannes Tschofenig <
> [email-masked]>; teep <[email-masked]>
> *Subject:* RE: Default, mandatory-to-implement algorithm
>
>
>
> Why not mention both RSA and ECC as mandatory-to-implement algorithms
> (similar to TLS 1.3 https://tools.ietf.org/html/rfc8446#section-9.1
> <https://clicktime.symantec.com/37QPVPRnmDzUsUdzVK4WinW7Vc?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8446%23section-9.1>)
> ?
>
>
>
> -Tiru
>
>
>
> *From:* TEEP <[email-masked]> *On Behalf Of *Wheeler, David M
> *Sent:* Monday, February 24, 2020 8:53 PM
> *To:* Hannes Tschofenig <[email-masked]>; teep <[email-masked]>
> *Subject:* Re: [Teep] Default, mandatory-to-implement algorithm
>
>
>
> *CAUTION*: External email. Do not click links or open attachments unless
> you recognize the sender and know the content is safe.
>
>
> ------------------------------
>
> Hannes,
>
> In choosing a mandatory-to-implement algorithm, we need to consider both
> classical attacks and quantum attacks. Given TEEP is going to be a
> standard, and may take a few years for TEEP to begin to be adopted widely,
> we will find ourselves close to the 2030 horizon when quantum attacks are
> very relevant.
>
>
>
> In the quantum attack model, the number of key bits is most relevant
> because the key must be modeled in qubits. While both RSA and ECC are both
> susceptible to Shor’s algorithm, RSA-3K will be more resistant to quantum
> threats than ECC, because it will take a larger quantum computer to model
> the key (>10K to 100K qubits depending on logical to physical qubit
> mapping) than ECC. There are (optimistic?) estimates that a quantum
> computer with the required number of qubits to break ECC-256 will be
> available around 2025 to 2027.
>
>
>
> It seems imprudent to me to put ECC as mandatory and make RSA optional at
> this point. I know that this is counter to many views who are not well
> informed on the quantum attacks, however US government recommendations have
> pulled Suite-B (i.e. use of ECC) as mandatory and returned to RSA and IFC
> algorithms over ECC due to the larger key size. This preference to RSA is
> only until we have fully quantum resistant algorithms, but this weill be
> another 3 years at least.
>
>
>
> *From:* TEEP <[email-masked]> *On Behalf Of *Hannes Tschofenig
> *Sent:* Monday, February 24, 2020 6:19 AM
> *To:* teep <[email-masked]>
> *Subject:* [Teep] Default, mandatory-to-implement algorithm
>
>
>
> Hi all,
>
>
>
> In OTrP RSA was the mandatory to use asymmetric algorithm (with SHA256 as
> the hash function) and ECC was optional to implement.
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> _______________________________________________
> TEEP mailing list
> [email-masked]
>
> https://clicktime.symantec.com/3CLY9NidtGNgn5Np4Yuadoa7Vc?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep
>

---

From: Mingliang Pei <[email-masked]>
Date: Mon, 24 Feb 2020 13:03:03 -0800

Email crossed. Just note that the previous protocol version has this
algorithm negotiation between a client agent and TAM, which detects
optional support even if an algorithm is just optional. It helps to support
algorithm agility in case some new algorithm is introduced in future.
Thanks, Ming

On Mon, Feb 24, 2020 at 12:57 PM Hannes Tschofenig <
[email-masked]> wrote:

> That would be a possibility too. In the meanwhile we have three MTI
> algorithms: RSA, ECC, hash-based signatures
>
> The issue with long-lived devices is a bit special given that some of that
> code ends up in ROM rather than code that can be updated.
>
> *From:* Dave Thaler <[email-masked]>
> *Sent:* Monday, February 24, 2020 9:04 PM
> *To:* Hannes Tschofenig <[email-masked]>; Wheeler, David M <
> [email-masked]>; Konda, Tirumaleswar Reddy
> <[email-masked]>; teep <[email-masked]>
> *Sent:* Monday, February 24, 2020 10:20 AM
> *To:* Wheeler, David M <[email-masked]>; Konda, Tirumaleswar
> Reddy <[email-masked]>; teep <[email-masked]>
> <TirumaleswarReddy_Konda@McAfee...com>>
> <https://clicktime.symantec.com/3D47NxjH2hAUNBc9E6Fkjk27Vc?u=https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Ftools.ietf.org%252Fhtml%252Frfc8446%2523section-9.1%26data%3D02%257C01%257Cdthaler%2540microsoft.com%257C28baee707a8045c7eec208d7b9562d2f%257C72f988bf86f141af91ab2d7cd011db47%257C1%257C0%257C637181652096493028%26sdata%3Du5NS93%252BFEnd3L8GnSk9auiagMP6CR2%252BY3H9shDDiqgQ%253D%26reserved%3D0>)
> ?
>
>
>
> -Tiru
>
>
>
> https://clicktime.symantec.com/317YVsDp4qHubEz1EJDqPDK7Vc?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep
>

---

From: Jeremy O'Donoghue <[email-masked]>
Date: Mon, 24 Feb 2020 21:28:20 +0000

As a consideration, the number of fuses or similar NVM required to provision RSA keys compared to ECC keys of theoretically equivalent strength is prohibitively expensive for many classes of device.

This is quite a strong argument in favour of ECC for at least some market segments. Perhaps the best option is to have different profiles for different device classes. Low cost devices use ECC and those which can stand the cost use RSA, with the TAM needing to manage both cases.

Best regards
Jeremy

On 24/02/2020, 21:03, "TEEP on behalf of Mingliang Pei" <[email-masked]<mailto:[email-masked]> on behalf of mingliang.pei=[email-masked]<mailto:mingliang.pei=[email-masked]>> wrote:

CAUTION: This email originated from outside of the organization.
Email crossed. Just note that the previous protocol version has this algorithm negotiation between a client agent and TAM, which detects optional support even if an algorithm is just optional. It helps to support algorithm agility in case some new algorithm is introduced in future. Thanks, Ming

On Mon, Feb 24, 2020 at 12:57 PM Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
That would be a possibility too. In the meanwhile we have three MTI algorithms: RSA, ECC, hash-based signatures
The issue with long-lived devices is a bit special given that some of that code ends up in ROM rather than code that can be updated.
It might be worthwhile to reach out to device manufactures to see what their thinking is.

From: Dave Thaler <[email-masked]<mailto:[email-masked]>>
Sent: Monday, February 24, 2020 9:04 PM
To: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>; Wheeler, David M <[email-masked]<mailto:[email-masked]>>; Konda, Tirumaleswar Reddy <[email-masked]>; teep <[email-masked]<mailto:[email-masked]>>
Subject: RE: Default, mandatory-to-implement algorithm

In software, this is easy … in hardware this is prohibitive. Especially for small devices.
Also consider that most TEE’s implement a single key for attestation. If you require two different types of keys for attestation, then the cost for a TEE goes way up. I am not aware of ANY TEE that supports two different algorithms for attestation.

From: Konda, Tirumaleswar Reddy <[email-masked]<mailto:TirumaleswarReddy_Konda@McAfee...com>>
Sent: Monday, February 24, 2020 9:23 AM
To: Wheeler, David M <[email-masked]<mailto:[email-masked]>>; Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>; teep <[email-masked]<mailto:[email-masked]>>
Subject: RE: Default, mandatory-to-implement algorithm

Why not mention both RSA and ECC as mandatory-to-implement algorithms (similar to TLS 1.3 https://tools.ietf.org/html/rfc8446#section-9.1<https://clicktime.symantec.com/3D47NxjH2hAUNBc9E6Fkjk27Vc?u=https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Ftools.ietf.org%252Fhtml%252Frfc8446%2523section-9.1%26data%3D02%257C01%257Cdthaler%2540microsoft.com%257C28baee707a8045c7eec208d7b9562d2f%257C72f988bf86f141af91ab2d7cd011db47%257C1%257C0%257C637181652096493028%26sdata%3Du5NS93%252BFEnd3L8GnSk9auiagMP6CR2%252BY3H9shDDiqgQ%253D%26reserved%3D0>) ?

-Tiru

In the quantum attack model, the number of key bits is most relevant because the key must be modeled in qubits. While both RSA and ECC are both susceptible to Shor’s algorithm, RSA-3K will be more resistant to quantum threats than ECC, because it will take a larger quantum computer to model the key (>10K to 100K qubits depending on logical to physical qubit mapping) than ECC. There are (optimistic?) estimates that a quantum computer with the required number of qubits to break ECC-256 will be available around 2025 to 2027.

Hi all,

Thoughts?

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
TEEP mailing list
[email-masked]<mailto:[email-masked]>
https://clicktime.symantec.com/317YVsDp4qHubEz1EJDqPDK7Vc?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep

---

From: Michael Richardson <[email-masked]>
Date: Mon, 24 Feb 2020 19:26:46 -0500

I think that this thread has gone rather sideways.

1) the TAM is, as I understand it, a service that runs in a rather
   non-constrained place, often out on the Internet (although there are
   exceptions), and is easily upgraded.  It needs to deal with algorithms for
   the family of devices that it needs to talk to, for the lifetime of those
   devices.  It primarily will be processing evidence from the devices.
   It may be producing attestations for other (unconstrained) relying parties.
   If necessary, the TAM can be upgraded by inserting DVDs into a server.

2) The TEEP Agent is a piece of software which runs inside/manages the TEE,
   which processes firmware (hopefully, in the form of SUIT
   manifests) which need to be loaded into a TEE.  The TE-Agent is not
   trivially upgradeble, but I believe that it can be updated.
   It may need to have trust anchors for the various TAMs that it might talk
   to built in, and there may be software updates required for the TE-Agent
   when the TAMs do things like roll certificate authorities.
   But, the TEEP-Agent, effectively, is the "bootloader" for the Trusted Apps (TAx).
   (It does not boot itself)

   The TAM will need to sign the SUIT manifests with an algorithm (and key, etc.)
   which the TEEP Agent can process, and this can be adapted such that
   different devices (or the same device on different days) get different
   algorithms.
   The TEEP Agent therefore never needs to speak more than one algorithm, and
   we can upgrade the TEEP Agent to support new things without flag days.

3) I think that TEEP Agent will be started/validated by a highly trusted part
   of the boot process.  I suspect that only the manufacturer of the silicon
   will get to provide this software. (I'd like to be wrong here, btw)
   Updates to the TEEP Agent will be critical when a quantum breakthrough occurs.
   It is therefore *this* piece which needs to have hash-based signatures.
   While the Hash-based signature themselves are big, the trust-anchors are just SHA256
   hashes, which are 32-bytes in size, so this is not a major commitment of
   fuses.   Putting an ECDSA key in here that is expected to last decades
   seems very short-sighted.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 25 Feb 2020 07:51:34 +0000

FWIW there is ciphersuite negotiation also in the TEEP protocol.

From: Mingliang Pei <[email-masked]>
Sent: Monday, February 24, 2020 10:03 PM
To: Hannes Tschofenig <[email-masked]>
Cc: Dave Thaler <[email-masked]>; Wheeler, David M <[email-masked]>; Konda, Tirumaleswar Reddy <[email-masked]>; teep <[email-masked]>
Subject: Re: [Teep] Default, mandatory-to-implement algorithm

From: Dave Thaler <[email-masked]<mailto:[email-masked]>>
Sent: Monday, February 24, 2020 9:04 PM
To: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>; Wheeler, David M <[email-masked]<mailto:[email-masked]>>; Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; teep <[email-masked]<mailto:[email-masked]>>
Subject: RE: Default, mandatory-to-implement algorithm

-Tiru

Hi all,

Thoughts?

Ciao
Hannes

---

From: <[email-masked]>
Date: Thu, 27 Feb 2020 15:25:10 +0100

Hi Michael,

Nice write-up.

There is indeed the question where the TEEP Agent sits inside the TEE and,
more importantly, which parts can be updated. In our discussions at the
hackathon we have been talking about implementing a TEEP Agent as a TA, or
as a pseudo-TA or system TA (as it is sometimes called) that has the same
privileges as the secure world OS. While we haven't made a decision about
this aspect and need further investigation one aspect is clear: the
manifests need to be verified before the TAs can be executed.

For example, for the STM32MP1 (which we had at the hackathon) the keys for
this verification have their anchor in the secure boot. I showed a picture
of it in the tutorial presentation. At least today, you are not changing
credential types in the chain. At the bottom of that chain is the code in
ROM (at least for a production device -- not so for a development board).

Does this change your view about the issue?

Ciao
Hannes

-----Original Message-----
From: TEEP <[email-masked]> On Behalf Of Michael Richardson
Sent: Tuesday, February 25, 2020 1:27 AM
To: teep <[email-masked]>
Subject: [Teep] algorithms for different parts of TEEP

1) the TAM is, as I understand it, a service that runs in a rather
   non-constrained place, often out on the Internet (although there are
   exceptions), and is easily upgraded.  It needs to deal with algorithms
for
   the family of devices that it needs to talk to, for the lifetime of those
   devices.  It primarily will be processing evidence from the devices.
   It may be producing attestations for other (unconstrained) relying
parties.
   If necessary, the TAM can be upgraded by inserting DVDs into a server.

   But, the TEEP-Agent, effectively, is the "bootloader" for the Trusted
Apps (TAx).

   The TAM will need to sign the SUIT manifests with an algorithm (and key,
etc.)
   which the TEEP Agent can process, and this can be adapted such that
   different devices (or the same device on different days) get different
   algorithms.
   The TEEP Agent therefore never needs to speak more than one algorithm,
and
   we can upgrade the TEEP Agent to support new things without flag days.

3) I think that TEEP Agent will be started/validated by a highly trusted
part
   of the boot process.  I suspect that only the manufacturer of the silicon
   will get to provide this software. (I'd like to be wrong here, btw)
   Updates to the TEEP Agent will be critical when a quantum breakthrough
occurs.
   It is therefore *this* piece which needs to have hash-based signatures.
   While the Hash-based signature themselves are big, the trust-anchors are
just SHA256
   hashes, which are 32-bytes in size, so this is not a major commitment of
   fuses.   Putting an ECDSA key in here that is expected to last decades
   seems very short-sighted.

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

---

From: Michael Richardson <[email-masked]>
Date: Thu, 27 Feb 2020 17:08:33 -0500

> manifests need to be verified before the TAs can be executed.

okay, This seems consistent with my understanding.

    > this verification have their anchor in the secure boot.

Fair enough: so how does the software get verified/updated in a post-quantum world?

    > I showed a picture

So is the TEEP Agent updatable at all?

    > Does this change your view about the issue?

I don't think so.

I think that we deal with the Post-Quantum upgrade by upgrading the TEEP
Agent with new algorithms, and it's the TEEP Agent upgrade that we need to
plan for with Hash-Based Signatures.

---

From: Rene Struik <[email-masked]>
Date: Thu, 27 Feb 2020 17:40:08 -0500

Dear colleagues:

One thing that unfortunately does not seem to sink-in is that one has to 
plan for change (aka "algorithm agility"), no matter which algorithms 
one uses. This is true should quantum computers one day indeed see the 
light (for it is very unlikely that PQ algorithms one picks are 
invulnerable to all future attack avenues ad infinum, even if one day 
test of time will have convinced people of theoretical PQ-virtue) and is 
also true today (see the many-many vulnerabilities embedded with past 
IETF protocols one has had to deal with).

One cannot expect a sole winner here. Please heed to advice of [1] 
(which, I believe, is even a Best Current Practice...).

Ref: [1] RFC 7696 - Guidelines for Cryptographic Algorithm Agility and 
Selecting Mandatory-to-Implement Algorithms (November 2015)

Rene

BTW1 - maybe an authentic append-only tree using block chain technology 
populated with roots of trust could be useful for transitionary effects.

BW2 - since algorithms are composed of simple arithmetic operations, one 
can certainly embed some of this in hardware, to support, e.g., some 
primitives underlying R-LWE, SIDH, etc. (without (!) customization to 
speedy values, since one wishes to keep this flexible and generic).

On 2/27/2020 5:08 PM, Michael Richardson wrote:
> https://www.ietf.org/mailman/listinfo/teep

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 28 Feb 2020 07:14:28 +0000

Agree with Rene. RFC7696 encourages more than one than one mandatory-to-implement algorithm for agility and says protocol design should allow transition to handle broken cryptographic algorithms.  Further, it says “IETF protocols that employ cryptography MUST specify one or more strong mandatory-to-implement algorithms or suites.  This does not require all deployments to use this algorithm or suite, but it does require that it be available to all deployments.”

It also discusses “picking only one cipher suite is harmful (see Section 3.3)”.

Cheers,
-Tiru

From: TEEP <[email-masked]> On Behalf Of Rene Struik
Sent: Friday, February 28, 2020 4:10 AM
To: Michael Richardson <[email-masked]>; 'teep' <[email-masked]>
Cc: [email-masked]; Russ Housley <[email-masked]>
Subject: Re: [Teep] algorithms for different parts of TEEP

One thing that unfortunately does not seem to sink-in is that one has to plan for change (aka "algorithm agility"), no matter which algorithms one uses. This is true should quantum computers one day indeed see the light (for it is very unlikely that PQ algorithms one picks are invulnerable to all future attack avenues ad infinum, even if one day test of time will have convinced people of theoretical PQ-virtue) and is also true today (see the many-many vulnerabilities embedded with past IETF protocols one has had to deal with).

One cannot expect a sole winner here. Please heed to advice of [1] (which, I believe, is even a Best Current Practice...).

Ref: [1] RFC 7696 - Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms (November 2015)

Rene

BTW1 - maybe an authentic append-only tree using block chain technology populated with roots of trust could be useful for transitionary effects.

BW2 - since algorithms are composed of simple arithmetic operations, one can certainly embed some of this in hardware, to support, e.g., some primitives underlying R-LWE, SIDH, etc. (without (!) customization to speedy values, since one wishes to keep this flexible and generic).

I don't think so.

    > From: TEEP <[email-masked]><mailto:[email-masked]> On Behalf Of Michael Richardson

    > To: teep <[email-masked]><mailto:[email-masked]>

    > Michael Richardson <[email-masked]><mailto:[email-masked]>, Sandelman Software Works  -=

--

Michael Richardson <[email-masked]><mailto:[email-masked]>, Sandelman Software Works

TEEP mailing list

--

email: [email-masked]<mailto:[email-masked]> | Skype: rstruik