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

[Stephen Farrell <[e-mail]>]

Hiya,

On 12/09/2019 20:47, Mike Ounsworth wrote:
> Hi Stephen,
> 
> That's an exciting solution space that's orthogonal to the ones that
> I wrote up in my Problem Statement draft. Do you have some concretes
> on what such a "replace X.509" proposal might look like?

I don't. In an IETF context/discussion though, I might start
from looking at how acme accounts are handled or how assertions
are being handled using e.g. cose. I think the encoding of the
assertions is easy enough. Figuring out what assertions to
encode is where the work'd be. For example, is the offline CA
model even worth bothering with? Maybe encouraging multiple
independent assertions is better than trying to encapsulate
all the verifier needs into one blob? Etc. One thing that'd
be a MUST in my little head would be making anything like
notAfter be optional. But no, I don't have a worked-out
proposal and nor do I know if others would like to work
on that.

> I suggest that even with full support for such a proposal, it would
> still make sense to standardize a "less change to the 1980s baggage"
> so that existing systems have something they can do in the short
> term. 

What short-term problem is there? (That needs solving.)

And what'd stop this sticking plaster from blocking any
other mechanisms get deployed as has happened to date
with x.509? Doing sufficiently better than x.509 to
displace x.509 in a classical context has turned out to
be too hard, despite a couple of attempts. It's not that
x.509 is ultra-terrible (it's only mediocre-terrible:-)
but once something is in place then a new thing has to
be sufficiently better to displace that. So there's a
real opportunity cost to the path you're suggesting I
reckon.

> Speaking as a PKI vendor, this is starting to be an
> uncomfortably hot issue with our customers who are deploying 20 year
> lifetime devices and want post-quantum protection on them like now
> with like no code changes.

New algorithms => new code. Transition from 1 key => >1 key
means new code. I don't see how "no new code" is relevant
here. And I can see ways in which minimising the amount of
new code might lead to a higher liklihood of vulnerabilities.

> So exactly as you say "people invested in x.509-based PKI may
> reasonably prefer less-change to more-change" :P

Sure. I don't think there's anything wrong with you proposing
what you're proposing. I just think that doing that would be
heading about 180 degrees in the wrong direction:-)

Cheers,
S.


> 
> - - - Mike Ounsworth | Office: [phone]
> 
> -----Original Message----- From: Secdispatch
> <[e-mail]> On Behalf Of Stephen Farrell Sent:
> Thursday, September 12, 2019 2:28 PM To: Scott Fluhrer (sfluhrer)
> <[e-mail]>; Dr. Pala <[e-mail]>;
> [e-mail] Subject: [EXTERNAL]Re: [Secdispatch] Problem
> statement for post-quantum multi-algorithm PKI
> 
> 
> Hiya,
> 
> On 12/09/2019 20:08, Scott Fluhrer (sfluhrer) wrote:
>> I agree that this is an important problem to solve.
> 
> Depending, on the "this," I agree or disagree:-)
> 
> Discussion of how to get what PKI offers in a world where current
> asymmetric algorithms might be weak and where quantum-resistant, but
> new, algorithms are emerging, is an excellent topic to start to
> consider.
> 
> I also think it seems a bit mad to consider x.509 as the main thing
> to consider so I'm not at all keen on seeing this problem space as
> being one where all we need is yet another sticking plaster for
> x.509. That said, I do get that people invested in x.509-based PKI
> may reasonably prefer less-change to more-change, I just think we may
> be sad if we miss another opportunity to move on leaving behind some
> of this 1980's baggage.
> 
> Cheers, S.
> 
>> 
>> One might think we have plenty of time, given that Real Quantum 
>> Computers are, more than likely, more than 10 years away, and even
>>  once you have one, you cannot use your Quantum Computer to break
>> the authentication of recorded conversations.
>> 
>> On the other hand, authentication also brings in additional issues;
>>  instead of having a two party system (where as long as both the
>> client and the server support a postquantum algorithm, they can
>> negotiate it), we now have an (at least) three party system, the
>> client, the server, and the CA.  this additional party makes the
>> upgrade path more complicated.  So, while we have more time, we may
>> need it.
>> 
>> I don’t think it’s too early to start thinking about the issues..
>> 
>> From: Secdispatch <[e-mail]> On Behalf Of Dr. 
>> Pala Sent: Thursday, September 12, 2019 10:39 AM To: 
>> [e-mail] Subject: Re: [Secdispatch] Problem statement
>> for post-quantum multi-algorithm PKI
>> 
>> 
>> Hi SecDispatch, Mike,
>> 
>> Our industry (Cable) is working on this problem already - some of
>> our members have started investigating few things in the
>> post-quantum field and in particular how to protect our PKIs in
>> this uncertain environment.
>> 
>> With few billions certificates issued across the industry, we
>> heavily rely on certificates for device authentication and,
>> therefore, we need to work on a solution today.
>> 
>> For us, the use of Composite Crypto is quite an interesting path to
>>  pursue because it provides an easy way to protect today our PKIs 
>> against the factorization threat (not only certificates, but all
>> the data structures for PKIX) thus allowing to verify the
>> authentication with Post-Quantum algorithms when we will need to
>> make the switch (deferred Algorithm Agility).
>> 
>> We intend to support this idea and actively deploy it for our PKIs
>> and eventually expand the adoption of this approach in other
>> environments we are engaged in (e.g., medical devices, cellular
>> networks, WiFi Alliance and WBA, etc.)
>> 
>> Looking forward to find a good home for this project within the
>> IETF - a simple but powerful tool for our "PKI toolboxes"
>> 
>> Cheers, Max
>> 
>> 
>> 
>> 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
>> 
>> -- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director
>> [OpenCA Logo]
>> 
>> 
>> _______________________________________________ Secdispatch mailing
>>  list [e-mail] 
>> https://www.ietf.org/mailman/listinfo/secdispatch
>> 
> _______________________________________________ Secdispatch mailing
> list [e-mail] 
> https://www.ietf.org/mailman/listinfo/secdispatch
>