Re: [TLS] AD Review of draft-ietf-tls-tls13

[Viktor Dukhovni <[e-mail]>]

> On May 22, 2017, at 10:50 AM, Nico Williams <[e-mail]> wrote:
> 
>>> "When using TLS to authenticate the server, certificate signature
>>> algorithms weaker than <list of weakest acceptable signature algs here>
>>> MUST NOT be used."
>> 
>> Minor correction, perhaps you really mean to say "when using RFC5280 (PKIX)
>> to authenticate... (the [server or client?]).  TLS is just the transport
>> after all.
> 
> No, I meant what I said, as in "as opposed to using TLS
> opportunistically".

While we are quibbling over terminology and not substance:

Note that opportunistically != unauthenticated.  Opportunistic DANE TLS
still authenticates when the peer has TLSA records, and even uses PKIX
when the TLSA record certificate usage is DANE-TA(2).  And sufficiently
strong algorithms are desirable even under those conditions:

   https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_client.c#L955

So it seems the phrase "using TLS to authenticate" in fact means using
RFC5280 (PKIX) to authenticate the peer via its signature over its
Cerificate Verify message:

	https://tools.ietf.org/html/draft-ietf-tls-tls13-20#section-4.4.3

The phrase used to describe the situation in that section of the draft is
"when authenticating via a certificate", which is part of the story, what
would need to be added to that to get the right context for setting a floor
on acceptable certificate signature algorithms is something along the lines
of "with PKIX chain verification".

Still, all of this belongs in an update of RFC5280, but if we just can't
resist saying something here along the lines you suggest then it might be:

"When peer authentication is via a certificate, with RFC5280 (PKIX) chain
verification, certificate signature algorithms weaker than <list of weakest
acceptable signature algs here> MUST NOT be trusted."

I carefully say "MUST NOT be trusted" rather than "MUST NOT be used", it is
the relying party that decides what minimal algorithm strength is acceptable.
The peer may send whatever chain it has (lacking one that meets the advertised
supported signature algorithms).

Peers that desire broadly interoperable RFC5280 authentication via their
certificate chain should of course be configured to present chains that avoid
deprecated certificate signature algorithms (except in self-signatures of
trust-anchors).

-- 
	Viktor.