Re: [Secdispatch] [EXTERNAL]Re: Can Composite sigs move back to LAMPS?

[Mike Ounsworth <[e-mail]>]

Hi Stephen,

We may have a misunderstanding about what draft-ounsworth-pq-composite-sigs is trying to accomplish. 

Draft-ounsworth-pq-composite-sigs defines ASN.1 structures for carrying multiple SubjectPublicKeyInfo, AlgorithmIdentifier, and BIT STRING (signature values), in a way that will be drop-in for PKIX-like protocols.

You keep mentioning parameter sets and "what if they change?". I really don't see why that's relevant. Draft-ounsworth-pq-composite-sigs is algorithm-agnostic; orthogonal to the choice of algorithms by NIST or their encodings. 

If anything, I see your argument being in support of composite because a composite solution can help bridge across a param change, for example maybe by including one signature on each param set until all clients are upgraded. I wish such a mechanism had existed since the beginning of PKI; it would have helped for example with the SHA1 -> SHA2 migration as there are *still* PKI deployments with a handful of critical legacy clients that keep the entire ecosystem on SHA1. In fact, AFAIK Microsoft code-signing did exactly that by including both SHA1 and SHA2 signatures on binaries and letting the verifier pick their favourite during the transition period. Let's standardize this before we end up with a dozen proprietary ways of jamming 2+ signatures on things!

---
Mike Ounsworth | Office: [phone]

-----Original Message-----
From: Stephen Farrell <[e-mail]> 
Sent: January 17, 2020 2:06 PM
To: John Gray <[e-mail]>; Markku-Juhani O. Saarinen <[e-mail]>; IETF SecDispatch <[e-mail]>
Cc: Daniel Van Geest <[e-mail]>; Mike Ounsworth <[e-mail]>
Subject: Re: [EXTERNAL]Re: [Secdispatch] Can Composite sigs move back to LAMPS?


Replying to a few mails at once, but ISTM this is starting to get repetitive.

On 17/01/2020 18:15, John Gray wrote:
> Hi Stephen,
> 
> The reason why we are putting together this composite standard is 
> because we believe we are in this position today.   If NIST  decides 
> no Round 3 is needed, then we will know the PQ winners by June of 
> this year.   Even if there is a Round 3, and no final set of PQ 
> algorithms is declared until 2021 or 2022, we want to have a hybrid 
> standard ready for us use.  We will need to implement, test, and 
> interop and all these things take time and have to be done after there 
> is a standard.  If we wait too long, it will be a free for all.

Right now there are too many algorithms to believe that we'd have other than a free-for-all as those pushing one or another try get their thing adopted. I'd also note that NIST has a history or defining new parameterisations after algorithm selection, so wouldn't be surprised if that happened here too. I'd prefer we wait and see what results from the NIST thing rather adopt work now in the IETF. If people want to do work ahead of NIST then that's of course fine, but adopting such work in the IETF is asking us all to do work on this now, and I think that's both risky and wasteful.

> 
> There are already a small handful of stable PQ algorithms available 
> to use today.   See RFC 8391 (XMSS) and RFC 8554 (LMS), so using a 
> hybrid RSA or EC with XMSS or LMS in a composite form is already 
> viable.  The choices are definitely few at this moment, but there are 
> viable use-cases.

Stateful signature schemes such as those are not suited for use in X.509 IMO, as was already raised on the list.
(And someone earlier claimed they wouldn't work for their use-cases, so I'm confused as to whether the proponents here do or don't want to include stateful signature
schemes.)

On 17/01/2020 17:54, Mike Ounsworth wrote:
> Cool. In the meantime, we plan to keep working on the outstanding TODO 
> decision points in the draft as more vendors approach us for interop 
> testing. :-)

I've no objection to people working on stuff. I am opposed to the IETF prematurely adopting work in this space though.

On 17/01/2020 18:08, Carrick Bartle wrote:
> From what I've gathered from the mailing list discussion on this topic 
> (in particular, the lead time necessary for hardware), it strikes me 
> that there is sufficient reason for this work to advance.

My experience in the IETF is that ill-defined and less well understood work takes longest. I think this matches that at the moment. I'd suggest the proponents might be better spending time on developing their work by implementing it in open-source generic PKI libraries and applications so that they can produce some non arm-waving evidence as to what this does or doesn't break. (IMO, it'll turn out to break a lot and change many lines of code, but who knows, I may be wrong.)

On 17/01/2020 18:32, Valery Smyslov wrote:
> Given the usual IETF performance, a year is a term just to launch a 
> real work and realize where to go. So, I think we should start doing 
> it now to have plenty of time and not to be in a hurry later.

See above as to how to speed things up more effectively.
Additionally, the idea that waiting a year or so means someone would have to "be in a hurry" seems questionable to me.

Cheers,
S.