Re: [TLS] Consistency for Signature Algorithms?

On Fri, Jul 21, 2017 at 8:00 AM, Ilari Liusvaara <ilariliusvaara@welho.com>
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
>