Re: [TLS] Consistency for Signature Algorithms?

[Hubert Kario <[e-mail]>]

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