Re: [TLS] Consistency for Signature Algorithms?

[Blumenthal, Uri - 0553 - MITLL]

> To clarify, you are arguing that P-384 should also be listed as MTI?

no, I'm arguing either for dropping the curve from signature algorithms, or to
bind RSA key sizes to hashes too

 

 

   I don't think that either of these are good ideas.

 

+1

 

Both of these ideas are pretty bad, especially the first one.

 

Listing P-384 as MTI would be just fine, IMHO.

 



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

Re: [TLS] Consistency for Signature Algorithms?

[Eric Rescorla]

On Mon, Jul 24, 2017 at 10:15 AM, Hubert Kario  wrote:

> On Monday, 24 July 2017 15:09:48 CEST Benjamin Kaduk wrote:
> > On 07/24/2017 05:49 AM, Hubert Kario wrote:
> > > On Friday, 21 July 2017 21:37:42 CEST Benjamin Kaduk wrote:
> > >> I'm afraid I don't understand this remark. There is the caveat to
> which
> > >> Ilari alludes, that the server can send whatever chain it has, if the
> > >> server can't send a chain that complies with the client's
> > >> signature_algorithms.  Since certificate validation is assumed to be
> > >> largely a function of the PKI library and not really in scope for the
> > >> TLS spec itself, this is not particularly problematic.
> > >
> > > true; that disjoint between "stuff that TLS library is supposed to do"
> and
> > > "stuff that PKI library is supposed to do" could be spelled out more
> > > explicitly in the RFC though
> >
> > I pasted that into https://github.com/tlswg/tls13-spec/issues/1062 but I
> > don't have high hopes that it won't just get closed with no action.
> >
> > >> The other main
> > >> usage of the signature_algorithms limits what can be used in
> > >> CertificateVerify, which is directly relevant to TLS and depends on
> the
> > >> key attested to in the certificate.  Are you claiming that there are
> > >> servers that only possess certificates with p384 keys (i.e., no RSA or
> > >> p256 or other fallback cert)?
> > >
> > > Yes, there are servers that have P-384 keys. Not sure if they have a
> dual
> > > stack (but that is unlikely as only about 30% of servers with ECDSA
> certs
> > > have also RSA cert).
> >
> > To clarify, you are arguing that P-384 should also be listed as MTI?
>
> no, I'm arguing either for dropping the curve from signature algorithms,
> or to
> bind RSA key sizes to hashes too
>


I don't think that either of these are good ideas. It turns out that curves
and
signature algorithms just aren't orthogonal (and even less orthogonal than
hash algorithms) nbut RSA is qualitatively different.

-Ekr


> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 115, 612 00  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] Consistency for Signature Algorithms?

[Hubert Kario]

On Monday, 24 July 2017 15:09:48 CEST Benjamin Kaduk wrote:
> On 07/24/2017 05:49 AM, Hubert Kario wrote:
> > On Friday, 21 July 2017 21:37:42 CEST Benjamin Kaduk wrote:
> >> I'm afraid I don't understand this remark. There is the caveat to which
> >> Ilari alludes, that the server can send whatever chain it has, if the
> >> server can't send a chain that complies with the client's
> >> signature_algorithms.  Since certificate validation is assumed to be
> >> largely a function of the PKI library and not really in scope for the
> >> TLS spec itself, this is not particularly problematic.
> > 
> > true; that disjoint between "stuff that TLS library is supposed to do" and
> > "stuff that PKI library is supposed to do" could be spelled out more
> > explicitly in the RFC though
> 
> I pasted that into https://github.com/tlswg/tls13-spec/issues/1062 but I
> don't have high hopes that it won't just get closed with no action.
> 
> >> The other main
> >> usage of the signature_algorithms limits what can be used in
> >> CertificateVerify, which is directly relevant to TLS and depends on the
> >> key attested to in the certificate.  Are you claiming that there are
> >> servers that only possess certificates with p384 keys (i.e., no RSA or
> >> p256 or other fallback cert)?
> > 
> > Yes, there are servers that have P-384 keys. Not sure if they have a dual
> > stack (but that is unlikely as only about 30% of servers with ECDSA certs
> > have also RSA cert).
> 
> To clarify, you are arguing that P-384 should also be listed as MTI?

no, I'm arguing either for dropping the curve from signature algorithms, or to 
bind RSA key sizes to hashes too

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  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] Consistency for Signature Algorithms?

[Viktor Dukhovni]

On Fri, Jul 21, 2017 at 02:37:42PM -0500, Benjamin Kaduk wrote:

> I'm afraid I don't understand this remark.  There is the caveat to which
> Ilari alludes, that the server can send whatever chain it has, if the
> server can't send a chain that complies with the client's
> signature_algorithms.

"Send whatever it has" is the expected behaviour in the vast majority
of cases, i.e., for servers with just one certificate chain.  I sure
hope that server implementation that abort instead of sending some
chain will be rare.

It is indeed a nuisance that even with curves for key agreement
split off into the separate "groups" extension, the "signature
algorithms" extension is still overloaded to serve two rather
different purposes:

1.  Negotiate algorithms suitable for signing TLS handshake
messages.

2.  Signal support for X.509 signature algorithms.

Using the same extension for both was perhaps a mistake.  As pointed
out in this thread,  X.509 admits more combinations for "2" than
TLS 1.3 does for "1".  Consequently TLS 1.3 servers with multiple
chains to choose from might employ suboptimal algorithms in order
to match the client's supported signature algorithm extension, even
though a better choice is available, but was not or cannot be
signalled by the client.

-- 
Viktor.

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

Re: [TLS] Consistency for Signature Algorithms?

[Benjamin Kaduk]

On 07/24/2017 05:49 AM, Hubert Kario wrote:
> On Friday, 21 July 2017 21:37:42 CEST Benjamin Kaduk wrote:
>> I'm afraid I don't understand this remark. There is the caveat to which
>> Ilari alludes, that the server can send whatever chain it has, if the
>> server can't send a chain that complies with the client's
>> signature_algorithms.  Since certificate validation is assumed to be
>> largely a function of the PKI library and not really in scope for the
>> TLS spec itself, this is not particularly problematic.  
> true; that disjoint between "stuff that TLS library is supposed to do" and 
> "stuff that PKI library is supposed to do" could be spelled out more 
> explicitly in the RFC though

I pasted that into https://github.com/tlswg/tls13-spec/issues/1062 but I
don't have high hopes that it won't just get closed with no action.

>> The other main
>> usage of the signature_algorithms limits what can be used in
>> CertificateVerify, which is directly relevant to TLS and depends on the
>> key attested to in the certificate.  Are you claiming that there are
>> servers that only possess certificates with p384 keys (i.e., no RSA or
>> p256 or other fallback cert)?
> Yes, there are servers that have P-384 keys. Not sure if they have a dual 
> stack (but that is unlikely as only about 30% of servers with ECDSA certs 
> have 
> also RSA cert).

To clarify, you are arguing that P-384 should also be listed as MTI?

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

Re: [TLS] Consistency for Signature Algorithms?

[Hubert Kario]

On Friday, 21 July 2017 21:37:42 CEST Benjamin Kaduk wrote:
> On 07/21/2017 09:34 AM, Hubert Kario wrote:
> > On Friday, 21 July 2017 15:38:32 CEST Benjamin Kaduk wrote:
> >> On 07/21/2017 08:23 AM, Hubert Kario wrote:
> >>> Signature Algorithms for ECDSA now define both the curve and the hash
> >>> 
> >>> algorithm:
> >>>   ecdsa_secp256r1_sha256(0x0403),
> >>>   ecdsa_secp384r1_sha384(0x0503),
> >>>   ecdsa_secp521r1_sha512(0x0603),
> >>> 
> >>> This is in contrast to the TLS 1.2 protocol, where any hash can be used
> >>> with any curve.
> >> 
> >> I assume you saw
> >> https://www.ietf.org/mail-archive/web/tls/current/msg23714.html which
> >> raised a different question in this same general area.
> >> 
> >> I do not see how the response here cannot be the same as it was there:
> >> namely, that the current formulation is assumed to have WG consensus,
> >> having been through two WGLCs; there would need to be rather strong
> >> reasons to make changes at this stage.
> > 
> > MTI (section 9.1) says only that ecdsa_secp256r1_sha256 is mandatory
> > (MUST)
> > and no word about any of the other two.
> > 
> > given that we already have CAs that use P-384 for signatures. I'd say this
> > is a big conflict between theory and practice.
> 
> I'm afraid I don't understand this remark.  There is the caveat to which
> Ilari alludes, that the server can send whatever chain it has, if the
> server can't send a chain that complies with the client's
> signature_algorithms.  Since certificate validation is assumed to be
> largely a function of the PKI library and not really in scope for the
> TLS spec itself, this is not particularly problematic.  

true; that disjoint between "stuff that TLS library is supposed to do" and 
"stuff that PKI library is supposed to do" could be spelled out more 
explicitly in the RFC though

> The other main
> usage of the signature_algorithms limits what can be used in
> CertificateVerify, which is directly relevant to TLS and depends on the
> key attested to in the certificate.  Are you claiming that there are
> servers that only possess certificates with p384 keys (i.e., no RSA or
> p256 or other fallback cert)?

Yes, there are servers that have P-384 keys. Not sure if they have a dual 
stack (but that is unlikely as only about 30% of servers with ECDSA certs have 
also RSA cert).


On Friday, 21 July 2017 17:00:55 CEST Ilari Liusvaara wrote:
> Actually, P-256+SHA512 is allowed with a caveat, even if the
> certificate is not self-signed. And with the same caveat, server can
> send a certificate signed with P-256+SHA3-512, despite TLS
> codepoint for it having never existed (not many clients can validate it
> through).

the reverse is true too - if your TLS library supports some combinations, the 
PKIX library MUST support them
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  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] Consistency for Signature Algorithms?

[Dr Stephen Henson]

On 21/07/2017 16:00, Ilari Liusvaara wrote:
> 
> I suppose some new dual-version TLS 1.2/1.3 libraries might have the
> same issue as mine: supported groups is just plain ignored for ECDSA,
> and siganture algorithms have the TLS 1.3 meanings, even in TLS 1.2.
> 

That is potentially a problem yes.

Suppose a server has an EE certificate with a P-256 public key and the client
preference order is ecdsa_secp384r1_sha384, ecdsa_secp256r1_sha256. For TLS 1.3
it will use ecdsa_secp256r1_sha256 and sign TLS messages using P-256+SHA256.

In TLS 1.2 the same preference list means sha384+ecdsa, sha256+ecdsa without the
curve restriction. In this case the server might sign the message using
P-256+SHA384 because the client prefers it. That isn't allowed in TLS 1.3 but is
in TLS 1.2. A client which enforces the TLS 1.3 signature algorithm rules for
TLS 1.2 might abort the connection at that point.

>> I agree though that there is an anomaly here. For example AFAICS in
>> certificates for TLS1.3 you're allowed (with some caveats) to use a
>> P-256+SHA-1 signature (which has security concerns) but P-256 + SHA512 is not
>> allowed at all. Is that likely to be a problem in practice? Are there many
>> such certificates about in the wild?
> 
> Actually, P-256+SHA512 is allowed with a caveat, even if the
> certificate is not self-signed. And with the same caveat, server can
> send a certificate signed with P-256+SHA3-512, despite TLS
> codepoint for it having never existed (not many clients can validate it
> through).
> 

Yes you're right, the caveat of not otherwise having any suitable chain allows
that case.

Steve.
-- 
Dr Stephen N. Henson.
Founder member of the OpenSSL project: http://www.openssl.org/

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

Re: [TLS] Consistency for Signature Algorithms?

[Dr Stephen Henson]

-- 
Dr Stephen N. Henson.
Founder member of the OpenSSL project: http://www.openssl.org/
On 21/07/2017 20:45, Dr Benjamin Kaduk wrote:
> On 07/21/2017 08:41 AM, Dr Stephen Henson wrote:
>> On 21/07/2017 14:23, Hubert Kario wrote:
>>> Signature Algorithms for ECDSA now define both the curve and the hash 
>>> algorithm:
>>>
>>> ecdsa_secp256r1_sha256(0x0403), ecdsa_secp384r1_sha384(0x0503), 
>>> ecdsa_secp521r1_sha512(0x0603),
>>>
>>> This is in contrast to the TLS 1.2 protocol, where any hash can be used
>>> with any curve.
>>>
>>> There are good reasons for that change: - less combinations to test -
>>> establishes the low water mart for security
>>>
>>> I see few problems with that though: 1). there are not insignificant number
>>> of clients that advertise support for all (at least P-256 and P-384)
>>> curves, but don't advertise support for hashes stronger than SHA-256 with
>>> ECDSA[1] 2). This is inconsistent with RSA-PSS behaviour, where key size is
>>> completely detached from the used hash algorithm. 3). This is not how ECDSA
>>> signatures in X.509 work, so it doesn't actually limit the signatures on
>>> certificates (in other words, as an implementer you need to support all
>>> hashes with all curves either way)
>>>
>> There is another and significant problem with the change. In TLS 1.2 support
>> for a curve was indicated in the supported curves extension and it implied
>> support for ECDH and ECDSA. This has changed in TLS 1.3: curves in the
>> supported groups extension are for ECDH only. Support for a curve for ECDSA 
>> is
>> indicated in the signature algorithms extension.
> 
> Could you say a bit more about why you believe this to be a problem?  On the
> face of it, it seems that the previous state overloaded a single field to mean
> multiple only semi-related things, whereas the new formulation keeps things 
> more
> orthogonal and easier to implement in a modular way.  That is, groups are for
> key exchange, and signature algorithms are for signing, and there is no muddy
> overlap between them.
> 

I didn't mean there was a problem with the current spec, I meant there was a
problem with the proposed change: i.e. to remove the curve requirement from
signature algorithms.

Steve.
-- 
Dr Stephen N. Henson.
Founder member of the OpenSSL project: http://www.openssl.org/

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

Re: [TLS] Consistency for Signature Algorithms?

[Dr Benjamin Kaduk]

On 07/21/2017 08:41 AM, Dr Stephen Henson wrote:
> On 21/07/2017 14:23, Hubert Kario wrote:
>> Signature Algorithms for ECDSA now define both the curve and the hash 
>> algorithm:
>>
>> ecdsa_secp256r1_sha256(0x0403), ecdsa_secp384r1_sha384(0x0503), 
>> ecdsa_secp521r1_sha512(0x0603),
>>
>> This is in contrast to the TLS 1.2 protocol, where any hash can be used
>> with any curve.
>>
>> There are good reasons for that change: - less combinations to test -
>> establishes the low water mart for security
>>
>> I see few problems with that though: 1). there are not insignificant number
>> of clients that advertise support for all (at least P-256 and P-384)
>> curves, but don't advertise support for hashes stronger than SHA-256 with
>> ECDSA[1] 2). This is inconsistent with RSA-PSS behaviour, where key size is
>> completely detached from the used hash algorithm. 3). This is not how ECDSA
>> signatures in X.509 work, so it doesn't actually limit the signatures on
>> certificates (in other words, as an implementer you need to support all
>> hashes with all curves either way)
>>
> There is another and significant problem with the change. In TLS 1.2 support
> for a curve was indicated in the supported curves extension and it implied
> support for ECDH and ECDSA. This has changed in TLS 1.3: curves in the
> supported groups extension are for ECDH only. Support for a curve for ECDSA is
> indicated in the signature algorithms extension.

Could you say a bit more about why you believe this to be a problem?  On
the face of it, it seems that the previous state overloaded a single
field to mean multiple only semi-related things, whereas the new
formulation keeps things more orthogonal and easier to implement in a
modular way.  That is, groups are for key exchange, and signature
algorithms are for signing, and there is no muddy overlap between them.

Thanks,

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

Re: [TLS] Consistency for Signature Algorithms?

[Benjamin Kaduk]

On 07/21/2017 09:34 AM, Hubert Kario wrote:
> On Friday, 21 July 2017 15:38:32 CEST Benjamin Kaduk wrote:
>> On 07/21/2017 08:23 AM, Hubert Kario wrote:
>>> Signature Algorithms for ECDSA now define both the curve and the hash
>>>
>>> algorithm:
>>>   ecdsa_secp256r1_sha256(0x0403),
>>>   ecdsa_secp384r1_sha384(0x0503),
>>>   ecdsa_secp521r1_sha512(0x0603),
>>>
>>> This is in contrast to the TLS 1.2 protocol, where any hash can be used
>>> with any curve.
>> I assume you saw
>> https://www.ietf.org/mail-archive/web/tls/current/msg23714.html which
>> raised a different question in this same general area.
>>
>> I do not see how the response here cannot be the same as it was there:
>> namely, that the current formulation is assumed to have WG consensus,
>> having been through two WGLCs; there would need to be rather strong
>> reasons to make changes at this stage.
> MTI (section 9.1) says only that ecdsa_secp256r1_sha256 is mandatory (MUST) 
> and no word about any of the other two.
>
> given that we already have CAs that use P-384 for signatures. I'd say this is 
> a big conflict between theory and practice.
>

I'm afraid I don't understand this remark.  There is the caveat to which
Ilari alludes, that the server can send whatever chain it has, if the
server can't send a chain that complies with the client's
signature_algorithms.  Since certificate validation is assumed to be
largely a function of the PKI library and not really in scope for the
TLS spec itself, this is not particularly problematic.  The other main
usage of the signature_algorithms limits what can be used in
CertificateVerify, which is directly relevant to TLS and depends on the
key attested to in the certificate.  Are you claiming that there are
servers that only possess certificates with p384 keys (i.e., no RSA or
p256 or other fallback cert)?

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

Re: [TLS] Consistency for Signature Algorithms?

[Watson Ladd]

On Fri, Jul 21, 2017 at 8:00 AM, Ilari Liusvaara 
wrote:

> On Fri, Jul 21, 2017 at 02:41:50PM +0100, Dr Stephen Henson wrote:
> > On 21/07/2017 14:23, Hubert Kario wrote:
> > > Signature Algorithms for ECDSA now define both the curve and the hash
> > > algorithm:
> > >
> > > ecdsa_secp256r1_sha256(0x0403), ecdsa_secp384r1_sha384(0x0503),
> > > ecdsa_secp521r1_sha512(0x0603),
> > >
> > > This is in contrast to the TLS 1.2 protocol, where any hash can be used
> > > with any curve.
> > >
> > > There are good reasons for that change: - less combinations to test -
> > > establishes the low water mart for security
> > >
> > > I see few problems with that though: 1). there are not insignificant
> number
> > > of clients that advertise support for all (at least P-256 and P-384)
> > > curves, but don't advertise support for hashes stronger than SHA-256
> with
> > > ECDSA[1] 2). This is inconsistent with RSA-PSS behaviour, where key
> size is
> > > completely detached from the used hash algorithm. 3). This is not how
> ECDSA
> > > signatures in X.509 work, so it doesn't actually limit the signatures
> on
> > > certificates (in other words, as an implementer you need to support all
> > > hashes with all curves either way)
> > >
> >
> > There is another and significant problem with the change. In TLS 1.2
> support
> > for a curve was indicated in the supported curves extension and it
> implied
> > support for ECDH and ECDSA. This has changed in TLS 1.3: curves in the
> > supported groups extension are for ECDH only. Support for a curve for
> ECDSA is
> > indicated in the signature algorithms extension.
>
> I suppose some new dual-version TLS 1.2/1.3 libraries might have the
> same issue as mine: supported groups is just plain ignored for ECDSA,
> and siganture algorithms have the TLS 1.3 meanings, even in TLS 1.2.
>
> > I agree though that there is an anomaly here. For example AFAICS in
> > certificates for TLS1.3 you're allowed (with some caveats) to use a
> > P-256+SHA-1 signature (which has security concerns) but P-256 + SHA512
> is not
> > allowed at all. Is that likely to be a problem in practice? Are there
> many
> > such certificates about in the wild?
>
> Actually, P-256+SHA512 is allowed with a caveat, even if the
> certificate is not self-signed. And with the same caveat, server can
> send a certificate signed with P-256+SHA3-512, despite TLS
> codepoint for it having never existed (not many clients can validate it
> through).
>

But this doesn't affect security if i understand the model correctly.

>
>
>
>
> -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] Consistency for Signature Algorithms?

[Ilari Liusvaara]

On Fri, Jul 21, 2017 at 02:41:50PM +0100, Dr Stephen Henson wrote:
> On 21/07/2017 14:23, Hubert Kario wrote:
> > Signature Algorithms for ECDSA now define both the curve and the hash 
> > algorithm:
> > 
> > ecdsa_secp256r1_sha256(0x0403), ecdsa_secp384r1_sha384(0x0503), 
> > ecdsa_secp521r1_sha512(0x0603),
> > 
> > This is in contrast to the TLS 1.2 protocol, where any hash can be used
> > with any curve.
> > 
> > There are good reasons for that change: - less combinations to test -
> > establishes the low water mart for security
> > 
> > I see few problems with that though: 1). there are not insignificant number
> > of clients that advertise support for all (at least P-256 and P-384)
> > curves, but don't advertise support for hashes stronger than SHA-256 with
> > ECDSA[1] 2). This is inconsistent with RSA-PSS behaviour, where key size is
> > completely detached from the used hash algorithm. 3). This is not how ECDSA
> > signatures in X.509 work, so it doesn't actually limit the signatures on
> > certificates (in other words, as an implementer you need to support all
> > hashes with all curves either way)
> > 
> 
> There is another and significant problem with the change. In TLS 1.2 support
> for a curve was indicated in the supported curves extension and it implied
> support for ECDH and ECDSA. This has changed in TLS 1.3: curves in the
> supported groups extension are for ECDH only. Support for a curve for ECDSA is
> indicated in the signature algorithms extension.

I suppose some new dual-version TLS 1.2/1.3 libraries might have the
same issue as mine: supported groups is just plain ignored for ECDSA,
and siganture algorithms have the TLS 1.3 meanings, even in TLS 1.2.

> I agree though that there is an anomaly here. For example AFAICS in
> certificates for TLS1.3 you're allowed (with some caveats) to use a
> P-256+SHA-1 signature (which has security concerns) but P-256 + SHA512 is not
> allowed at all. Is that likely to be a problem in practice? Are there many
> such certificates about in the wild?

Actually, P-256+SHA512 is allowed with a caveat, even if the
certificate is not self-signed. And with the same caveat, server can
send a certificate signed with P-256+SHA3-512, despite TLS
codepoint for it having never existed (not many clients can validate it
through).




-Ilari





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

Re: [TLS] Consistency for Signature Algorithms?

[Hubert Kario]

On Friday, 21 July 2017 15:38:32 CEST Benjamin Kaduk wrote:
> On 07/21/2017 08:23 AM, Hubert Kario wrote:
> > Signature Algorithms for ECDSA now define both the curve and the hash
> > 
> > algorithm:
> >   ecdsa_secp256r1_sha256(0x0403),
> >   ecdsa_secp384r1_sha384(0x0503),
> >   ecdsa_secp521r1_sha512(0x0603),
> > 
> > This is in contrast to the TLS 1.2 protocol, where any hash can be used
> > with any curve.
> 
> I assume you saw
> https://www.ietf.org/mail-archive/web/tls/current/msg23714.html which
> raised a different question in this same general area.
> 
> I do not see how the response here cannot be the same as it was there:
> namely, that the current formulation is assumed to have WG consensus,
> having been through two WGLCs; there would need to be rather strong
> reasons to make changes at this stage.

MTI (section 9.1) says only that ecdsa_secp256r1_sha256 is mandatory (MUST) 
and no word about any of the other two.

given that we already have CAs that use P-384 for signatures. I'd say this is 
a big conflict between theory and practice.

> > There are good reasons for that change:
> >  - less combinations to test
> >  - establishes the low water mart for security
> > 
> > I see few problems with that though:
> >  1). there are not insignificant number of clients that advertise support
> >  for>  
> >   all (at least P-256 and P-384) curves, but don't advertise support
> >   for
> >   hashes stronger than SHA-256 with ECDSA[1]
> >  
> >  2). This is inconsistent with RSA-PSS behaviour, where key size is
> >  completely>  
> >   detached from the used hash algorithm.
> >  
> >  3). This is not how ECDSA signatures in X.509 work, so it doesn't
> >  actually
> >  
> >   limit the signatures on certificates (in other words, as an
> >   implementer
> >   you need to support all hashes with all curves either way)
> > 
> > With the implementers hat on, I'd prefer to drop the curves from signature
> > algorithm names/specifications and return to TLS 1.2 behaviour.
> > With my security hat on, I'd say that we should set the minimal key sizes
> > for RSA-PSS signatures too, as we did with ECDSA.
> > 
> > Any other ideas?
> > 
> >  1 - Nick Sullivan from Cloudflare provided me with some stats from random
> > 
> > 5 client hellos from early 2017:
> > 
> > Sigalgs:
> > ECDSA + SHA-256 = 39104 (78.2%)
> > ECDSA + (SHA-256 + SHA-384 + SHA-512) = 28678 (57.4%)
> > ECDSA + (SHA-256 + SHA-384 + !SHA-512) = 8934 (17.9%)
> > ECDSA + (SHA-256 + !SHA-384 + !SHA-512) = 1492 (2.98%)
> > 
> > Note: many of the 1492 seem to be on iOS and only support:
> > [RSA-SHA-384, RSA-SHA-256, RSA-SHA1, ECDSA-SHA256, ECDSA-SHA1]
> > 
> > Curves:
> > none = 757 (1.51%)
> > P-256 = 49243 (98.5%)
> > P-384 = 49233 (98.5%)
> > P-256 + P-384 = 49233 (98.5%)
> > P-256 + !P-384 = 10 (0.02%)
> > !P-256 + P-384 = 0 (0%)
> > 
> > 
> > ___
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls


-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  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] Consistency for Signature Algorithms?

[Dr Stephen Henson]

On 21/07/2017 14:23, Hubert Kario wrote:
> Signature Algorithms for ECDSA now define both the curve and the hash 
> algorithm:
> 
> ecdsa_secp256r1_sha256(0x0403), ecdsa_secp384r1_sha384(0x0503), 
> ecdsa_secp521r1_sha512(0x0603),
> 
> This is in contrast to the TLS 1.2 protocol, where any hash can be used
> with any curve.
> 
> There are good reasons for that change: - less combinations to test -
> establishes the low water mart for security
> 
> I see few problems with that though: 1). there are not insignificant number
> of clients that advertise support for all (at least P-256 and P-384)
> curves, but don't advertise support for hashes stronger than SHA-256 with
> ECDSA[1] 2). This is inconsistent with RSA-PSS behaviour, where key size is
> completely detached from the used hash algorithm. 3). This is not how ECDSA
> signatures in X.509 work, so it doesn't actually limit the signatures on
> certificates (in other words, as an implementer you need to support all
> hashes with all curves either way)
> 

There is another and significant problem with the change. In TLS 1.2 support
for a curve was indicated in the supported curves extension and it implied
support for ECDH and ECDSA. This has changed in TLS 1.3: curves in the
supported groups extension are for ECDH only. Support for a curve for ECDSA is
indicated in the signature algorithms extension.

I agree though that there is an anomaly here. For example AFAICS in
certificates for TLS1.3 you're allowed (with some caveats) to use a
P-256+SHA-1 signature (which has security concerns) but P-256 + SHA512 is not
allowed at all. Is that likely to be a problem in practice? Are there many
such certificates about in the wild?

Steve.
-- 
Dr Stephen N. Henson.
Founder member of the OpenSSL project: http://www.openssl.org/

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

Re: [TLS] Consistency for Signature Algorithms?

[Benjamin Kaduk]

On 07/21/2017 08:23 AM, Hubert Kario wrote:
> Signature Algorithms for ECDSA now define both the curve and the hash 
> algorithm:
>
>   ecdsa_secp256r1_sha256(0x0403),
>   ecdsa_secp384r1_sha384(0x0503),
>   ecdsa_secp521r1_sha512(0x0603),
>
> This is in contrast to the TLS 1.2 protocol, where any hash can be used with 
> any curve.

I assume you saw
https://www.ietf.org/mail-archive/web/tls/current/msg23714.html which
raised a different question in this same general area.

I do not see how the response here cannot be the same as it was there:
namely, that the current formulation is assumed to have WG consensus,
having been through two WGLCs; there would need to be rather strong
reasons to make changes at this stage.

-Ben


> There are good reasons for that change:
>  - less combinations to test
>  - establishes the low water mart for security
>
> I see few problems with that though:
>  1). there are not insignificant number of clients that advertise support for 
>   all (at least P-256 and P-384) curves, but don't advertise support for 
>   hashes stronger than SHA-256 with ECDSA[1] 
>  2). This is inconsistent with RSA-PSS behaviour, where key size is completely
>   detached from the used hash algorithm.
>  3). This is not how ECDSA signatures in X.509 work, so it doesn't actually 
>   limit the signatures on certificates (in other words, as an implementer
>   you need to support all hashes with all curves either way)
>
> With the implementers hat on, I'd prefer to drop the curves from signature 
> algorithm names/specifications and return to TLS 1.2 behaviour.
> With my security hat on, I'd say that we should set the minimal key sizes for 
> RSA-PSS signatures too, as we did with ECDSA.
>
> Any other ideas?
>
>
>  1 - Nick Sullivan from Cloudflare provided me with some stats from random 
> 5 client hellos from early 2017:
>
> Sigalgs:
> ECDSA + SHA-256 = 39104 (78.2%)
> ECDSA + (SHA-256 + SHA-384 + SHA-512) = 28678 (57.4%)
> ECDSA + (SHA-256 + SHA-384 + !SHA-512) = 8934 (17.9%)
> ECDSA + (SHA-256 + !SHA-384 + !SHA-512) = 1492 (2.98%)
>
> Note: many of the 1492 seem to be on iOS and only support:
> [RSA-SHA-384, RSA-SHA-256, RSA-SHA1, ECDSA-SHA256, ECDSA-SHA1]
>
> Curves:
> none = 757 (1.51%)
> P-256 = 49243 (98.5%)
> P-384 = 49233 (98.5%)
> P-256 + P-384 = 49233 (98.5%)
> P-256 + !P-384 = 10 (0.02%)
> !P-256 + P-384 = 0 (0%)
>
>
> ___
> 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

[TLS] Consistency for Signature Algorithms?

[Hubert Kario]

Signature Algorithms for ECDSA now define both the curve and the hash 
algorithm:

  ecdsa_secp256r1_sha256(0x0403),
  ecdsa_secp384r1_sha384(0x0503),
  ecdsa_secp521r1_sha512(0x0603),

This is in contrast to the TLS 1.2 protocol, where any hash can be used with 
any curve.

There are good reasons for that change:
 - less combinations to test
 - establishes the low water mart for security

I see few problems with that though:
 1). there are not insignificant number of clients that advertise support for 
  all (at least P-256 and P-384) curves, but don't advertise support for 
  hashes stronger than SHA-256 with ECDSA[1] 
 2). This is inconsistent with RSA-PSS behaviour, where key size is completely
  detached from the used hash algorithm.
 3). This is not how ECDSA signatures in X.509 work, so it doesn't actually 
  limit the signatures on certificates (in other words, as an implementer
  you need to support all hashes with all curves either way)

With the implementers hat on, I'd prefer to drop the curves from signature 
algorithm names/specifications and return to TLS 1.2 behaviour.
With my security hat on, I'd say that we should set the minimal key sizes for 
RSA-PSS signatures too, as we did with ECDSA.

Any other ideas?


 1 - Nick Sullivan from Cloudflare provided me with some stats from random 
5 client hellos from early 2017:

Sigalgs:
ECDSA + SHA-256 = 39104 (78.2%)
ECDSA + (SHA-256 + SHA-384 + SHA-512) = 28678 (57.4%)
ECDSA + (SHA-256 + SHA-384 + !SHA-512) = 8934 (17.9%)
ECDSA + (SHA-256 + !SHA-384 + !SHA-512) = 1492 (2.98%)

Note: many of the 1492 seem to be on iOS and only support:
[RSA-SHA-384, RSA-SHA-256, RSA-SHA1, ECDSA-SHA256, ECDSA-SHA1]

Curves:
none = 757 (1.51%)
P-256 = 49243 (98.5%)
P-384 = 49233 (98.5%)
P-256 + P-384 = 49233 (98.5%)
P-256 + !P-384 = 10 (0.02%)
!P-256 + P-384 = 0 (0%)
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  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