Subject: [Curdle] SHA3 should be in scope.

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 9 Dec 2015 23:21:41 -0500

Whether or not we decide we should be using SHA2 or SHA3 across the board,
we should make sure every application supports both:

* The additional effort of doing SHA3 in CURDLE is minimal.

* If we don't do SHA3 in CURDLE, people will write a series of separate
drafts. This will be more work for the Security AD, IESG, IANA and the RFC
Editor and the result is not likely to be as consistent or as good.

* We should aim to have exactly two algorithms for each cryptographic
primitive. A preferred algorithms that applications can expect to be
supported and a 'hot spare' that applications should implement wherever
possible in case of need. The hot spare should ideally be based on a
different principle to the preferred.

Right now SHA2 is the preferred digest function and I don't expect that to
change. But the SHA1->SHA2 transition was a lot harder than it should have
been and left a lot more broken gear than the MD5->SHA1 transition. The
difference was that for MD5 we had a hot spare but a lot of vendors didn't
even start to think about implementing SHA2 until the first compromise of
SHA1 was announced.

I do not see this as a slippery slope as the primary and hot-spare slots
for every other algorithm are already filled. For public key we have RSA
and the CFRG-ECC schemes. For symmetric encryption we have AES and
CHA-CHA20. This is just rounding things out for digest functions so we have
two options there.

RSA is going to be the preferred algorithm until the CFRG work is complete
and has seen significant deployment. That is still at least 5 years off
which is a pity because it is cutting it awfully close. My expectation is
that as soon as CFRG is done with the ECC curve work, the next focus of
attention will be public key systems that are quantum resistant, (if we can
convince ourselves such schemes actually exist).

So by the time we are phasing RSA out, I expect that we will be looking at
algorithms that have not been invented yet to replace it. Adding SHA3 to
CURDLE is not a slippery slope.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 10 Dec 2015 06:50:15 +0200

Hi, Phil

Not against this, but consider that SHA3 has been available for a while, and I haven’t heard of any IETF group beginning work on standardizing it. Compare and contrast with Curve25519, ChaCha20/Poly1305 and EdDSA that had and have drafts in several working groups even before the final documents were published.

The only group that is considering SHA3 is CFRG (for EdDSA-448). I have heard some people on other lists expressing a preference to ignore SHA3 and standardize instead on Blake2 as the hot spare or even the primary.

I don’t think the ADs want Curdle to shove a hot spare down into a bunch of protocols, especially when there are active working groups for these protocols (such as TLS or IPsecME).

Yoav

> On 10 Dec 2015, at 6:21 AM, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> Whether or not we decide we should be using SHA2 or SHA3 across the board, we should make sure every application supports both:
> 
> * If we don't do SHA3 in CURDLE, people will write a series of separate drafts. This will be more work for the Security AD, IESG, IANA and the RFC Editor and the result is not likely to be as consistent or as good.
> 
> * We should aim to have exactly two algorithms for each cryptographic primitive. A preferred algorithms that applications can expect to be supported and a 'hot spare' that applications should implement wherever possible in case of need. The hot spare should ideally be based on a different principle to the preferred.
> 
> Right now SHA2 is the preferred digest function and I don't expect that to change. But the SHA1->SHA2 transition was a lot harder than it should have been and left a lot more broken gear than the MD5->SHA1 transition. The difference was that for MD5 we had a hot spare but a lot of vendors didn't even start to think about implementing SHA2 until the first compromise of SHA1 was announced.
> 
> 
> I do not see this as a slippery slope as the primary and hot-spare slots for every other algorithm are already filled. For public key we have RSA and the CFRG-ECC schemes. For symmetric encryption we have AES and CHA-CHA20. This is just rounding things out for digest functions so we have two options there.
> 
> RSA is going to be the preferred algorithm until the CFRG work is complete and has seen significant deployment. That is still at least 5 years off which is a pity because it is cutting it awfully close. My expectation is that as soon as CFRG is done with the ECC curve work, the next focus of attention will be public key systems that are quantum resistant, (if we can convince ourselves such schemes actually exist).
> 
> So by the time we are phasing RSA out, I expect that we will be looking at algorithms that have not been invented yet to replace it. Adding SHA3 to CURDLE is not a slippery slope.
> 
> _______________________________________________
> Curdle mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 10 Dec 2015 00:57:04 -0500

On Wed, Dec 9, 2015 at 11:50 PM, Yoav Nir <[email-masked]> wrote:

> Hi, Phil
>
> Not against this, but consider that SHA3 has been available for a while,
> and I haven’t heard of any IETF group beginning work on standardizing it.
> Compare and contrast with Curve25519, ChaCha20/Poly1305 and EdDSA that had
> and have drafts in several working groups even before the final documents
> were published.
>

The standard was only published on 15th August 2015. And even though
everyone knew what it was going to say, we could hardly begin a standards
effort until the FIPS was published.

> The only group that is considering SHA3 is CFRG (for EdDSA-448). I have
> heard some people on other lists expressing a preference to ignore SHA3 and
> standardize instead on Blake2 as the hot spare or even the primary.
>

I can't see that flying. Blake was an entrant in the SHA3 competition.
Blake2 has only been published 3 years and has not received anything like
the attention the competition entries did. It hasn't even received as much
attention as Blake.

I don’t think the ADs want Curdle to shove a hot spare down into a bunch of
> protocols, especially when there are active working groups for these
> protocols (such as TLS or IPsecME).
>

As I pointed out when CFRG was asked to pick curves 'for TLS', these would
inevitably become the defaults for everything else. There isn't exactly a
high bar for adding suites to either TLS or IPSEC.

I am a simple soul. I don't get into hypotheticals about what decisions a
WG might make. If someone wants to make the case that their application is
so special it should not be able to use the same crypto suite as pretty
much everything else then let them say so and give their reasons in public.

>From a process point of view, I expect that what is going to happen is that
work will begin in CURDLE on the applications that don't have a current WG
and then people involved in CURDLE are going to propose whatever is
necessary to the WGs that do exist to align things nicely.

---

From: John Mattsson <[email-masked]>
Date: Thu, 10 Dec 2015 09:46:29 +0000

I support doing SHA-3 in CURDLE for the reasons already laid down by Phillip. Striving for 2 different hash algorithms make very much sense. Historically not only implementers but also SDOs have been far too slow to adopt new algorithms.

SHA-3 is an excellent choice as it has a very different construction from SHA-2. It is already used in other standards as ETSI SAGE chose if as the basis for the new authentication and key generation set TUAK.

We should not end up in a situation where we do not even think about adding SHA-3 to protocols before any SHA-2 compromises are announced.

/John

From: Curdle <[email-masked]<mailto:[email-masked]>> on behalf of Phillip Hallam-Baker <[email-masked]<mailto:[email-masked]>>
Date: Thursday 10 December 2015 05:21
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Curdle] SHA3 should be in scope.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 10 Dec 2015 12:10:42 -0500

On Thu, Dec 10, 2015 at 12:00 PM, Paul Hoffman <[email-masked]>
wrote:

> The working group is less than a week old, and already we're discussing
> items explicitly outside the charter. Yuck.
>
> Note that the charter not only prohibits discussing hashes, but it also
> limits the WG to which the CURDLE work applies.
>
> If you actually care about getting the SHA3 work started (I don't), start
> a new WG that is focused on it, and that applies to all WGs in the IETF,
> particularly TLS.
>
> --Paul Hoffman
>

>From the announcement:

"A new IETF working group has been proposed in the Security Area. The IESG
has not made any determination yet. The following draft charter was
submitted, and is provided for informational purposes only. Please send
your comments to the IESG mailing list (iesg at ietf.org) by 2015-12-14."

The WG has not been formed yet. We are in charter discussion. Therefore
nothing is out of scope. My proposal is to refine the charter scope.

I raised the proposal here because that is what the Area Director told me
to do.

Creating a separate working group would mean double the work for the IESG,
IANA and RFC Editor. Independent drafts are likely to be worse. Getting
SHA2 consistently supported in IETF protocols took Russ at least three
years.

The cost of implementing crypto code is negligible. It is qualifying and
testing that takes the time. Each time we touch one of our systems we have
to go through QA again or risk something bad happening. That is why we
greatly prefer to do all the changes at once.

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 10 Dec 2015 09:00:12 -0800

If you actually care about getting the SHA3 work started (I don't), 
start a new WG that is focused on it, and that applies to all WGs in the 
IETF, particularly TLS.

--Paul Hoffman

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 10 Dec 2015 09:20:14 -0800

> nothing is out of scope. My proposal is to refine the charter scope.

Whoops, my mistake. I got ahead of myself.

Just to be clear then, you are proposing to add SHA3 to the charter 
*and* to widen the WGs covered to all groups that use crypto? It would 
be weird to only do the first but to be discussing the use of SHA3 in 
TLS, for example.

> SHA2 consistently supported in IETF protocols took Russ at least three

The flip side of the "double the work of the IESG" argument is that 
there is a lot of interest in working on the new curves and, so far, 
almost none for SHA3. Therefore, overlapping the two will make this WG 
harder to manage.

Having one or two WGs would not affect the work for the IANA or RFC 
Editor.

Fully agree about independent drafts: if there is a move towards SHA3, 
it should be done in the various WGs, or in a collection WG.

> greatly prefer to do all the changes at once.

Fully agree. However, I disagree that it should be done in CURDLE. If it 
spun up as a separate WG, it would be easier for those folks to focus on 
which bits of SHA3 we want to use, which we don't, and the whole BLAKE2 
question (which I know you reject, but others embrace).

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 10 Dec 2015 12:57:36 -0500

On Thu, Dec 10, 2015 at 12:20 PM, Paul Hoffman <[email-masked]>
wrote:

> Just to be clear then, you are proposing to add SHA3 to the charter *and*
> to widen the WGs covered to all groups that use crypto? It would be weird
> to only do the first but to be discussing the use of SHA3 in TLS, for
> example.

No, just add SHA3 to the scope.

We currently have three sets of protocols that use crypto

1) Stuff nobody uses (PEM, MOSS, etc.)
2) Protocols that are in active use but don't have an active WG
3) Protocols that have an active WG.

The point of CURDLE is to address group 2. I don't think anyone is
proposing to add the CFRG curves for use in PEM.

What happens on 3 is really up to the relevant WG chairs and the
responsible AD. I don't see any need to assume that this is going to be a
massive turf war. There are only two current protocol WGs that define
crypto algs directly, IPSECME and TLS.

TLS has cipher suites which is a big complication because you end up with
the x*y*z combinatorial explosion. IPSEC doesn't have that issue.

There is obviously going to need to be protocol specific input for every
one of the protocols affected. Introducing new signature and encryption
algorithms introduces a lot of complexity. Swapping SHA2 for SHA3 isn't
anywhere near as complex.

> The flip side of the "double the work of the IESG" argument is that there
> is a lot of interest in working on the new curves and, so far, almost none
> for SHA3. Therefore, overlapping the two will make this WG harder to manage.
>

There are two reasons for the lack of interest in SHA3 to date. The first
was the lack of a FIPS till three months ago. But the bigger one was
knowing that a new set of Elliptic Curves were on their way.

> Having one or two WGs would not affect the work for the IANA or RFC Editor.
>

It will mean more documents and more sets of code point requests and more
people to interact with.

> Fully agree about independent drafts: if there is a move towards SHA3, it
> should be done in the various WGs, or in a collection WG.
>

So far, nobody has stated they support BLAKE2 themselves, only that
'others' like it. Until someone is prepared to put their name to the
proposal and back it up with arguments, BLAKE2 isn't even on the table.

Getting consistent support for SHA3 is an achievable goal. Getting
consistent support for a new proposal by one of the groups that entered the
competition and didn't win is not very likely.

The other reason for choosing SHA3 is that it helps strengthen the case for
getting NIST to support the new CFRG algorithms in place of their existing
curves. NIST has already taken a step back from them. The NIST objective
has been to persuade the industry to move to ECC. The plethora of curves is
obviously an obstacle at this point, moving to CFRG curves is a win for all
concerned. But persuading a large bureaucracy on that point is not easy.
Recognizing their SHA3 effort makes the case a lot easier.

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 10 Dec 2015 20:47:23 +0200

> knowing that a new set of Elliptic Curves were on their way.
 
In my opinion, there are two reasons:
1) SHA-2 is good enough.
2) SHA-3 has no real advantages over SHA-2.

It seems the goal of NIST was to get something strong that is as
different from SHA-2 as possible, so it is maximally unlikely that
whatever could bring down SHA-2 would also take SHA-3 with it.
 
> proposal and back it up with arguments, BLAKE2 isn't even on the table.

The second reason I gave above would be false for BLAKE2. For this reason,
it seems to be getting much more real-world use than SHA-3.

Also, there is RFC about Blake2, and AFAIK not one even in process for
SHA-3, nevermind that I consider FIPS202 pretty unreadable due to
dealing with cases nobody really cares about.
 
> competition and didn't win is not very likely.

As of currently, I don't consider TLS 1.3 draft currently capable of taking
any ciphersuite that doesn't have SHA2-256 or SHA2-384 PRF. Not SHA-3,
not BLAKE2.

> Recognizing their SHA3 effort makes the case a lot easier.

I don't see why this is the case. Also, PKIX has problems one hits if
one tries to use SHA-3 (outside black-box settings like some Ed448 hash
proposals)...

-Ilari

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 10 Dec 2015 14:02:16 -0500

On Thu, Dec 10, 2015 at 1:47 PM, Ilari Liusvaara <[email-masked]>
wrote:

> proposals)..

Could you specify them?

PKIX uses an algorithm ID that conflates the digest and the public key
algorithm. But that is all. Every crypto lib I have used allows for a
choice of digest function. The RSA message format has to be configured to
ensure the digest OID is embedded but that is straightforward.

---

From: "Dang, Quynh" <[email-masked]>
Date: Thu, 10 Dec 2015 19:15:03 +0000

Hi Ilari,

Could you please explain this "FIPS202 pretty unreadable due to
dealing with cases nobody really cares about." ?

Thank you in advance!

Quynh.

From: Ilari Liusvaara <[email-masked]<mailto:[email-masked]>>
Date: Thu, Dec 10, 2015 at 1:47 PM
Subject: Re: [Curdle] SHA3 should be in scope.
To: Phillip Hallam-Baker <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>

-Ilari

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

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 10 Dec 2015 21:35:12 +0200

> dealing with cases nobody really cares about." ?

The bit-level representation due to supporting things like:

- Lane width not 64.
- Round count not 24.
- Bit-length inputs (these are rarely implemented).

If one omits those, one can get much much compact and understandable
description.

-Ilari

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 10 Dec 2015 21:37:40 +0200

> ensure the digest OID is embedded but that is straightforward.

Oh yeah, it would work fine with RSA. It is the ECDSA that runs into
trouble. Basically, you for good crypto practice, you need to either fix
the algorithms at key level or have solid indication in the output
itself. Neither is easily possible with ECDSA in PKIX.

-Ilari

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 10 Dec 2015 15:08:53 -0500

> itself. Neither is easily possible with ECDSA in PKIX.

That is a CFRG issue. There is a poll at present.

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 10 Dec 2015 22:29:14 +0200

> That is a CFRG issue. There is a poll at present.

The way current drafts are written, would not be a problem with EdDSA,
even if one defined multiple signature primitives sharing a curve
(however, there is alternative proposal for PKIX that does suffer
from multi-hash problems).

(The algorithms do black-box encapsulation of hashes or possibly
indicate it).

-Ilari

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 10 Dec 2015 14:03:03 -0800

> -----Original Message-----
> From: Curdle [mailto:[email-masked]] On Behalf Of Ilari Liusvaara
> Sent: Thursday, December 10, 2015 11:38 AM
> To: Phillip Hallam-Baker <[email-masked]>
> Cc: [email-masked]
> > > I don't see why this is the case. Also, PKIX has problems one hits
> > > if one tries to use SHA-3 (outside black-box settings like some
> > > Ed448 hash proposals)..
> > >
> >
> > Could you specify them?
> >
> > choice of digest function. The RSA message format has to be configured
> > to ensure the digest OID is embedded but that is straightforward.
> 
trouble.
> Basically, you for good crypto practice, you need to either fix the
algorithms at
> key level or have solid indication in the output itself. Neither is easily
possible
> with ECDSA in PKIX.

I would hope that we would not be defining new PKCS v1.5 signature
algorithms.  If it is PSS then the algorithm is not fixed and is
potentially, but probably not, a problem.