Subject: [Secdispatch] Problem statement for post-quantum multi-algorithm PKI

From: Mike Ounsworth <[email-masked]>
Date: Wed, 11 Sep 2019 21:11:23 +0000

Hi SecDispatch,

This got bounced here from LAMPS because the scope is potentially more than a "limited" pkix change, and because this needs multi-WG visibility to decide on a category of solution.

Background / history
--------------------

The Post-Quantum community (for example, surrounding the NIST PQC competition), is pushing for "hybridized" crypto that combines RSA/ECC with new primitives in order to hedge our bets against both quantum adversaries, and also algorithmic / mathematical breaks of the new primitives.

A year and a half ago, a draft was put to LAMPS for putting PQ public key and signatures into X.509v3 extensions. This draft has been allowed to expire, but is being pursued at the ITU.
https://datatracker.ietf.org/doc/draft-truskovsky-lamps-pq-hybrid-x509/

Earlier this year, a new draft was put to LAMPS for defining "composite" public key and signature algorithms that, essentially, concatenate multiple crypto algorithms into a single key or signature octet string. This draft stalled in LAMPS over whether it is the correct overall approach.
https://datatracker.ietf.org/doc/draft-ounsworth-pq-composite-sigs/

Now I'm taking a step back and submitting a draft that acts as a semi-formal problem statement, and an overview of the three main categories of solutions.
https://datatracker.ietf.org/doc/draft-pq-pkix-problem-statement/

My Opinion
----------

Personally, I'm fairly agnostic to the chosen solution, but feel that we need some kind of standard(s) around the post-quantum transition for certificates and PKI. Personally, I feel that Composite is mature enough as an idea to standardize as a tool in our toolbox for contexts where it makes sense, even if a different mechanism is preferred for TLS and IPSEC/IKE.

Requested action from SECDISPATCH
---------------------------------

1. Feedback on the problem statement draft. https://datatracker.ietf.org/doc/draft-pq-pkix-problem-statement/

2. Discussion of how to progress this.

PS I'm a new IETF'er, please be gentle :P

Thanks,
- - -
Mike Ounsworth | Software Security Architect
Entrust Datacard

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 13 Sep 2019 05:42:47 -0400

Mike,

Are you looking for an agenda spot in Singapore?

Additionally, it would be good to see discussion on list in advance, so thank you for posting your message.

Best regards,
Kathleen 

Sent from my mobile device

> On Sep 11, 2019, at 5:11 PM, Mike Ounsworth <[email-masked]> wrote:
> 
> Hi SecDispatch,
> 
> _______________________________________________
> Secdispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdispatch

---

From: Mike Ounsworth <[email-masked]>
Date: Fri, 13 Sep 2019 14:02:56 +0000

Hi Kathleen,

I'm new to IETF, and looking for guidance. If an agenda spot in Singapore is the right next step to get visibility and discussion, then I'm happy to do that.

Thanks!
-Mike

From: Kathleen Moriarty
Sent: Friday, September 13, 04:42
Subject: [EXTERNAL]Re: [Secdispatch] Problem statement for post-quantum multi-algorithm PKI
To: Mike Ounsworth
Cc: [email-masked]

WARNING: This email originated outside of Entrust Datacard.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.

Mike,

Best regards,
Kathleen

> https://datatracker.ietf.org/doc/draft-<https://datatracker.ietf.org/doc/draft-truskovsky-lamps-pq-hybrid-x509/>truskovsky<https://datatracker.ietf.org/doc/draft-truskovsky-lamps-pq-hybrid-x509/>-lamps-pq-hybrid-x509/<https://datatracker.ietf.org/doc/draft-truskovsky-lamps-pq-hybrid-x509/>
>
>
> https://datatracker.ietf.org/doc/draft-<https://datatracker.ietf.org/doc/draft-ounsworth-pq-composite-sigs/>ounsworth<https://datatracker.ietf.org/doc/draft-ounsworth-pq-composite-sigs/>-pq-composite-<https://datatracker.ietf.org/doc/draft-ounsworth-pq-composite-sigs/>sigs<https://datatracker.ietf.org/doc/draft-ounsworth-pq-composite-sigs/>/<https://datatracker.ietf.org/doc/draft-ounsworth-pq-composite-sigs/>
>
>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 13 Sep 2019 15:07:24 +0100

Hiya,

On 13/09/2019 15:02, Mike Ounsworth wrote:
> Hi Kathleen,
> 
> I'm new to IETF, and looking for guidance. If an agenda spot in
> Singapore is the right next step to get visibility and discussion,
> then I'm happy to do that.

FWIW, while I'm not keen on Mike's particular proposal,
I would also support having a slot to discuss this a
bit. (On the basis that I might well be wrong, as often
happens, or to help tee up a bigger discussion if one's
desirable later:-)

Cheers,
S.

> 
> Thanks! -Mike
> 
> 
> 
> From: Kathleen Moriarty Sent: Friday, September 13, 04:42 Subject:
> [EXTERNAL]Re: [Secdispatch] Problem statement for post-quantum
> multi-algorithm PKI To: Mike Ounsworth Cc: [email-masked]
> 
> 
> WARNING: This email originated outside of Entrust Datacard. DO NOT
> CLICK links or attachments unless you trust the sender and know the
> content is safe.
> 
> Mike,
> 
> Best regards, Kathleen
>> On Sep 11, 2019, at 5:11 PM, Mike Ounsworth
>> <[email-masked]> wrote:
>> 
>> Hi SecDispatch,
>> 
>> This got bounced here from LAMPS because the scope is potentially
>> more than a "limited" pkix change, and because this needs multi-WG
>> visibility to decide on a category of solution.
>> 
>> 
>> 
>> Background / history --------------------
>> 
>> The Post-Quantum community (for example, surrounding the NIST PQC
>> competition), is pushing for "hybridized" crypto that combines
>> RSA/ECC with new primitives in order to hedge our bets against both
>> quantum adversaries, and also algorithmic / mathematical breaks of
>> the new primitives.
>> 
>> 
>> A year and a half ago, a draft was put to LAMPS for putting PQ
>> public key and signatures into X.509v3 extensions. This draft has
>> been allowed to expire, but is being pursued at the ITU. 
Earlier this year, a new draft was put to LAMPS for defining "composite"
public key and signature algorithms that, essentially, concatenate
multiple crypto algorithms into a single key or signature octet string.
This draft stalled in LAMPS over whether it is the correct overall approach.
>> https://datatracker.ietf.org/doc/draft-<https://datatracker.ietf.org/doc/draft-ounsworth-pq-composite-sigs/>ounsworth<https://datatracker.ietf.org/doc/draft-ounsworth-pq-composite-sigs/>-pq-compos…
Now I'm taking a step back and submitting a draft that acts as a
semi-formal problem statement, and an overview of the three main
categories of solutions.
>> My Opinion ----------
>> Personally, I'm fairly agnostic to the chosen solution, but feel
>> that we need some kind of standard(s) around the post-quantum
>> transition for certificates and PKI. Personally, I feel that
>> Composite is mature enough as an idea to standardize as a tool in
>> our toolbox for contexts where it makes sense, even if a different
>> mechanism is preferred for TLS and IPSEC/IKE.
>> 
>> 
>> 
>> 
>> 1. Feedback on the problem statement draft.
>> Thanks, - - - Mike Ounsworth | Software Security Architect Entrust
>> Datacard
>> 
>> _______________________________________________ Secdispatch mailing
>> list [email-masked] 
> _______________________________________________ Secdispatch mailing
> list [email-masked]

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 18 Sep 2019 19:33:46 -0400

OK, so yes, I have to finish the Mesh before I start on anything new. But I
do think I can solve a few of the use cases raised with the technology I
developed for the Mesh and in particular the question of how to manage an
embedded device.

Recall that a few years ago, I proposed a scheme 'omnibroker' that was a
delegated trust service. If device X wants to connect to party Y via
protocol Z, it asks the omnibroker and back come all the crypto parameters
required. In the TLS case it would get back an IP address, port, cert path
and OCSP token.

The omnibroker could in principle perform the actual key exchange and pass
back a Kerberos ticket to the client in response to the request. So what we
have here is a point of leverage. Alice deploys her $20,000 worth of IoT
devices into the walls of her new mansion. They each connect to her
personal Mesh Service which provides them with the necessary credential to
communicate with her personal Omnibroker. That credential could be a
Kerberos like ticket meaning that the device to Omnibroker connection is
QCR.

If it becomes known that a Quantum Computer of appreciable size has been
built, all Alice needs to do is to drop in a new Omnibroker service that
can support the new modes of interaction, new Quantum Resistant algorithms
and so on. So she has to make a $100 (or less) upgrade instead of a $20,000
one.

This is not going to solve every problem of course. It is not going to
allow a constrained device to be put onto the Internet. But I still
consider that a silly idea. In the age of the $5 PiZero, constrained
devices should have connections that are mediated by decently performant
devices.

Again, this is not a line of research that is currently my top priority. If
someone wants to make it my top priority, there is a protocol for that.

My current priority is to solve the three problems I see as critical for
deploying the last generation of end-to-end crypto: Provisioning every
device with a private key pair, publishing the corresponding public keys in
a useful fashion and protecting data at rest.