Subject: [TLS] Draft 18 certificate signature algorithm requirements

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 1 Dec 2016 02:50:25 +0000

We've discussed this before, and the current state of the text is
certainly much improved.  I'd like to touch on one final point.

The current text reads:

   Section 4.4.1.2 ( https://tools.ietf.org/html/draft-ietf-tls-tls13-18#page-56 )

   All certificates provided by the server MUST be signed by a signature
   algorithm that appears in the "signature_algorithms" extension
   provided by the client, if they are able to provide such a chain (see
   Section 4.2.3).  Certificates that are self-signed or certificates
   that are expected to be trust anchors are not validated as part of
   the chain and therefore MAY be signed with any algorithm.

   If the server cannot produce a certificate chain that is signed only
   via the indicated supported algorithms, then it SHOULD continue the
   handshake by sending the client a certificate chain of its choice
   that may include algorithms that are not known to be supported by the
   client.  This fallback chain MAY use the deprecated SHA-1 hash
   algorithm only if the "signature_algorithms" extension provided by
   the client permits it.  If the client cannot construct an acceptable
   chain using the provided certificates and decides to abort the
   handshake, then it MUST abort the handshake with an
   "unsupported_certificate" alert.

The first and second paragraph are in conflict, unless the first
paragraph's MUST is changed to a SHOULD, or a "MUST if at all
possible", ...  That is it fine to require the server to send a
compatible rather than an incompatible certificate when it has at
least one of each, but if the only choice is to fail, the second
paragraph says that the server "SHOULD" send what it has, thus
the first is not really a MUST as written.

The only compromise in the direction of the first paragraph made
in the second is that certificates (not self) signed with SHA1 MUST
not be sent if the client did not offer to support it, even if
that's the only certificate it has, and even if that SHA1 signature
will never be used by the client (e.g. with a DANE-EE(3) TLSA record
authenticating the server directly).

The onus is correctly placed on the client (not on the server) to
abort the connection, if the client's security requirements are not
met by the server's certificate chain.

So I'd like to see the text in the first paragraph changed to a
SHOULD or worst-case a qualified "MUST whenever possible".

I should also note that the second part of the first paragraph,
which says:

                    Certificates that are self-signed or certificates
   that are expected to be trust anchors are not validated as part of
   the chain and therefore MAY be signed with any algorithm.

assumes that the server knows which of its certificates are trust
anchors, but this is not something that the server can in general
definitely know.  All kinds of clients may use all kinds of methods
to validate the server chain.

So I think there is a final opportunity to polish the text by making
it clear that the server SHOULD (whenever possible) send a certificate
chain that the client is likely to be able to process, but otherwise
proceed to the text in the second paragraph, which says (correctly)
that it SHOULD otherwise send what it has, which may indeed prove
sufficient to the client despite the apparent signature algorithm
mismatch.

On a related note, is there in the current draft anything that
requires ECDSA certificates to bear ECDSA issuer signatures? Or
has that finally been relaxed, allowing the transmission of EE
ECDSA certs bearing RSA signatures (ideally the client also signals
support for RSA signatures)?  This would lift the restriction
imposed by:

   https://tools.ietf.org/search/rfc4492#section-2.2

   In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA-
   capable public key and be signed with ECDSA.

My impression is that the text in the last paragraph of 4.4.1.4:
 
   https://tools.ietf.org/html/draft-ietf-tls-tls13-18#section-4.4.1.4

   Note that a certificate containing a key for one signature algorithm
   MAY be signed using a different signature algorithm (for instance, an
   RSA key signed with an ECDSA key).

seems to have the desired effect.  Is that correct?  If so, should
the change from 4492 be stated more emphatically, making it clear
that the older restriction no longer applies?

-- 
	Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 30 Nov 2016 22:51:00 -0500

> the first is not really a MUST as written.

It's "MUST if... ". That's different from SHOULD unless because it
means that the unless clause is that only reason for violating it, and then
if that condition obtains it SHOULD do X but could presumably do
other things.

> SHOULD or worst-case a qualified "MUST whenever possible".

I don't see any difference between "MUST whenever possible"
and the current language.

> requires ECDSA certificates to bear ECDSA issuer signatures?

No. Nor has that been true since TLS 1.2. See:
https://tools.ietf.org/search/rfc5246#section-7.4.2

   If the client provided a "signature_algorithms" extension, then all
   certificates provided by the server MUST be signed by a
   hash/signature algorithm pair that appears in that extension.  Note
   that this implies that a certificate containing a key for one
   signature algorithm MAY be signed using a different signature
   algorithm (for instance, an RSA key signed with a DSA key).  This is
   a departure from TLS 1.1, which required that the algorithms be the
   same.  Note that this also implies that the DH_DSS, DH_RSA,
   ECDH_ECDSA, and ECDH_RSA key exchange algorithms do not restrict the
   algorithm used to sign the certificate.  Fixed DH certificates MAY be
   signed with any hash/signature algorithm pair appearing in the
   extension.  The names DH_DSS, DH_RSA, ECDH_ECDSA, and ECDH_RSA are
   historical.

> Or

Given that ECDHE_ECDSA is not even a concept in TLS 1.3, I don't see
that this text is relevant.

-Ekr

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 30 Nov 2016 23:32:26 -0500

> On Nov 30, 2016, at 10:51 PM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Wed, Nov 30, 2016 at 9:50 PM, Viktor Dukhovni <[email-masked]> wrote:
> 
> The current text reads:
> 
> [...]

Yes, I see.  The stretch of text between the "MUST" and the "if" just happened
to overflow my stack limit when I was rereading this today...  Please pardon
the short attention span.  So all is well, unless there is merit it trying
to word-smith the text to bring the "MUST" and "if" closer together....

The good new is that the intent is already just right.

> and the current language.

Yes, fair enough...

> https://tools.ietf.org/search/rfc5246#section-7.4.2

Great.  Thanks.

-- 
	Viktor.

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 1 Dec 2016 04:36:17 +0000

Viktor Dukhovni <[email-masked]> writes:

>So I'd like to see the text in the first paragraph changed to a SHOULD or 
>worst-case a qualified "MUST whenever possible".

Why is that whole thing even there in the first place?  From the previous 
discussions where this came up, the pretty much universal consensus was that 
people were ignoring the requirement because it served no obvious purpose 
but broke interoperability.  Unless you're a server operator that chooses to 
buy a whole bunch of $995 certs, one per algorithm, from a CA that allows 
you to choose which algorithm gets used for signing, the whole thing is 
completely inapplicable.  You send whatever cert chain the CA gave you to 
the client, and it's up to them to decide whether they want to accept or 
reject.  What would be lost by simply removing that entire block of text, 
since it's being ignored by implementers anyway?  The solution is to remove
it, not to fiddle with it until it becomes a no-op that matches what 
everyone is doing anyway.

(This seems to be getting like PKIX where a mistake is never actually 
corrected, just watered down again and again over successive iterations of a 
spec until it's finally quietly dropped when no-one is looking).

Peter.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 30 Nov 2016 23:49:26 -0500

> On Nov 30, 2016, at 11:36 PM, Peter Gutmann <[email-masked]> wrote:
> 

I would agree, if indeed everyone were ignoring this.  Sadly, that's not
the case.  In particular try to send to use a CAcert-issued client cert
to send email with STARTTLS to outlook.com...

So I wanted to see explicit text saying that the server SHOULD send what
it has.  Some folks here probably still think you and I (and perhaps ekr)
are wrong, and that the server should drop the connection...  This is not
an invitation to reopen that wound.

-- 
	Viktor.