Subject: [Spasm] Add SHA-3 to PKIX

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 24 Feb 2017 11:47:32 -0500

All,

In the wake of the SHA-1 break, the WebPKI is now down to one digest
algorithm. Given the role of the WebPKI, we need two algorithms based on
different principles.

SHA-3 is the obvious choice. NIST has allocated OIDs but they have
parameters and so it is not quite a straight drop in replacement for SHA-2.

Deployment of SHA-2 took 15 years, in part because nobody saw the need to
deploy SHA-2 until after the Wang attack of 2005. There are many moving
parts in this system and one of the major problems is that many parties
wait for the others to act before they act.

* CABForum can't act until there is an RFC to cite.
* HSM vendors won't produce product until there is a demand.

There is of course the complicating factor of Curve-X ECC. I note that
draft-ietf-curdle-pkix-newcurves
<https://tools.ietf.org/html/draft-ietf-curdle-pkix-newcurves> is in WG
last call. I was previously waiting on that draft passing the IESG to raise
Curve-X in CABForum.

I suggest the following as an approach for SHA-3/RSA

1) Submit a SHA-3/RSA draft to LAMPS
2) On passing
3) Submit a CABForum Ballot to adopt SHA-3 as a approved algorithm

The Curve-X work could happen in parallel and would follow the same
approach. I would expect the two would quickly get in sync.

---

From: Yoav Nir <[email-masked]>
Date: Fri, 24 Feb 2017 19:48:51 +0200

Hi, Phil

> On 24 Feb 2017, at 18:47, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> All,
> 
> In the wake of the SHA-1 break, the WebPKI is now down to one digest algorithm. Given the role of the WebPKI, we need two algorithms based on different principles.
> 
> SHA-3 is the obvious choice. NIST has allocated OIDs but they have parameters and so it is not quite a straight drop in replacement for SHA-2.
> 
> Deployment of SHA-2 took 15 years, in part because nobody saw the need to deploy SHA-2 until after the Wang attack of 2005. There are many moving parts in this system and one of the major problems is that many parties wait for the others to act before they act.
> 
> There is of course the complicating factor of Curve-X ECC. I note that draft-ietf-curdle-pkix-newcurves <https://tools.ietf.org/html/draft-ietf-curdle-pkix-newcurves> is in WG last call. I was previously waiting on that draft passing the IESG to raise Curve-X in CABForum.
> 
> The Curve-X work could happen in parallel and would follow the same approach. I would expect the two would quickly get in sync.

Sounds like a plan.  Three questions:
Why LAMPS rather than CURDLE?
What about ECDSA?
What is “On passing”?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 24 Feb 2017 13:23:35 -0500

On Fri, Feb 24, 2017 at 12:48 PM, Yoav Nir <[email-masked]> wrote:

>    1. Why LAMPS rather than CURDLE?
>    2. What about ECDSA?
>    3. What is “On passing”?
>
> ​1. Well because the responsible SECAD suggested LAMPS. ​

​Its the same people and could well end up being the same meeting slot at
some point. I suspect it means he wants CURDLE to do its work and
disappear.​

​2. Good question and was the reason I had been holding off on SHA-3.

I want both of course. But Curve-X requires a bit more prep than SHA-3.

3. CABForum does not need to wait for an RFC to be passed to begin
discussions but it will probably need to have an RFC available to vote on a
motion. So I would look to raise this in CABForum as soon as it passed the
IESG and propose the ballot as soon as the RFC passed.​

​​

---

From: Yoav Nir <[email-masked]>
Date: Fri, 24 Feb 2017 22:40:03 +0200

> On 24 Feb 2017, at 20:23, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> 
> 
> On Fri, Feb 24, 2017 at 12:48 PM, Yoav Nir <[email-masked] <mailto:[email-masked]>> wrote:
> Hi, Phil
> 
>> On 24 Feb 2017, at 18:47, Phillip Hallam-Baker <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> All,
>> 
> ​Its the same people and could well end up being the same meeting slot at some point. I suspect it means he wants CURDLE to do its work and disappear.​

OK

> I want both of course. But Curve-X requires a bit more prep than SHA-3.

The two EdDSA curves I understand. But what about ECDSA with the NIST curves? Currently each of the three curves (P-256, P-384, and P-521) is used with one of the SHA2 variants. Don’t you want them with SHA3 variants?

> 3. CABForum does not need to wait for an RFC to be passed to begin discussions but it will probably need to have an RFC available to vote on a motion. So I would look to raise this in CABForum as soon as it passed the IESG and propose the ballot as soon as the RFC passed.​

OK

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 24 Feb 2017 15:53:32 -0500

On Fri, Feb 24, 2017 at 3:40 PM, Yoav Nir <[email-masked]> wrote:

> The two EdDSA curves I understand. But what about ECDSA with the NIST
> curves? Currently each of the three curves (P-256, P-384, and P-521) is
> used with one of the SHA2 variants. Don’t you want them with SHA3 variants?
>

​No.​

​NIST EdDSA withj SHA-2 is in the CABForum list of approved algorithms. But
I can't see there being momentum behind uses of those curves in the future.
I think we have made a decision to focus on Curve-X

I don't see any need to remove them. Particularly when the curve that is
used most is P-384 which is rather stronger than 25519. But Curve-X is our
chosen path and we should not re-litigate that.

​There are a large number of algorithms that I would like to see purged.
​In fact pretty much everything that isn't AES, RSA, SHA-2, SHA-3, Curve-X,
Cha-Cha20 or close relatives (Blake2, HMAC).

​We don't actually add security by adding new algorithms. We only add
security byu removing the weak ones. Anything that is not widely used and
necessary is just more attack surface.​

---

From: Jim Schaad <[email-masked]>
Date: Fri, 24 Feb 2017 13:00:00 -0800

From: Spasm [mailto:[email-masked]] On Behalf Of Phillip Hallam-Baker
Sent: Friday, February 24, 2017 12:54 PM
To: Yoav Nir <[email-masked]>
Cc: SPASM <[email-masked]>
Subject: Re: [Spasm] Add SHA-3 to PKIX

On Fri, Feb 24, 2017 at 3:40 PM, Yoav Nir <[email-masked] <mailto:[email-masked]> > wrote:

​No.​

​NIST EdDSA withj SHA-2 is in the CABForum list of approved algorithms. But I can't see there being momentum behind uses of those curves in the future. I think we have made a decision to focus on Curve-X

[JLS] I am having a bit of a problem with this.  EdDSA w/ 25519 uses SHA-2, but w/448 uses SHA-3.  The blanket statement of Curve-X uses SHA-2 is not correc.t

Jim

I don't see any need to remove them. Particularly when the curve that is used most is P-384 which is rather stronger than 25519. But Curve-X is our chosen path and we should not re-litigate that.

​There are a large number of algorithms that I would like to see purged. ​In fact pretty much everything that isn't AES, RSA, SHA-2, SHA-3, Curve-X, Cha-Cha20 or close relatives (Blake2, HMAC).

​We don't actually add security by adding new algorithms. We only add security byu removing the weak ones. Anything that is not widely used and necessary is just more attack surface.​

---

From: Yoav Nir <[email-masked]>
Date: Fri, 24 Feb 2017 23:04:32 +0200

> On 24 Feb 2017, at 23:00, Jim Schaad <[email-masked]> wrote:
> 
> 
> 
> From: Spasm [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Phillip Hallam-Baker
> To: Yoav Nir <[email-masked] <mailto:[email-masked]>>
> Cc: SPASM <[email-masked] <mailto:[email-masked]>>
> On Fri, Feb 24, 2017 at 3:40 PM, Yoav Nir <[email-masked] <mailto:[email-masked]>> wrote:

And EdDSA is not NIST-approved (nor either of the curves). I think Phil meant ECDSA there.

Yoav

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 24 Feb 2017 16:22:30 -0500

On Fri, Feb 24, 2017 at 4:04 PM, Yoav Nir <[email-masked]> wrote:

> *From:* Spasm [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Phillip Hallam-Baker
> *Sent:* Friday, February 24, 2017 12:54 PM
> *To:* Yoav Nir <[email-masked]>
> *Cc:* SPASM <[email-masked]>
> *Subject:* Re: [Spasm] Add SHA-3 to PKIX
>
> ​NIST EdDSA withj SHA-2 is in the CABForum list of approved algorithms.
> But I can't see there being momentum behind uses of those curves in the
> future. I think we have made a decision to focus on Curve-X
>
> [JLS] I am having a bit of a problem with this.  EdDSA w/ 25519 uses
> SHA-2, but w/448 uses SHA-3.  The blanket statement of Curve-X uses SHA-2
> is not correc.t
>
> Jim
>
>
​No, I don't care about the NIST curves or algorithms at this point. Just
more legacy.

I thought I lost the SHA-3 battle on EdDSA. Glad to see I was wrong.

Yep, doing SHA-3 for 448 makes sense as you want to use SHAKE, its the
primitive designed to do what the signature needs.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 27 Feb 2017 14:15:35 +0100

On Fri, 2017-02-24 at 11:47 -0500, Phillip Hallam-Baker wrote:
> algorithm. Given the role of the WebPKI, we need two algorithms based
> on different principles.
> 

Hi,
 Do you here mean the SHAKE algorithms or the SHA3 ones? As far as I
see in the NIST web site, the SHA3 ones require no parameters [0]. The
SHAKE ones, indeed they do.

[0]. http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/algorithms.h
tml

> * HSM vendors won't produce product until there is a demand.

I'd add here also:
 * TLS 1.3 did not include the algorithm in the current draft nor plans
to include it until there is adoption

> 3) Submit a CABForum Ballot to adopt SHA-3 as a approved algorithm

Certainly a good idea.

regards,
Nikos

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Mon, 27 Feb 2017 13:41:10 +0000

From: Spasm <[email-masked]<mailto:[email-masked]>> on behalf of Nikos Mavrogiannopoulos <[email-masked]<mailto:[email-masked]>>
Date: Monday, February 27, 2017 at 8:15 AM
To: Phillip Hallam-Baker <[email-masked]<mailto:[email-masked]>>, SPASM <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Spasm] Add SHA-3 to PKIX

parameters and so it is not quite a straight drop in replacement for
SHA-2.

Hi,

Hi Nikos,

We could use the OIDs for the SHAKEs which do not have output length parameter with an explicit policy being that output length of SHAKE128 is 256 bits and output length of SHAKE256 is 512 bits.

Quynh.

I'd add here also:

Certainly a good idea.

regards,
Nikos

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

---

From: Peter Bowen <[email-masked]>
Date: Mon, 27 Feb 2017 06:15:33 -0800

> parameters and so it is not quite a straight drop in replacement for SHA-2.

Where do you see that there are parameters called for in the NIST spec?

On http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/algorithms.html, I see:

nistAlgorithms OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) country(16)
us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) }
sigAlgs OBJECT IDENTIFIER ::= { nistAlgorithms 3 }

id-dsa-with-sha3-224 ::= { sigAlgs 5 }
id-dsa-with-sha3-256 ::= { sigAlgs 6 }
id-dsa-with-sha3-384 ::= { sigAlgs 7 }
id-dsa-with-sha3-512 ::= { sigAlgs 8 }

id-ecdsa-with-sha3-224 ::= { sigAlgs 9 }
id-ecdsa-with-sha3-256 ::= { sigAlgs 10 }
id-ecdsa-with-sha3-384 ::= { sigAlgs 11 }
id-ecdsa-with-sha3-512 ::= { sigAlgs 12 }

id-rsassa-pkcs1-v1_5-with-sha3-224 ::= { sigAlgs 13 }
id-rsassa-pkcs1-v1_5-with-sha3-256 ::= { sigAlgs 14 }
id-rsassa-pkcs1-v1_5-with-sha3-384 ::= { sigAlgs 15 }
id-rsassa-pkcs1-v1_5-with-sha3-512 ::= { sigAlgs 16 }

Yes, SHAKE has parameters, but SHA3-* does not AFAICT.

> parts in this system and one of the major problems is that many parties wait
> for the others to act before they act.
>
> draft-ietf-curdle-pkix-newcurves is in WG last call. I was previously
> waiting on that draft passing the IESG to raise Curve-X in CABForum.
>

Why not include (FF)DSA and ECDSA as well? They might be as en vogue
as EdDSA but are something handled by HSMs today.

> approach. I would expect the two would quickly get in sync.

Thanks,
Peter

---

From: Rob Stradling <[email-masked]>
Date: Mon, 27 Feb 2017 14:28:12 +0000

> Where do you see that there are parameters called for in the NIST spec?

If there are no parameters, then there still needs to be a specification 
that says how to encode "no parameters" in an AlgorithmIdentifier!

Is it like this...
https://tools.ietf.org/html/rfc3279#section-2.2.1
   "When any of these three OIDs appears within the ASN.1 type
    AlgorithmIdentifier, the parameters component of that type SHALL be
    the ASN.1 type NULL."
?

Or like this...
https://tools.ietf.org/html/rfc3279#section-2.2.3
   "When the ecdsa-with-SHA1 algorithm identifier appears as the
    algorithm field in an AlgorithmIdentifier, the encoding MUST omit the
    parameters field."
?

Or something else?

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 27 Feb 2017 09:54:36 -0500

> id-rsassa-pkcs1-v1_5-with-sha3-512 ::= { sigAlgs 16 }

​Someone suggested this was an issue. Since they are a likely implementer,
I assumed we at least need to tell them it isn't.

I can't see a need for the parameters. But we do need to tell people the
exact padding mode to use for PKIX. ​

> as EdDSA but are something handled by HSMs today.

​Might as well specify the full set in any PKIX related draft.
​
​They are certainly being used in the WebPKI.​

---

From: Sean Turner <[email-masked]>
Date: Mon, 27 Feb 2017 16:59:40 -0500

> On Feb 27, 2017, at 9:28 AM, Rob Stradling <[email-masked]> wrote:
> 
> If there are no parameters, then there still needs to be a specification that says how to encode "no parameters" in an AlgorithmIdentifier!

I don’t recall seeing a spec that says what to do about the parameters, but I helped with the RFC5480 update to RFC3279 and will volunteer to do another one.

spt

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 27 Feb 2017 17:07:07 -0500

Thanks,

If nobody has firm views, my preference would be as close to the way RSA is
handled as is possible. But I am protecting my code :-)

On Mon, Feb 27, 2017 at 4:59 PM, Sean Turner <[email-masked]> wrote:

> I don’t recall seeing a spec that says what to do about the parameters,
> but I helped with the RFC5480 update to RFC3279 and will volunteer to do
> another one.
>
> spt
> [email-masked]

---

From: Russ Housley <[email-masked]>
Date: Mon, 27 Feb 2017 17:23:07 -0500

The work to add SHA-3 toPKIX (and possibly S/MIME) is not in the current charter.  In the past, Stephen was strongly against anything in the LAMPS charter that did not have a high probablility of being implemented.  So, if this work was added to the charter, who would implement it?  Please speak on the list.

Note that the current charter says:

> In addition, the LAMPS Working Group may investigate other updates to 
> the documents produced by the PKIX and S/MIME Working Groups, but the 
> LAMPS Working Group shall not adopt any of these potential work items 
> without rechartering. No such re-chartering is envisaged until one or 
> more of the above work items have been successfully delivered to the RFC 
> editor queue. 

Since our first document is in IESG Evaluation and the other two are in WG Last Call, I would expect that this criteria will be met shortly.

Russ

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 27 Feb 2017 18:07:21 -0500

On Mon, Feb 27, 2017 at 5:23 PM, Russ Housley <[email-masked]> wrote:

> The work to add SHA-3 toPKIX (and possibly S/MIME) is not in the current
> charter.  In the past, Stephen was strongly against anything in the LAMPS
> charter that did not have a high probablility of being implemented.  So, if
> this work was added to the charter, who would implement it?  Please speak
> on the list.
>
> Since our first document is in IESG Evaluation and the other two are in WG
> Last Call, I would expect that this criteria will be met shortly.

​I agree about not wanting to document stuff that is not going to be used.

The point of this is to get a sounding from the parties that would be doing
the deployment in CABForum. To pass a ballot has to have a majority of the
Browsers and 2/3rd of the CAs.

We can't hold a ballot on adding anything to the approved algorithms until
we have the RFC. But we can have a motion of intent to do so.