Subject: [lamps] Proposed addition of hash-based signature algorithms for certificates to the LAMPS charter

From: Russ Housley <[email-masked]>
Date: Tue, 6 Nov 2018 22:50:59 -0500

The SECDISPATCH WG met on Tuesday afternoon, and they made this recommendation:

>  draft-vangeest-x509-hash-sigs-01 -- re-charter LAMPS WG to accept this draft

Three questions:

1) Do you support the addition of this work to the LAMPS charter?

2) If it is added, would you review the document?

3) If it results in an RFC, would you implement?

Russ & Tim

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 7 Nov 2018 03:56:38 +0000

Yes in favor, yes would review, unlikely to implement.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 7 Nov 2018 11:03:48 +0700

Same for me

> On 7 Nov 2018, at 10:56, Salz, Rich <[email-masked]> wrote:
> 
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: Tim Hollebeek <[email-masked]>
Date: Wed, 7 Nov 2018 04:21:49 +0000

(chair hat off)

Yes, yes, and yes.

-Tim

> -----Original Message-----
> From: Spasm <[email-masked]> On Behalf Of Russ Housley
> Sent: Wednesday, November 7, 2018 10:51 AM
> To: SPASM <[email-masked]>
> Subject: [lamps] Proposed addition of hash-based signature algorithms for
> certificates to the LAMPS charter
>

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Wed, 7 Nov 2018 15:58:43 +0000

1) Yes  
2) Yes 
3) No. Probably in the long run. 

I would also like to know if there are any IPR disclosures related to this draft. 

Panos 

-----Original Message-----
From: Spasm <[email-masked]> On Behalf Of Russ Housley
Sent: Tuesday, November 06, 2018 10:51 PM
To: SPASM <[email-masked]>
Subject: [lamps] Proposed addition of hash-based signature algorithms for certificates to the LAMPS charter

Three questions:

Russ & Tim

---

From: Daniel Van Geest <[email-masked]>
Date: Wed, 7 Nov 2018 16:10:43 +0000

We have no IPR disclosures for this draft. We're not aware of any 3rd party ones.

From: [email-masked]
Sent: November 7, 2018 10:59 AM
To: [email-masked]; [email-masked]
Subject: Re: [lamps] Proposed addition of hash-based signature algorithms for certificates to the LAMPS charter

1) Yes
2) Yes

Panos

-----Original Message-----
From: Spasm <[email-masked]> On Behalf Of Russ Housley
Sent: Tuesday, November 06, 2018 10:51 PM
To: SPASM <[email-masked]>
Subject: [lamps] Proposed addition of hash-based signature algorithms for certificates to the LAMPS charter

Three questions:

Russ & Tim

---

From: "Dr. Pala" <[email-masked]>
Date: Thu, 8 Nov 2018 06:31:28 -0500

Hi Russ, all,

> 1) Do you support the addition of this work to the LAMPS charter?
Yes.
> 2) If it is added, would you review the document?
Yes.
> 3) If it results in an RFC, would you implement?
Yes - but this might require sometime (and possibly in combination with 
the composite-crypto proposal which we will submit soon).

---

From: Adam Langley <[email-masked]>
Date: Thu, 8 Nov 2018 12:42:10 -0800

> 1) Do you support the addition of this work to the LAMPS charter?

No:

The signature schemes in the draft are stateful and sudden-death: the
penalty for mishandling the state is huge. This contrasts with every
signature scheme ever (I believe) deployed and thus with every current
process. For example, reconstituting an HSM from smartcards would be a
fatal error with such a scheme.

These schemes hedge against a valid risk, but at the cost of introducing a
much larger one.

The contexts in which stateful & sudden-death signatures are plausible are
so specific and controlled that standisation in X.509 would be immaterial
to them—they are not multi-lateral enough that whether something has an RFC
or not matters. On the other hand, standisation implicitly hints that the
thing being standardised is somewhat reasonable. So, on balance, I don't
think the integration of stateful schemes into formats and protocols is a
suitable subject for the IETF.

AGL
-- 
Adam Langley [email-masked] https://www.imperialviolet.org

---

From: "Dr. Pala" <[email-masked]>
Date: Sat, 10 Nov 2018 05:34:49 -0500

Hi Adam,

long time no see... are you still on this mailing list ? Are you 
planning to contribute to the working group ? Anyhow, to the technical 
matter...

I do not understand your position here. The draft is just about defining 
the OIDs, the RFC for the Hash-based signatures is defined elsewhere and 
I think is progressing in its definition and use (e.g., 
draft-mcgrew-hash-sigs-13, ietf-lamps-cms-hash-sig, etc.), therefore I 
do not think that these objections are relevant for the document at hand.

Can you please provide more /*targeted notes about this particular 
document ?*/

Cheers,
Max

P.S.: For the point you are raising about stateful schemes are mostly 
true - they are more difficult to handle and we will need to modify 
interfaces and APIs (e.g. PKCS#11) to add the possibility to 
transfer/update the private key status, however this is something we 
shall prepare to do since many QR algorithms tend to be stateful, IMHO. 
In this sense, stateful schemes are (most probably) going to be relevant 
in many environments. Maybe not in browsers, but, as I always try to 
remind people, browsers != Internet and TLS != PKI (therefore, it might 
not be relevant to you, but they might be relevant in many other 
environments - e.g., Cable Industry, Wireless, etc.). Just my 2 cents...

On 11/8/18 3:42 PM, Adam Langley wrote:
> On Tue, Nov 6, 2018 at 7:51 PM Russ Housley <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> These schemes hedge against a valid risk, but at the cost of 
> introducing a much larger one.
>
> The contexts in which stateful & sudden-death signatures are plausible 
> are so specific and controlled that standisation in X.509 would be 
> immaterial to them—they are not multi-lateral enough that whether 
> something has an RFC or not matters. On the other hand, standisation 
> implicitly hints that the thing being standardised is somewhat 
> reasonable. So, on balance, I don't think the integration of stateful 
> schemes into formats and protocols is a suitable subject for the IETF.
>
> AGL
> -- 
> Adam Langley [email-masked] <mailto:[email-masked]> 
> https://www.imperialviolet.org
>
-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

---

From: Adam Langley <[email-masked]>
Date: Sat, 10 Nov 2018 08:29:05 -0800

On Sat, Nov 10, 2018 at 2:35 AM Dr. Pala <[email-masked]> wrote:

> long time no see... are you still on this mailing list ? Are you planning
> to contribute to the working group ? Anyhow, to the technical matter...
>
(I was pointed to thread this by a colleague.)

> the OIDs, the RFC for the Hash-based signatures is defined elsewhere and I
> think is progressing in its definition and use (e.g.,
> draft-mcgrew-hash-sigs-13, ietf-lamps-cms-hash-sig, etc.), therefore I do
> not think that these objections are relevant for the document at hand.
>
> Can you please provide more *targeted notes about this particular
> document ?*
>
The document mentioned by Russ at the top of the thread
is draft-vangeest-x509-hash-sigs-01. Its title says that it's specifically
about HSS and XMSS, and it continues: "[the] private keys are stateful".

> P.S.: For the point you are raising about stateful schemes are mostly true
> - they are more difficult to handle and we will need to modify interfaces
> and APIs (e.g. PKCS#11) to add the possibility to transfer/update the
> private key status, however this is something we shall prepare to do since
> many QR algorithms tend to be stateful, IMHO. In this sense, stateful
> schemes are (most probably) going to be relevant in many environments.
> Maybe not in browsers, but, as I always try to remind people, browsers !=
> Internet and TLS != PKI (therefore, it might not be relevant to you, but
> they might be relevant in many other environments - e.g., Cable Industry,
> Wireless, etc.). Just my 2 cents...
>
There was been a general, and positive, move over the past decade+ towards
cryptographic primitives that are more robust, e.g. giving people AEADs
rather than a hash and block cipher and telling them to figure it out. I
think the general use of stateful signatures would be counter to this and a
mistake. I don't believe that many QR algorithms are stateful: it's just
the small signatures as far as I'm aware. Stateful hash-based signatures
are useful, but as building blocks of a stateless system.

Cheers

AGL

---

From: Tim Hollebeek <[email-masked]>
Date: Mon, 12 Nov 2018 14:35:32 +0000

(chair hat off)

Reconstituting a CT log server from a backup is similarly catastrophic.  

The risk you note is certainly something that should be carefully addressed in the draft, but I think throwing stateful signatures out of IETF entirely because of it is a bit of an overreaction.

-Tim

From: Spasm <[email-masked]> On Behalf Of Adam Langley
Sent: Thursday, November 8, 2018 12:42 PM
To: Russ Housley <[email-masked]>
Cc: SPASM <[email-masked]>
Subject: Re: [lamps] Proposed addition of hash-based signature algorithms for certificates to the LAMPS charter

On Tue, Nov 6, 2018 at 7:51 PM Russ Housley <[email-masked] <mailto:[email-masked]> > wrote:

Three questions:

No:

The signature schemes in the draft are stateful and sudden-death: the penalty for mishandling the state is huge. This contrasts with every signature scheme ever (I believe) deployed and thus with every current process. For example, reconstituting an HSM from smartcards would be a fatal error with such a scheme.

These schemes hedge against a valid risk, but at the cost of introducing a much larger one.

The contexts in which stateful & sudden-death signatures are plausible are so specific and controlled that standisation in X.509 would be immaterial to them—they are not multi-lateral enough that whether something has an RFC or not matters. On the other hand, standisation implicitly hints that the thing being standardised is somewhat reasonable. So, on balance, I don't think the integration of stateful schemes into formats and protocols is a suitable subject for the IETF.

AGL

-- 

Adam Langley [email-masked] <mailto:[email-masked]>  https://www.imperialviolet.org

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 12 Nov 2018 10:46:42 -0500

> Reconstituting a CT log server from a backup is similarly catastrophic.

Could you elaborate on why you believe that’s relevant? I have some
suspicions, but before I point out the flaws in an argument you may not be
making, it seems useful to understand exactly what connection you see
between that and a discussion of certificate signing algorithms.

The risk you note is certainly something that should be carefully addressed
> in the draft, but I think throwing stateful signatures out of IETF entirely
> because of it is a bit of an overreaction.
>

That’s fairly dismissive, even if couched in “a bit”. Do you disagree that
the stateless signatures offer equivalent security and with better
usability than stateful signatures - something that other WGs have been
prioritizing or requiring of their work product for half a decade now? What
makes this WG unique?

>
> -Tim
>
>
>
> *From:* Spasm <[email-masked]> *On Behalf Of *Adam Langley
> *Sent:* Thursday, November 8, 2018 12:42 PM
> *To:* Russ Housley <[email-masked]>
> *Cc:* SPASM <[email-masked]>
> *Subject:* Re: [lamps] Proposed addition of hash-based signature
> algorithms for certificates to the LAMPS charter
>
>
>

---

From: Tim Hollebeek <[email-masked]>
Date: Mon, 12 Nov 2018 16:06:24 +0000

Most people disagree with you, including NIST.

Another example:

http://www.pqsignatures.org/index/hbs.html

“While the security of other post-quantum cryptographic schemes like lattice-based ones is still object to further research, hash-based signatures are well understood.”

Second, hash-based signatures have already been standardized by IETF, while stateless schemes have not.

-Tim

From: Ryan Sleevi <[email-masked]> 
Sent: Monday, November 12, 2018 7:47 AM
To: Tim Hollebeek <[email-masked]>
Cc: Russ Housley <[email-masked]>; SPASM <[email-masked]>
Subject: Re: [lamps] Proposed addition of hash-based signature algorithms for certificates to the LAMPS charter

On Mon, Nov 12, 2018 at 9:35 AM Tim Hollebeek <[email-masked] <mailto:[email-masked]> > wrote:

(chair hat off)

Could you elaborate on why you believe that’s relevant? I have some suspicions, but before I point out the flaws in an argument you may not be making, it seems useful to understand exactly what connection you see between that and a discussion of certificate signing algorithms.

That’s fairly dismissive, even if couched in “a bit”. Do you disagree that the stateless signatures offer equivalent security and with better usability than stateful signatures - something that other WGs have been prioritizing or requiring of their work product for half a decade now? What makes this WG unique?

-Tim

From: Spasm <[email-masked] <mailto:[email-masked]> > On Behalf Of Adam Langley
Sent: Thursday, November 8, 2018 12:42 PM
To: Russ Housley <[email-masked] <mailto:[email-masked]> >
Cc: SPASM <[email-masked] <mailto:[email-masked]> >
Subject: Re: [lamps] Proposed addition of hash-based signature algorithms for certificates to the LAMPS charter

Three questions:

No:

 

AGL

-- 

_______________________________________________
Spasm mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/spasm

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 12 Nov 2018 11:15:31 -0500

Tim,

I find the reply approach fairly unhelpful. Perhaps you could reply to
specific statements in my message, rather than directing them to me
personally. I made several statements in the previous message, and your
statement "Most people disagree with you" provides little insight into what
you take umbrage with.

Such thoughtful replies on the substance, rather than the person, also
helps make sure that concerns are addressed; for example, given that you
have not elaborated on the CT argument, it's difficult for others to make
sense of that reference. As I'm certain we both want to ensure a productive
discussion, chair hat or otherwise, understanding the substance of your
past arguments and current statements provides much more value than the
quick and unfortunately too brief replies.

On Mon, Nov 12, 2018 at 11:06 AM Tim Hollebeek <[email-masked]>
wrote:

> “While the security of other post-quantum cryptographic schemes like
> lattice-based ones is still object to further research, hash-based
> signatures are well understood.”
>
>
>
> *From:* Ryan Sleevi <[email-masked]>
> *Sent:* Monday, November 12, 2018 7:47 AM
> *To:* Tim Hollebeek <[email-masked]>
> *Cc:* Russ Housley <[email-masked]>; SPASM <[email-masked]>
> The risk you note is certainly something that should be carefully
> addressed in the draft, but I think throwing stateful signatures out of
> IETF entirely because of it is a bit of an overreaction.
>
>
>
> <https://clicktime.symantec.com/a/1/dyI47pNUwzjnKlpg5udkPYVvjyqwzB1mpFy1Reomrlc=?d=k6708s9Yv76k4u3DteWeNyNOB5qXm722T3vthjyGAq-vZUunB52jcSXFBqPSaPV8clB2U6v9LdUA6qqUDEFXMYI2EYb10gQzgWPHgg5zy5YButabWcD3uM8cv3SS8WaF7oL89L6mk3K41RNvexdilfSE8we0zrFulaYBg2_vzWrKDFI5g5dee2LGJJlYgIZFkBjm-r89vLH_9UZes9qNh6nvM8fitYtAbTW2X5SpXcDwEupqziQfEdp0AUp_ZWRio7Zg7IELEKymOt_OAir1EM4YDzXS4k-Q4m7TgUOxSg1SkUi7eLnoMN0B8TxjhQu_6ALXBwIBi1vOPxj0tNIU-KMvm7z1yOvxSgM25di33PoRVxKwORl2mjWtpVF-7uUOAdyM5-ER_1F9I-IE9i-SHiLiLSfIMGOrOICyk_9pUEGrNDgrLfB_btIgsPekbVALCeAJo3KjSW2Lfa0z5wAuXFR1Kf4KfMUYxLAbsxnsdaif&u=https%3A%2F%2Fwww.imperialviolet.org>
>
> <https://clicktime.symantec.com/a/1/oOomiZEcGux8HmqHiFlNh-Bhr7iH6WnkP2UWmAx89wU=?d=k6708s9Yv76k4u3DteWeNyNOB5qXm722T3vthjyGAq-vZUunB52jcSXFBqPSaPV8clB2U6v9LdUA6qqUDEFXMYI2EYb10gQzgWPHgg5zy5YButabWcD3uM8cv3SS8WaF7oL89L6mk3K41RNvexdilfSE8we0zrFulaYBg2_vzWrKDFI5g5dee2LGJJlYgIZFkBjm-r89vLH_9UZes9qNh6nvM8fitYtAbTW2X5SpXcDwEupqziQfEdp0AUp_ZWRio7Zg7IELEKymOt_OAir1EM4YDzXS4k-Q4m7TgUOxSg1SkUi7eLnoMN0B8TxjhQu_6ALXBwIBi1vOPxj0tNIU-KMvm7z1yOvxSgM25di33PoRVxKwORl2mjWtpVF-7uUOAdyM5-ER_1F9I-IE9i-SHiLiLSfIMGOrOICyk_9pUEGrNDgrLfB_btIgsPekbVALCeAJo3KjSW2Lfa0z5wAuXFR1Kf4KfMUYxLAbsxnsdaif&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm>
>

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 12 Nov 2018 16:23:58 +0000

Hiya,

> 1) Do you support the addition of this work to the LAMPS charter?

Not sure. (Sorry for being on the fence;-)

I believe that the hash based signature schemes are
sufficiently secure, if implemented and used properly,
so I don't have concerns about the basic crypto, though
we've ~zero experience in implementing and using these
schemes afaik.

I do think there will be applications for those schemes
but am concerned that it may be a bad plan to define
how to use those schemes for X.509. I'd much prefer if
there were interest in trying to see how to move beyond
X.509 entirely as we consider attempts to be secure
in a post-quantum sense. If there were sufficient interest
in that (moving beyond X.509) then the valid concerns that
Adam raised (about e.g. APIs and recovery) could, I think,
be better handled. (Sadly, I'm unaware of any credible
proposal to move beyong X.509, much as I'd like to see
one;-) I don't think LAMPS would be the right venue for
such work, were there to be interest in that.

If, OTOH, it is inevitable that X.509 CAs want to start
signing certificates using these schemes, then I guess
just defining OIDs in LAMPS would be reasonable, but I
figure that's the wrong direction to take, and I'm not
sure what relying parties would really be using them, so
defining those OIDs may be premature.

> 2) If it is added, would you review the document?

Maybe.

> 3) If it results in an RFC, would you implement?

Not I.

Cheers,
S.

---

From: Daniel Van Geest <[email-masked]>
Date: Tue, 13 Nov 2018 18:16:58 +0000

Hi Adam,

You’re right that handling state needs to be done carefully and use of these signature schemes would not be appropriate in many contexts.  My presentation of this draft to LAMPS and SECDISPATCH pointed this out and gave some examples where they would and would not be appropriate.  If the WG chooses to proceed with this draft we can add more prominent/thorough text covering risks and mitigations.  Some solutions for managing state have been investigated, for example in https://eprint.iacr.org/2016/357.pdf, and should be used by signing implementations.

There are multi-lateral use cases for these signatures, a notable one being offline root CA signing.  Since these signature schemes are already well trusted, migration can begin prior to the completion of the NIST PQ Cryptography standardization, but will probably continue to be used well beyond that since they have decades of study behind them.

If we add stronger text warning of state reuse or mismanagement, the same should probably be done in draft-ietf-lamps-cms-hash-sig.  That draft is targeting code signing in CMS, but CMS also has other use cases where stateful signatures could be dangerous.

Daniel

On 2018-11-08, 3:42 PM, "Spasm on behalf of Adam Langley" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

On Tue, Nov 6, 2018 at 7:51 PM Russ Housley <[email-masked]<mailto:[email-masked]>> wrote:

Three questions:

No:

AGL
--
Adam Langley [email-masked]<mailto:[email-masked]> https://www.imperialviolet.org

---

From: Adam Langley <[email-masked]>
Date: Tue, 13 Nov 2018 11:10:52 -0800

On Tue, Nov 13, 2018 at 10:17 AM Daniel Van Geest <[email-masked]>
wrote:

> You’re right that handling state needs to be done carefully and use of
> these signature schemes would not be appropriate in many contexts.  My
> presentation of this draft to LAMPS and SECDISPATCH pointed this out and
> gave some examples where they would and would not be appropriate.
>

(Are there slides or a recording of that presentation? Happy to be
persuaded by a compelling use-case.)

  If the WG chooses to proceed with this draft we can add more
> prominent/thorough text covering risks and mitigations.  Some solutions for
> managing state have been investigated, for example in
> https://eprint.iacr.org/2016/357.pdf, and should be used by signing
> implementations.
>

Certainly one can imagine a system for assigning nonces that is intended to
be robust. But it is very different from any existing CA design that I'm
aware of. (Using "CA" in the generic sense, not limited to the WebPKI.)

It seems to me that defining OIDs and putting signatures in X.509 is the
easy step in this process. A robust design and process around the nonce
uniqueness problem is the hard part. If there were a couple of vendors who
had built such a thing, published white papers around it etc, and were now
seeking official recognition for some OIDs, that would be a very different
situation. Rather I fear that defining the OIDs first encourages people to
believe that this technology is "approved" in some sense, and thus to be
over-confident. (See the long history of much simplier issues with WebPKI
CAs, nearly all of whom presumably believed that they were being
sufficiently contentious in their operations: revoking their own live
certificates, getting ASN.1 encoding wrong, losing track of their key
material, etc.)

On the other hand, if people were putting in the significant effort to
build these (hopefully) robust systems, I don't think the lack of an
official OID would hinder them very much. Indeed, I think the IETF works
best when recognising and aligning existing and tested practice.

There are multi-lateral use cases for these signatures, a notable one being
> offline root CA signing.  Since these signature schemes are already well
> trusted, migration can begin prior to the completion of the NIST PQ
> Cryptography standardization, but will probably continue to be used well
> beyond that since they have decades of study behind them.
>

(To be clear: I have no reservations about the security of these schemes,
if used correctly. I just think the final qualification there is huge!)

If we add stronger text warning of state reuse or mismanagement, the same
> should probably be done in draft-ietf-lamps-cms-hash-sig.  That draft is
> targeting code signing in CMS, but CMS also has other use cases where
> stateful signatures could be dangerous.
>

I think I would have exactly the same reservations about that draft.

Cheers

AGL

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 13 Nov 2018 19:43:49 -0600

> persuaded by a compelling use-case.)

Recording of secdispatch: 22:25 into
https://www.youtube.com/watch?v=VawLLztFWOI and slides at
https://datatracker.ietf.org/meeting/103/materials/slides-103-secdispatch-algorithm-identifiers-for-hss-and-xmss-for-use-in-the-internet-x509-public-key-infrastructure-draft-vangeest-x509-hash-sigs-01-00
(from the "meeting materials" ('x') button at
https://datatracker.ietf.org/meeting/103/agenda.html .
Retrieving the LAMPS analogues is left as an exercise for the reader.

> sufficiently contentious in their operations: revoking their own live

(I assume this is supposed to be "conscientious"?)

> certificates, getting ASN.1 encoding wrong, losing track of their key

I think I'm missing some steps in how the IETF provided procedures that the
CA operators were following and thought were sufficient (but were actually
insufficient).

-Ben

---

From: Adam Langley <[email-masked]>
Date: Wed, 14 Nov 2018 15:14:10 -0800

> Retrieving the LAMPS analogues is left as an exercise for the reader.

Thank you for the pointers. The examples of where they might be
appropriate from the slides were "CA certs in interactive protocols"
and "CA certs in non-interactive protocols, code signing certs". I
don't think there's anything unexpected there and I disagree for the
reasons given above. (In contrast, I think /stateless/, hash-based
signatures make a whole lot of sense for code-signing.)

> (I assume this is supposed to be "conscientious"?)

Yes, thank you.

> CA operators were following and thought were sufficient (but were actually

I'm aiming to point out that X.509 has assumed competencies that CAs
have failed to meet before. Perhaps more applicably, X.509 assumes
that serial numbers under a given issuer are unique. But, even without
searching, I've personally dealt with one case where a WebPKI CA was
unable to revoke an intermediate because its (non-trivial) serial
number was duplicated in another, still active, intermediate.

There has been a heartening and positive move by the IETF in recent
years towards primitives that are harder to misuse. I think this moves
in the other direction.

Cheers

AGL