Re: [TLS] SHA-3 in SignatureScheme

[Joseph Salowey]

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

On Fri, Sep 9, 2016 at 4:30 AM, Martin Thomson 
wrote:

> On 9 September 2016 at 20:02, Gilles Van Assche 
> wrote:
> > 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.
>
> And I'm more than happy to have the work happen, but I think that we
> can do things in stages.
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] SHA-3 in SignatureScheme

[Martin Thomson]

On 9 September 2016 at 20:02, Gilles Van Assche  wrote:
> 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.

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] SHA-3 in SignatureScheme

[Gilles Van Assche]

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


On 09/09/16 06:20, Martin Thomson wrote:
> On 7 September 2016 at 18:24, Ilari Liusvaara  
> wrote:
>> Therefore I think that this work should be pursued in a separate spec,
>> not in TLS 1.3 core.
> I think that Ilari has it here.
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] SHA-3 in SignatureScheme

[Martin Thomson]

On 7 September 2016 at 18:24, Ilari Liusvaara  wrote:
> Therefore I think that this work should be pursued in a separate spec,
> not in TLS 1.3 core.

I think that Ilari has it here.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] SHA-3 in SignatureScheme

[Ilari Liusvaara]

On Tue, Sep 06, 2016 at 01:47:48PM +0200, Gilles Van Assche wrote:
> 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.

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] SHA-3 in SignatureScheme

[Blumenthal, Uri - 0553 - MITLL]

+1

 

On 9/6/16, 7:47 , "TLS on behalf of Gilles Van Assche"  wrote:

 

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

 

 

On 01/09/16 19:38, Hubert Kario wrote:

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

 



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] SHA-3 in SignatureScheme

[Gilles Van Assche]

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


On 01/09/16 19:38, Hubert Kario wrote:
> 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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] SHA-3 in SignatureScheme

[Ilari Liusvaara]

On Mon, Sep 05, 2016 at 10:17:58AM +0200, Nikos Mavrogiannopoulos wrote:
> On Fri, 2016-09-02 at 10:04 -0700, Eric Rescorla 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 
> > 
> > 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.

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] SHA-3 in SignatureScheme

[Yoav Nir]

> On 5 Sep 2016, at 11:17 AM, Nikos Mavrogiannopoulos  wrote:
> 
> On Fri, 2016-09-02 at 10:04 -0700, Eric Rescorla 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 
>> 
>> 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.

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

> 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.

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.

> IMO, unless there are doubts about SHA3's adoption as a certificate
> 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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] SHA-3 in SignatureScheme

[Nikos Mavrogiannopoulos]

On Fri, 2016-09-02 at 10:04 -0700, Eric Rescorla 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 
> 
> 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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] SHA-3 in SignatureScheme

[Yoav Nir]

> On 2 Sep 2016, at 10:28 PM, Blumenthal, Uri - 0553 - MITLL  
> wrote:
>  We have SHA-256 and SHA-384.
> 
> 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?

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




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] SHA-3 in SignatureScheme

[Blumenthal, Uri - 0553 - MITLL]

On 9/2/16, 15:22 , "TLS on behalf of Eric Rescorla"  wrote:

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...

 

 We have SHA-256 and SHA-384.

 

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?



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] SHA-3 in SignatureScheme

[Salz, Rich]

> 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

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: richs...@jabber.at Twitter: RichSalz


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] SHA-3 in SignatureScheme

[Eric Rescorla]

On Fri, Sep 2, 2016 at 12:21 PM, Hubert Kario  wrote:

> On Friday, 2 September 2016 21:38:33 CEST Yoav Nir wrote:
> > > On 2 Sep 2016, at 8:27 PM, Hubert Kario  wrote:
> > >
> > > On Friday, 2 September 2016 12:06:55 CEST Benjamin Kaduk wrote:
> > >> On 09/02/2016 12:04 PM, Eric Rescorla wrote:
> > >>> On Fri, Sep 2, 2016 at 8:25 AM, Dave Garrett  > >>>
> > >>> > wrote:
> > >>>On Friday, September 02, 2016 07:32:06 am Eric Rescorla wrote:
> >  On Fri, Sep 2, 2016 at 3:42 AM, Ilari Liusvaara
> > 
> > >>>>
> wrote:
> > > 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).
> > 
> >  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
> > >>>
> > >>> I'm not sure that that's true.
> > >>
> > >> 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.
> > >
> > > what would be the reasons not to add it now?
> >
> > 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?
>
> 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...
>

We have SHA-256 and SHA-384.

-Ekr


>
> --
> 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
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] SHA-3 in SignatureScheme

[Hubert Kario]

On Friday, 2 September 2016 21:38:33 CEST Yoav Nir wrote:
> > On 2 Sep 2016, at 8:27 PM, Hubert Kario  wrote:
> > 
> > On Friday, 2 September 2016 12:06:55 CEST Benjamin Kaduk wrote:
> >> On 09/02/2016 12:04 PM, Eric Rescorla wrote:
> >>> On Fri, Sep 2, 2016 at 8:25 AM, Dave Garrett  >>> 
> >>> > wrote:
> >>>On Friday, September 02, 2016 07:32:06 am Eric Rescorla wrote:
>  On Fri, Sep 2, 2016 at 3:42 AM, Ilari Liusvaara
>  
> >>>> wrote:
> > 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).
>  
>  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
> >>> 
> >>> I'm not sure that that's true.
> >> 
> >> 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.
> > 
> > what would be the reasons not to add it now?
> 
> 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?

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...

-- 
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

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] SHA-3 in SignatureScheme

[Benjamin Kaduk]

On 09/02/2016 12:27 PM, Hubert Kario wrote:
>
> 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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] SHA-3 in SignatureScheme

[Salz, Rich]

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$
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] SHA-3 in SignatureScheme

[Eric Rescorla]

On Fri, Sep 2, 2016 at 11:38 AM, Yoav Nir  wrote:

>
> > On 2 Sep 2016, at 8:27 PM, Hubert Kario  wrote:
> >
> > On Friday, 2 September 2016 12:06:55 CEST Benjamin Kaduk wrote:
> >> On 09/02/2016 12:04 PM, Eric Rescorla wrote:
> >>> On Fri, Sep 2, 2016 at 8:25 AM, Dave Garrett  >>>
> >>> > wrote:
> >>>On Friday, September 02, 2016 07:32:06 am Eric Rescorla wrote:
>  On Fri, Sep 2, 2016 at 3:42 AM, Ilari Liusvaara
> >>>
> >>>> wrote:
> > 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).
> 
>  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
> >>>
> >>> I'm not sure that that's true.
> >>
> >> 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.
> >
> > what would be the reasons not to add it now?
>
> 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]
>

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

-Ekr


>  - 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.
>
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] SHA-3 in SignatureScheme

[Yoav Nir]

> On 2 Sep 2016, at 8:27 PM, Hubert Kario  wrote:
> 
> On Friday, 2 September 2016 12:06:55 CEST Benjamin Kaduk wrote:
>> On 09/02/2016 12:04 PM, Eric Rescorla wrote:
>>> On Fri, Sep 2, 2016 at 8:25 AM, Dave Garrett >> 
>>> > wrote:
>>>On Friday, September 02, 2016 07:32:06 am Eric Rescorla wrote:
 On Fri, Sep 2, 2016 at 3:42 AM, Ilari Liusvaara
>>> 
>>>> wrote:
> 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).
 
 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
>>> 
>>> I'm not sure that that's true.
>> 
>> 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.
> 
> what would be the reasons not to add it now?

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.



___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] SHA-3 in SignatureScheme

[Hubert Kario]

On Friday, 2 September 2016 12:06:55 CEST Benjamin Kaduk wrote:
> On 09/02/2016 12:04 PM, Eric Rescorla wrote:
> > On Fri, Sep 2, 2016 at 8:25 AM, Dave Garrett  > 
> > > wrote:
> > On Friday, September 02, 2016 07:32:06 am Eric Rescorla wrote:
> > > On Fri, Sep 2, 2016 at 3:42 AM, Ilari Liusvaara
> > 
> > > wrote:
> > > > 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).
> > > 
> > > 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
> > 
> > I'm not sure that that's true.
> 
> 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.

what would be the reasons not to add it now?

-- 
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

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] SHA-3 in SignatureScheme

[Benjamin Kaduk]

On 09/02/2016 12:04 PM, Eric Rescorla wrote:
>
>
> On Fri, Sep 2, 2016 at 8:25 AM, Dave Garrett  > wrote:
>
> On Friday, September 02, 2016 07:32:06 am Eric Rescorla wrote:
> > On Fri, Sep 2, 2016 at 3:42 AM, Ilari Liusvaara
> > wrote:
> > > 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).
> >
> > 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 
>
>
> I'm not sure that that's true.
>

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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] SHA-3 in SignatureScheme

[Eric Rescorla]

On Fri, Sep 2, 2016 at 10:04 AM, Eric Rescorla  wrote:

>
>
> On Fri, Sep 2, 2016 at 8:25 AM, Dave Garrett 
> wrote:
>
>> On Friday, September 02, 2016 07:32:06 am Eric Rescorla wrote:
>> > On Fri, Sep 2, 2016 at 3:42 AM, Ilari Liusvaara <
>> ilariliusva...@welho.com> wrote:
>> > > 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).
>> >
>> > 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
>
>
> 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


>
> -Ekr
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] SHA-3 in SignatureScheme

[Eric Rescorla]

On Fri, Sep 2, 2016 at 8:25 AM, Dave Garrett  wrote:

> On Friday, September 02, 2016 07:32:06 am Eric Rescorla wrote:
> > On Fri, Sep 2, 2016 at 3:42 AM, Ilari Liusvaara <
> ilariliusva...@welho.com> wrote:
> > > 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).
> >
> > 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


I'm not sure that that's true.

-Ekr
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] SHA-3 in SignatureScheme

[Dave Garrett]

On Friday, September 02, 2016 07:32:06 am Eric Rescorla wrote:
> On Fri, Sep 2, 2016 at 3:42 AM, Ilari Liusvaara  
> wrote:
> > 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).
> 
> 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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] SHA-3 in SignatureScheme

[Blumenthal, Uri - 0553 - MITLL]

Speaking of PRF hash, I want to bring up the fact that‎ SHA-3 is a better PRF 
by design, as that was one of the explicitly stated competition requirements 
(unlike MD*, SHA-1, and SHA-2).

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: Ilari Liusvaara
Sent: Friday, September 2, 2016 06:44
To: Hubert Kario
Cc: tls@ietf.org
Subject: Re: [TLS] SHA-3 in SignatureScheme

On Fri, Sep 02, 2016 at 12:08:47PM +0200, Hubert Kario wrote:
> On Thursday, 1 September 2016 19:22:18 CEST Dave Garrett wrote:
> >
> > 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.

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls




smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] SHA-3 in SignatureScheme

[Eric Rescorla]

On Fri, Sep 2, 2016 at 3:42 AM, Ilari Liusvaara 
wrote:

> On Fri, Sep 02, 2016 at 12:08:47PM +0200, Hubert Kario wrote:
> > On Thursday, 1 September 2016 19:22:18 CEST Dave Garrett wrote:
> > >
> > > 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.
>
> 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).
>

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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] SHA-3 in SignatureScheme

[Hubert Kario]

On Friday, 2 September 2016 13:42:40 CEST Ilari Liusvaara wrote:
> On Fri, Sep 02, 2016 at 12:08:47PM +0200, Hubert Kario wrote:
> > On Thursday, 1 September 2016 19:22:18 CEST Dave Garrett wrote:
> > > 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.
> 
> Just tweaking the signatures is not enough. There is also the PRF hash,
> and using weak hash there has, umm... rather bad consequences.

SHA-3 ciphersuites added

-- 
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

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] SHA-3 in SignatureScheme

[Ilari Liusvaara]

On Fri, Sep 02, 2016 at 12:08:47PM +0200, Hubert Kario wrote:
> On Thursday, 1 September 2016 19:22:18 CEST Dave Garrett wrote:
> >
> > 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.

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] SHA-3 in SignatureScheme

[Dave Garrett]

On Thursday, September 01, 2016 02:30:54 pm Scott Fluhrer (sfluhrer) wrote:
> > On Thursday, 1 September 2016 12:43:31 CEST Benjamin Kaduk wrote:
> > > On 09/01/2016 12:38 PM, Hubert Kario wrote:
> > > > The SHA-3 standard is already published and accepted[1], shouldn't
> > > > TLSv1.3 include signatures with those hashes then?
> > >
> > > 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.
> 
> 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.


Dave

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] SHA-3 in SignatureScheme

[Hubert Kario]

On Thursday, 1 September 2016 12:43:31 CEST Benjamin Kaduk wrote:
> On 09/01/2016 12:38 PM, Hubert Kario wrote:
> > The SHA-3 standard is already published and accepted[1], shouldn't TLSv1.3
> > include signatures with those hashes then?
> 
> 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.

> >  1 - https://www.federalregister.gov/articles/2015/08/05/2015-19181/
> > 
> > announcing-approval-of-federal-information-processing-standard-fips-202-sh
> > a-3- standard
> 
> 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.

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...

-- 
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

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] SHA-3 in SignatureScheme

[Benjamin Kaduk]

On 09/01/2016 12:38 PM, Hubert Kario wrote:
> The SHA-3 standard is already published and accepted[1], shouldn't TLSv1.3 
> include signatures with those hashes then?

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

>  1 - https://www.federalregister.gov/articles/2015/08/05/2015-19181/
> announcing-approval-of-federal-information-processing-standard-fips-202-sha-3-
> standard
>

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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls