Subject: [TLS] SHA-3 in SignatureScheme

From: Hubert Kario <[email-masked]>
Date: Thu, 01 Sep 2016 19:38:36 +0200

The SHA-3 standard is already published and accepted[1], shouldn't TLSv1.3 
include signatures with those hashes then?

I think at least the following signature algorithms should be added:
ecdsa_secp256r1_sha3_256
ecdsa_secp384r1_sha3_384
ecdsa_secp521r1_sha3_512

rsa_pss_sha3_256
rsa_pss_sha3_384
rsa_pss_sha3_512

 1 - https://www.federalregister.gov/articles/2015/08/05/2015-19181/
announcing-approval-of-federal-information-processing-standard-fips-202-sha-3-
standard
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 1 Sep 2016 12:43:31 -0500

> include signatures with those hashes then?

Why does it need to be part of the core spec instead of a separate document?

> announcing-approval-of-federal-information-processing-standard-fips-202-sha-3-

I think we generally end up with a RFC specifying how to use them in
IETF protocols and then cite the RFC instead of the NIST publication
directly.

-Ben

---

From: Hubert Kario <[email-masked]>
Date: Thu, 01 Sep 2016 20:17:07 +0200

> Why does it need to be part of the core spec instead of a separate document?

because: we also are adding RSA-PSS to TLSv1.2 in this document,
I don't see why it needs to be delayed. Finally, TLSv1.2 added SHA-2 just like 
that, it was not tacked on later.

Note that I do not suggest that implementation of SHA-3 signature algorithms 
should be recommended, let alone mandatory for TLSv1.3, just that the standard 
include the codepoints.

> > announcing-approval-of-federal-information-processing-standard-fips-202-sh
> > a-3- standard
> 

I would see that as necessary for RSASSA-PKCS1_v1.5, as it needs the values 
for hash info, but neither ECDSA nor RSASSA-PSS require them. I think that RFC 
3447 is enough to implement RSASSA-PSS with SHA-3.

Also, is see RFC 5246 referencing the NIST publication directly, not the RFC 
4634...

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Thu, 1 Sep 2016 18:30:54 +0000

> -----Original Message-----
> From: TLS [mailto:[email-masked]] On Behalf Of Hubert Kario
> Sent: Thursday, September 01, 2016 2:17 PM
> To: Benjamin Kaduk
> Cc: <[email-masked]>
> Subject: Re: [TLS] SHA-3 in SignatureScheme
> 
> > > The SHA-3 standard is already published and accepted[1], shouldn't
> > > TLSv1.3 include signatures with those hashes then?
> >
> because: we also are adding RSA-PSS to TLSv1.2 in this document, I don't see
> why it needs to be delayed. Finally, TLSv1.2 added SHA-2 just like that, it was
> not tacked on later.

IIRC, SHA-2 was a special case; SHA-1 was demonstrated to be cryptographically weaker than expected and so we needed to have a secure alternative ASAP.

The SHA-3 is not like that; there's no evidence that suggests that SHA-2 is weak; the only incentive to implementing SHA-3 is "we'll, it is a standard, and so we might as well support it".

IMHO, how SHA-2 was handled should be viewed as an exception, not a rule for how we should proceed in the future...

---

From: Dave Garrett <[email-masked]>
Date: Thu, 1 Sep 2016 19:22:18 -0400

> The SHA-3 is not like that; there's no evidence that suggests that SHA-2 is weak; the only incentive to implementing SHA-3 is "we'll, it is a standard, and so we might as well support it".

The reason I see is that we currently specify exactly one valid hash algorithm (in a variety of sizes). The precedent argument is good enough for me. I think adding it in this document is definitely worth considering. I don't want to wait until SHA-2 is considered weak to provide an alternative, if we can avoid it.

Dave

---

From: Hubert Kario <[email-masked]>
Date: Fri, 02 Sep 2016 12:08:47 +0200

On Thursday, 1 September 2016 19:22:18 CEST Dave Garrett wrote:
> > > > Why does it need to be part of the core spec instead of a separate
> > > 
> > > document?
> > > 
> > > because: we also are adding RSA-PSS to TLSv1.2 in this document, I don't
> > > see why it needs to be delayed. Finally, TLSv1.2 added SHA-2 just like
> > IIRC, SHA-2 was a special case; SHA-1 was demonstrated to be
> > cryptographically weaker than expected and so we needed to have a secure
> > alternative ASAP.
> > 
> > The SHA-3 is not like that; there's no evidence that suggests that SHA-2
> > is weak; the only incentive to implementing SHA-3 is "we'll, it is a
> > standard, and so we might as well support it".
> The reason I see is that we currently specify exactly one valid hash
> algorithm (in a variety of sizes). The precedent argument is good enough
> for me. I think adding it in this document is definitely worth considering.
> I don't want to wait until SHA-2 is considered weak to provide an
> alternative, if we can avoid it.

I've created a PR for it: https://github.com/tlswg/tls13-spec/pull/616

I haven't changed any recommendations, the recommended hashes to implement are 
still SHA-2 based, and I don't think we should change that given that 
certificates just now are transitioning to SHA-256 because of incompatibility 
fears.

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 2 Sep 2016 13:42:40 +0300

> certificates just now are transitioning to SHA-256 because of incompatibility 

Just tweaking the signatures is not enough. There is also the PRF hash,
and using weak hash there has, umm... rather bad consequences.

I also don't see why this should be in TLS 1.3 spec, instead of being
its own spec (I looked up how much process BS it would be to get the
needed registrations: informative RFC would do).

-Ilari

---

From: Hubert Kario <[email-masked]>
Date: Fri, 02 Sep 2016 13:09:36 +0200

On Friday, 2 September 2016 13:42:40 CEST Ilari Liusvaara wrote:
> > I haven't changed any recommendations, the recommended hashes to implement
> > are still SHA-2 based, and I don't think we should change that given that
> > certificates just now are transitioning to SHA-256 because of
> > incompatibility fears.
> 

SHA-3 ciphersuites added

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 2 Sep 2016 04:32:06 -0700

On Fri, Sep 2, 2016 at 3:42 AM, Ilari Liusvaara <[email-masked]>
wrote:

> incompatibility

I also am not following why we need to do this now. The reason we defined
SHA-2 in
a new RFC was because (a) SHA-1 was looking weak and (b) we had to make
significant
changes to TLS to allow the use of SHA-2. This does not seem to be that
case.

-Ekr

>
> -Ilari
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Dave Garrett <[email-masked]>
Date: Fri, 2 Sep 2016 11:25:38 -0400

On Friday, September 02, 2016 07:32:06 am Eric Rescorla wrote:
> On Fri, Sep 2, 2016 at 3:42 AM, Ilari Liusvaara <[email-masked]> wrote:
> I also am not following why we need to do this now. The reason we defined SHA-2 in
> a new RFC was because (a) SHA-1 was looking weak and (b) we had to make significant
> changes to TLS to allow the use of SHA-2. This does not seem to be that case.

I don't think we strictly _need_ to do this now, however I think it's a good idea given that we'll need to do it eventually and we can do it now and get people to consider implementing it more easily as part of a larger spec than later as a subsequent standalone. Doing it now gives it far greater visibility and should be relatively simple and quick to do.

Dave

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 2 Sep 2016 10:04:29 -0700

On Fri, Sep 2, 2016 at 8:25 AM, Dave Garrett <[email-masked]> wrote:

> I don't think we strictly _need_ to do this now, however I think it's a
> good idea given that we'll need to do it eventually

I'm not sure that that's true.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 2 Sep 2016 10:05:45 -0700

> I'm not sure that that's true.

To clarify: we might need to do this for one of several reasons:

- Some sort of completeness theory
- SHA-256 starts to look much weaker

The second could certainly happen, but if it doesn't, it's not clear that
there's really a completeness need.

-Ekr

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 2 Sep 2016 12:06:55 -0500

On 09/02/2016 12:04 PM, Eric Rescorla wrote:
>
>
> On Fri, Sep 2, 2016 at 8:25 AM, Dave Garrett <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     > On Fri, Sep 2, 2016 at 3:42 AM, Ilari Liusvaara
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     I don't think we strictly _need_ to do this now, however I think
>     it's a good idea given that we'll need to do it eventually 
>
>

Predicting future needs is not always reliable, yes.
>From a release-engineering (standards-engineering?) perspective, I still
don't see any reasons to add it now, and do see reasons to not add it now.

-Ben

---

From: Hubert Kario <[email-masked]>
Date: Fri, 02 Sep 2016 19:27:58 +0200

On Friday, 2 September 2016 12:06:55 CEST Benjamin Kaduk wrote:
> >     > > its own spec (I looked up how much process BS it would be to
> >     
> >     get the
> >     
> >     > I also am not following why we need to do this now. The reason
> >     
> >     we defined SHA-2 in
> >     
> >     > a new RFC was because (a) SHA-1 was looking weak and (b) we had
> >     
> >     to make significant
> >     
> >     > changes to TLS to allow the use of SHA-2. This does not seem to
> >     
> >     be that case.
> >     

what would be the reasons not to add it now?

---

From: Yoav Nir <[email-masked]>
Date: Fri, 2 Sep 2016 21:38:33 +0300

> On 2 Sep 2016, at 8:27 PM, Hubert Kario <[email-masked]> wrote:
> 

Several reasons:
 - This is a core spec. Those don’t traditionally specify new algorithms unless they’re MTI (like SHA-256 is TLS 1.2 and RSAPSS here)
 - For now, SHA-3 is yet another national algorithm. Why add this and not Streebog? [1]
 - Who’s to tell whether SHA-2 breaks earlier than SHA-3?

So absent a desire to change MTI algorithms, I think publishing a “SHA-3 and its use in TLS/IPsec/SSH/other” document is a fine idea, but not as part of any core protocol.

Yoav

[1] I’m sure there are excellent reasons why SHA-3 is better. We don’t just add any national standard unless we think we need it.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 2 Sep 2016 12:01:56 -0700

On Fri, Sep 2, 2016 at 11:38 AM, Yoav Nir <[email-masked]> wrote:

>  - This is a core spec. Those don’t traditionally specify new algorithms
> unless they’re MTI (like SHA-256 is TLS 1.2 and RSAPSS here)

I'm 100% in favor of adding any algorithm called Streebog. Also, perhaps
Orcslayer.

-Ekr

> So absent a desire to change MTI algorithms, I think publishing a “SHA-3
> and its use in TLS/IPsec/SSH/other” document is a fine idea, but not as
> part of any core protocol.
>
> Yoav
>
> [1] I’m sure there are excellent reasons why SHA-3 is better. We don’t
> just add any national standard unless we think we need it.
>
>
>

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 2 Sep 2016 19:07:29 +0000

We should not add new "this is [cool|national-standard|strong|emerging]"  crypto mechanisms to this spec.

Any invention we do here, should be around the protocol, not the crypto.
	/r$

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 2 Sep 2016 14:11:48 -0500

> what would be the reasons not to add it now?

It seems that Yoav was faster than me, but the two main ones I had in
mind were:

We want the core protocol to be as small as possible while still
fulfilling its goals.  We already have extension mechanisms for adding
new ciphers, so there is no need to have another one in the core spec as
a backup [unless it's MTI].

We want to keep the number of changes down as we approach a final
version, to lower the burden of (re)review, particularly by the
cryptographers who are gracious enough to engage in analysis of the
pre-final versions.

-Ben

---

From: Hubert Kario <[email-masked]>
Date: Fri, 02 Sep 2016 21:21:00 +0200

On Friday, 2 September 2016 21:38:33 CEST Yoav Nir wrote:
> - For now,
> SHA-3 is yet another national algorithm. Why add this and not Streebog? [1]

But then we have:
* AES and ChaCha (two modes for the former one even)
* RSA and ECDSA
* NIST curves and Bernstein curves
* ECDHE key exchange an DHE key exchange

only the SHA-2 stands alone...

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 2 Sep 2016 12:22:12 -0700

> only the SHA-2 stands alone...

We have SHA-256 and SHA-384.

-Ekr

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 2 Sep 2016 19:25:52 +0000

> * ECDHE key exchange an DHE key exchange

This is a good point to bring up, but I think it can be resolved easily.  AES/ChaCha -- if only mobile you'll do chacha else you have hardware assist and will do AES.  RSA and ECDSA -- you'll only do one, depending on which cert you bought from your CA, and who even has commercial ECDSA certs yet?  NIST v Bernstein might be harder, but the performance of X25519 will win out.  ECDHE vs DHE?  Who would ever bother to do DHE these days?

Now, how can you give clear guidance on when to pick SHA2 over SHA3?   It's different from the others because it is truly a multiplicative choice; all of the others have clear guidance on when to pick which.

--  
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Fri, 2 Sep 2016 19:28:03 +0000

On 9/2/16, 15:22 , "TLS on behalf of Eric Rescorla" <[email-masked] on behalf of [email-masked]> wrote:

But then we have:

No. By the same token we have AES-128, AES-256, ECDHE over P256, etc.

I support adding SHA-3 to the core. 

Alternatively, feel free to throw ChaCha out and define it separately. Same with Bernstein’s curves. Why keeping them all in the core?

---

From: Yoav Nir <[email-masked]>
Date: Sat, 3 Sep 2016 20:03:20 +0300

> On 2 Sep 2016, at 10:28 PM, Blumenthal, Uri - 0553 - MITLL <[email-masked]> wrote:

ChaCha is in RFC 7905
DJB’s curves are in RFC4492bis

The core spec just mentions them because it is revising the registry.

If there had been a “SHA-3 and its use in TLS” that applied to TLS 1.2, we’d mention it as well.

Yoav

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 05 Sep 2016 10:17:58 +0200

> I'm not sure that that's true.

It is unclear to me what is the intention. Due to the semantics of the
signatureAlgorithms extension in TLS 1.3, if the TLS 1.3 draft doesn't
define SHA3, it effectively _bans_ the usage of SHA3 in all certificate
chains intended to be used by TLS 1.3. If that's the intention then
yes, SHA3 should not be included.

In that case implementations of TLS 1.3 will have to wait for a SHA3
RFC to be published in order to enable the algorithm. That would
introduce a delay, and in certain occasions (e.g., firmware) we will
have TLS 1.3 implementations which may never support SHA3.

IMO, unless there are doubts about SHA3's adoption as a certificate
algorithm, it should be part of the TLS 1.3 spec.

regards,
Nikos

---

From: Yoav Nir <[email-masked]>
Date: Mon, 5 Sep 2016 11:48:37 +0300

> On 5 Sep 2016, at 11:17 AM, Nikos Mavrogiannopoulos <[email-masked]> wrote:
> 

I don’t think that’s anyone’s intention.

> have TLS 1.3 implementations which may never support SHA3.

Not necessarily. If you write a SHA-3 document now, and it is simple as such documents tend to be, it could go through the last calls before the TLS 1.3 document. If it makes a reference to the TLS 1.3 document it will end up waiting for TLS 1.3 in the RFC editor’s queue.

The upside is that this adds support for SHA-3 certificates even for TLS 1.2 implementations, which makes sense to me. If there are SHA-3 certificates out there, their use and deployment should not depend on TLS 1.3 implementations.

> algorithm, it should be part of the TLS 1.3 spec.

I have doubts. If you’re a CA and you’re going to issue a certificate, are you going to use SHA-2 that is supported by nearly everything, or SHA-3 that is supported by nothing. How about in 5 years when SHA-3 is supported by all updated browsers, but not by old browsers and dozens of different programmatic clients?

Besides, maybe we’ll all be using EdDSA and won’t need a hash at all.

I think the hard part for SHA-3 is not using it as a certificate hash but using it as a PRF.

Yoav

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 5 Sep 2016 13:02:12 +0300

> yes, SHA3 should not be included.

Huh? Can you explain your logic on how you arrived at that conclusion?

AFAICT, there is nothing preventing assigning new SignatureAlgorithm IDs
from 0705...FDFF range, with possible legacy type specified (for TLS 1.2
compatiblity).

So SHA-3 SignatureSchemes can be added to TLS 1.3 _and_ 1.2 post-hoc.

If the above is wrong, there is IMO a serious issue with the draft.

-Ilari

---

From: Gilles Van Assche <[email-masked]>
Date: Tue, 6 Sep 2016 13:47:48 +0200

Hello,

For RSA PSS, I would suggest to consider:
rsa_pss_shake128
rsa_pss_shake256
where SHAKE128 (or 256), as an exendable output function (XOF), directly
replaces the mask generating function MGF.

This would make RSA PSS simpler and more efficient.

Kind regards,
Gilles

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Tue, 6 Sep 2016 12:35:44 +0000

+1

On 9/6/16, 7:47 , "TLS on behalf of Gilles Van Assche" <[email-masked] on behalf of [email-masked]> wrote:

Hello,

rsa_pss_shake128

rsa_pss_shake256

Kind regards,

Gilles

ecdsa_secp256r1_sha3_256

ecdsa_secp384r1_sha3_384

ecdsa_secp521r1_sha3_512

rsa_pss_sha3_256

rsa_pss_sha3_384

rsa_pss_sha3_512

standard

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 7 Sep 2016 11:24:58 +0300

> This would make RSA PSS simpler and more efficient.

Well, my opinion on this thing still is:

- There is no real sense of urgent concern about SHA-2.
- This was not true with MD5/SHA-1 when TLS 1.2 was designed. There
  definitely was urgent concern.
- Therefore a few month delay for a separate spec is not a major issue.
- Delaying TLS 1.3 for that would be a major issue.
- TLS 1.3 has sufficient hooks to add this later (if you disagree,
  speak up, because it would be a major flaw).
- I don't expect people to implement stuff just because it is in TLS 1.3
  spec (but we shouldn't put crap there in case they do), so the
  "visibility loss" would be pretty minimal.

Therefore I think that this work should be pursued in a separate spec,
not in TLS 1.3 core.

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Fri, 9 Sep 2016 14:20:32 +1000

> Therefore I think that this work should be pursued in a separate spec,

I think that Ilari has it here.

---

From: Gilles Van Assche <[email-masked]>
Date: Fri, 9 Sep 2016 12:02:41 +0200

I don't mind if this is done in a separate spec.

My point was technically how to best use FIPS 202 in RSA PSS, and we (as
Keccak team) would be more than happy to help in that area.

Kind regards,
Gilles

---

From: Martin Thomson <[email-masked]>
Date: Fri, 9 Sep 2016 21:30:59 +1000

> Keccak team) would be more than happy to help in that area.

And I'm more than happy to have the work happen, but I think that we
can do things in stages.

---

From: Joseph Salowey <[email-masked]>
Date: Fri, 9 Sep 2016 13:56:19 -0700

While there seems to be some support for adding SHA-3 to TLS, we're not
seeing enough support to add it as part of TLS 1.3.  Individual drafts that
specify ciphers suites can always be separately considered though.

Cheers,

J&S