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

From: Sankalp Bagaria <[email-masked]>
Date: Fri, 19 May 2017 15:04:49 +0530

Hi,

I would like to mention that TLS can be used with non-X.509 certificates
also.
In particular, it can be used with ITS ETSI and IEEE certificates.
https://datatracker.ietf.org/doc/html/draft-serhrouchni-tls-certieee1609

So, in my opinion, TLS should be very loosely or not at all coupled with
RFC 5280.

Thanks and Regards,
Sankalp Bagaria.

> On Tue, May 16, 2017 at 11:31 AM, Russ Housley <[email-masked]>
> wrote:
> >
> > On May 16, 2017, at 11:23 AM, Eric Rescorla <[email-masked]> wrote:
> >
> >
> >
> > On Tue, May 16, 2017 at 8:17 AM, Russ Housley <[email-masked]>
> wrote:
> >>
> >>
> >> On May 15, 2017, at 7:01 PM, Eric Rescorla <[email-masked]> wrote:
> >>
> >>
> >>
> >> On Mon, May 15, 2017 at 12:38 PM, Russ Housley <[email-masked]>
> >> wrote:
> >>>
> >>> Just commenting on Section 4.2 ?
> >>>
> >>> >
> >>> > > 3. Section 4.2.
> >>> > >
> >>> > >    "In general, detailed certificate validation procedures are out
> of
> >>> > >    scope for TLS (see [RFC5280]).  This section provides
> TLS-specific
> >>> > >    requirements."
> >>> > >
> >>> > > I don't see an explanation of why it is out-of-scope.  The
> reference
> >>> > > is just to RFC5280, which seems odd.  I would expect the reference
> to
> >>> > > be to something that explains why it is out-of-scope.
> >>>
> >>> I think the the separation of certificate path validation from the TLS
> >>> protocol is correct, but perhaps this can be explained differently.
> Perhaps
> >>> the approach should be that TLS depends upon certificate path
> validation as
> >>> described in RFC 5280.
> >>>
> >>> > In general, TLS's policy (dating back to TLS 1.0) has been that the
> >>> > job of TLS is to carry the certificates and other authentication
> >>> > material but to leave it up to other parts of the system to
> >>> > interpret them. It's been a long time since that decision was made,
> >>> > but from my perspective, there are a number of major reasons:
> >>> >
> >>> > 1. Most of PKI processing (path construction, etc.) is generic and
> >>> >    not specific to TLS. What is specific to TLS is:
> >>> >
> >>> >    * How to indicate what your PKI capabilities are
> >>> >      (see, e.g, S 4.2.4 and 4.3.2)
> >>> >    * How to stuff the PKI material into the protocol
> >>> >      (principally S 4.4.2)
> >>> >    * How to determine whether a given certificate is suitable for
> >>> >      use in TLS 4.4.4.2 and 4.3.2.1).
> >>> >
> >>> >    So we want to outsource the generic PKI part
> >>> >
> >>> >
> >>> > 2. It matches the software architecture that people often use,
> >>> >    which is to have a TLS stack but separate PKI validation. For
> >>> >    instance, Firefox uses NSS for TLS but moz::pkix for
> >>> >    validation. Similarly, Chrome uses BoringSSL for TLS
> >>> >    but the system PKI libraries for validation.
> >>> >
> >>> >
> >>> > In this case, I think that this text was more intended to
> >>> > say "and go read 5280 to learn how to do this". To that end,
> >>> > I suggest we say"
> >>> >
> >>> >
> >>> >     "In general detailed certificate validation procedures are out of
> >>> >     scope for TLS. [RFC5280] provides general procedures for
> >>> >     certificate validation. This section provides TLS-specific
> >>> >     requirements.?
> >>>
> >>> I agree with the reasoning, however the dependency on RFC 5280 should
> be
> >>> called out in a MUST statement.  I suggest something like:
> >>>
> >>>     "TLS depends on certificate path validation, and a conformant
> >>>     TLS implementation MUST implement certificate paths validation
> >>>     in a manner that achieves the same result as [RFC5280]. This
> >>>     section provides TLS-specific requirements.?
> >>>
> >>> Note that RFC 5280 is already a normative reference.
> >>
> >>
> >> A MUST here would be a pretty material change to historical TLS
> practice.
> >> As Viktor says, there are TLS-using applications that just don't
> validate
> >> the cert via 5280 at all.
> >>
> >>
> >> I think we want to say that if the certificates are used, then the
> >> certification path MUST be validated in a manner that is compatible with
> >> Internet X.509 certificate profile [RFC5280]; however, other approaches
> to
> >> validation of the public key, such as the DANE TLSA resource record
> >> [RFC6698], are also acceptable.
> >
> >
> > I can see how you would want to say that, but it's not really consistent
> > either
> > with historical practice or with the way that other standards track RFCs
> use
> > TLS
> > with certificates (see RFC 5763).
> >
> >
> > Actually, that is a great example.  I accept the need for loose coupling.
>
> OK, does that put us back to the suggested wording:
>
>     "TLS depends on certificate path validation, and a conformant
>      TLS implementation MUST implement certificate paths validation
>      in a manner that achieves the same result as [RFC5280]. This
>      section provides TLS-specific requirements.?
>
> For any developers following, does this help enough with any
> interoperability questions?
>
> Thanks,
> Kathleen
>
> >
> > Russ
> >
>
>
>
> --
>
> Best regards,
> Kathleen
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>
> ------------------------------
>
> End of TLS Digest, Vol 154, Issue 61
> ************************************
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 19 May 2017 13:12:39 +0300

> So, in my opinion, TLS should be very loosely or not at all coupled with

Just commenting on that draft, I don't see anything that would specify
how the certificate message itself is formatted in TLS 1.2 if those
types are used (I presume the same as the usual TLS 1.2 X.509
certificate message[1][2]). If the formatting is the same as X.509 one,
mapping that to TLS 1.3 will be straightforward. If it is not the same,
then the mapping to TLS 1.3 has to be explicitly defined.

The reason formatting for TLS 1.2 is significant is that for TLS 1.2, it
looks like each certificate type defines its own format (and none of the
three formats so fare is the same). Also, avoid putting in any non-
certificate fields, as that causes major problems with TLS 1.3 (as seen
with OpenPGP type[3]).

[1] This is list (24-bit length) of non-empty octet strings (24 bit
length).

[2] That the message formatting is the same does not imply that the
octets string contents is in any way the same.

[3] Also, RPK had its own format in TLS 1.2, but TLS 1.3 specification
explicitly gives RPK type a new format.

-Ilari

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 19 May 2017 16:51:21 -0400

> On May 19, 2017, at 5:34 AM, Sankalp Bagaria <[email-masked]> wrote:
> 
> I would like to mention that TLS can be used with non-X.509 certificates also.

Which brings us to some more undesirable layer violation in the current
draft.  The language in question is appropriate for updates to RFC5280,
but does not belong in TLS.  The problems in question are largely
already addressed elsewhere (as CAs no longer issue MD5, SHA1, ...
certificates, browsers no longer support them, ...) and continue to
be further remediated in the appropriate standards and products.

Therefore delete:

   Section 4.2.3 (Legacy algorithms paragraph final sentence):

      ...                                       TLS 1.3 servers
      MUST NOT offer a SHA-1 signed certificate unless no valid
      certificate chain can be produced without it (see
      Section 4.4.2.2).

   Section 4.4.2.2:

   ...          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.

   Section 4.4.2.4:

   Any endpoint receiving any certificate signed using any signature
   algorithm using an MD5 hash MUST abort the handshake with a
   "bad_certificate" alert.  SHA-1 is deprecated and it is RECOMMENDED
   that any endpoint receiving any certificate signed using any
   signature algorithm using a SHA-1 hash abort the handshake with a
   "bad_certificate" alert.  All endpoints are RECOMMENDED to transition
   to SHA-256 or better as soon as possible to maintain interoperability
   with implementations currently in the process of phasing out SHA-1
   support.

I note that TLS 1.3 does not have any language prohibiting MD2, MDC2DES,
MD4, RIPEMD160, private signature oids, ... that may be weaker than SHA-1
or even MD5.

Opportunistic unauthenticated TLS ignores the peer certificate and should
not have to fall back to cleartext just because some certificate in the
chain is not sufficiently sexy.  There are other legitimate use cases where
the restrictions above are inappropriate.

The reason I am pointing this out is that I just had to waste a bunch of
time convincing the rest of the OpenSSL team to ignore the draft language
in question, and just stick with whatever "security level" (floor on
algorithm strength) the application or default settings requested.  This
already excludes MD5 by default, and we'll likely adjust the collision
resistance rating of SHA-1 from 2^80 to its reported ~2^64 strength (from
the recent Google collision announcement), after which SHA-1 will also
be excluded at security level 1.  This will be done in the X.509 ala PKIX
code and not the TLS code, and applications that ignore the chain or do
DANE-EE(3), ... will not be affected.

I propose that the current draft language is just a landmine for TLS
implementations, that addresses a non-problem (or more precisely a
problem that is more properly and well addressed elsewhere).

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Fri, 19 May 2017 16:35:27 -0500

> be further remediated in the appropriate standards and products.

+1

Grounds:

 - layering violation (though arguably this TLS 1.3 could be made to
   update RFC5280, we shouldn't want to do that)

 - banning some, but not all weak algorithms is a knee-jerk reaction --
   it's reactionary

 - this hurts applications that don't care for TLS server
   authentication -- applications which either don't care for server
   authentication at all, or which will use channel binding

 - it's much better to have a security level knob that disables weak
   algorithms

   (apps which don't care for TLS server authentication... need two such
   knobs: one for server authentication (on/off) and one for security
   level for key agreement, PRF, and ciphersuite negotiation)

> MD4, RIPEMD160, private signature oids, ... that may be weaker than SHA-1

That could be fixed, of course.  But let's not.

> algorithm strength) the application or default settings requested.  This

I much prefer the idea that there MUST be a security level knob for the
user/application.

> DANE-EE(3), ... will not be affected.

That's right: for PKIX server authentication, the security level
enforcement should be done in PKIX code, not in TLS code.  This is an
excellent example of how layering in Internet protocols should translate
into layering into implementations.  Conversely, this is also an example
of how layering violations in Internet protocols lead to layering
violations in implementations.

> problem that is more properly and well addressed elsewhere).

+1.

Nico
--

---

From: Dave Garrett <[email-masked]>
Date: Fri, 19 May 2017 21:43:19 -0400

>    with implementations currently in the process of phasing out SHA-1

No. I strongly oppose stripping all off this out.

> MD4, RIPEMD160, private signature oids, ... that may be weaker than SHA-1

They're not listed as possible field values anywhere directly in the TLS spec.
If someone wants to add a line to one of the "MUST NOT" lists somewhere for
all hashes weaker than SHA-1, that sounds fine to me.

> the restrictions above are inappropriate.

Opportunistic unauthenticated TLS isn't the protocol we're defining here.
If your goal isn't authentication, then by all means violate the requirements
laid out for authentication. I have no problem making that explicit, if desired,
however this is not the primary desired operating mode of TLS.

> problem that is more properly and well addressed elsewhere).

TLS is already a minefield of problems. Enumerating many of them explicitly
is a step forward to avoiding them more easily in the future. In a complex
system, just fixing something in one place is not enough. If we list it as
a possible option in the spec, we should be _very_ clear when it is crap.

I'm aware that this is unavoidably messy. Viktor, your input has greatly
helped improve the language here to accommodate varying use-cases,
and I would personally prefer we work together to make the mess correct,
rather than give up and delete the relevant text.

Dave

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 19 May 2017 22:15:31 -0400

> On May 19, 2017, at 9:43 PM, Dave Garrett <[email-masked]> wrote:
> 

That list was not intended to be take as a serious suggestion.  Note that
it is NOT the job of TLS to specify a comprehensive list of X.509 certificate
signature algorithm OIDS, which are MTI, which deprecated, and so on.  The
security floor you're looking for needs to be set in update to RFC5280
via the "curdle" WG or wherever else such an update belongs.

> Opportunistic unauthenticated TLS isn't the protocol we're defining here.

Actually, it very much is.  This WG defines TLS (period).  That includes
opportunistic unauthenticated TLS, opportunistic DANE TLS, TLS with
pre-shared public key fingerprints, TLS with TOFU key pinning and so on.

One reason TLS is complicated is its versatility.

> laid out for authentication.

There is no requirement for authentication.  There is only a mechanism
to make it possible.  And opportunistic TLS is NOT a violation of the
TLS specification.

> I have no problem making that explicit, if desired,

Yes, the "primary mode" is authentication via a profusion of CAs,
with most certificates being "DV" certificates, which are issued
after perfunctory verification by the CA and memoized in the form
of a certificate for the world to trust.  This means that the MiTM
BGP route injection attack has to target the route between some
trusted CA and the victim domain, rather than between the user
and the victim domain.  It's not much better than opportunistic
TLS, but yes, it does protect against low-tech attacks that only
subvert the user's network (coffee-shop, airport WiFi, ...).

So the X.509 PKI in TLS is not entirely a case of the emperor's new
clothes, but we need to be a bit more realistic about the resulting
security, and not forget that it is far from airtight, and that the
non-mainstream use-cases sometimes yield more actual security than
one might get from an all-or-nothing approach.

> a possible option in the spec, we should be _very_ clear when it is crap.

PKIX (RFC5280 via X.509) is already a minefield of problems.  The fixes
and ratcheting up the associated security parameters belong there, and
NOT in TLS.  The TLS 1.3 draft does a reasonabl job of improving the actual
TLS security design and parameters, and should properly stick to that.

[ Yes, it also adds a potential pitfall in the form of 0-RTT, but that
  is of course another thread. ]

> rather than give up and delete the relevant text.

I'd be  happy to review relevant changes in an RFC5280 update where this
belongs, and would also benefit S/MIME, CMS, etc and not just TLS.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Sat, 20 May 2017 00:41:18 -0500

> They're not listed as possible field values anywhere directly in the TLS spec.

That's because it wouldn't be TLS that mentions them but PKIX, so _of
course_ TLS doesn't reiterate everything that PKIX says.

> Opportunistic unauthenticated TLS isn't the protocol we're defining here.

TLS certainly can be used that way.  And it is.

> however this is not the primary desired operating mode of TLS.

Then state the requirements in such a way that it is still possible to
use TLS in this way.

"When using TLS to authenticate the server, certificate signature
algorithms weaker than <list of weakest acceptable signature algs here>
MUST NOT be used."

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 20 May 2017 01:55:07 -0400

> On May 20, 2017, at 1:41 AM, Nico Williams <[email-masked]> wrote:
> 

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.

This formulation does correctly place the security floor in the proper
context, namely PKIX authentication, and does not inappropriately
mandate aborting connections and the like.

A peer presenting certificates with deprecated algorithms would then
not pass PKIX authentication.  It is then up to the other party to
decide whether this matters and how to react.

This would amount in essence to a TLS-specific "profile" for PKIX.
If such a thing is really needed, so be it.  So long as we have no
text mandating connection termination based on potentially irrelevant
certificate details I can go along with a compromise in which a more
narrow prohibition of MD5 and SHA-1 remains along the lines above.

-- 
	Viktor.

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 20 May 2017 11:28:56 +0300

> No. I strongly oppose stripping all off this out.

This requirement is bad layering violation.

It is even further made problematic by:

- TLS and PKIX libraries are often decoupled, making this difficult to
  implement.
- It requires code to support MD5, which as weak algorithm is hazardous.

I do have written TLS implementation. It does not follow this, because I
regard the aborting requirements as insane (it does not have any code to
support MD5, and is not architecturally capable of aborting based on
signature algorithm).

The code treats MD5 as unknown signature algorithm, which does not
require hazardous code. Pathbuilding avoids MD5 signatures and it is
not possible to validate signatures using MD5 (algorithm conversion
will return an error).

(The SHA-1 handling is more complex, as RSA-PKCS#1v1.5-SHA1 is actually
validateable, but only in certain context. Suffice to say, I would
love to just dump the SHA-1 code).

> all hashes weaker than SHA-1, that sounds fine to me.

These are values internal to PKIX. And the draft _does_ allow sending a
certificate contaning those (hint: If the server does not have any
other chain using only signaled algorithms).

And MD5 isn't listed as possible field value either.

-Ilari

---

From: Nico Williams <[email-masked]>
Date: Mon, 22 May 2017 09:50:09 -0500

> to authenticate... (the [server or client?]).  TLS is just the transport

No, I meant what I said, as in "as opposed to using TLS
opportunistically".

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 22 May 2017 11:35:31 -0400

> On May 22, 2017, at 10:50 AM, Nico Williams <[email-masked]> wrote:
> 

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.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 22 May 2017 11:53:10 -0400

> On May 22, 2017, at 11:35 AM, Viktor Dukhovni <[email-masked]> wrote:
> 

I want to reiterate, that the simplest approach, and the one that I
would prefer, is not to repurpose the TLS 1.3 specification to carry
language that properly belongs in PKIX.  The "MUST NOT" language
related to MD5 and SHA-1 in *certificate signatures* should be removed.

-- 
	Viktor.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 22 May 2017 12:06:47 -0500

> to authenticate... (the [server or client?]).  TLS is just the transport

Given the apparent strength of opinion against removing these supposed
restrictions entirely, it seems like this text (or something similar) is
probably the best we can do.

-Ben

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 22 May 2017 13:17:18 -0400

> On May 22, 2017, at 1:06 PM, Benjamin Kaduk <[email-masked]> wrote:
> 
> Given the apparent strength of opinion against removing these supposed restrictions entirely, it seems like this text (or something similar) is probably the best we can do.

Perhaps so, but I saw only one strong objection from Dave Garrett.  Is that
sufficient for "apparent strength of opinion"?  Removal is simpler, and it
sure does not look like people are determined to continue to support MD5
and SHA-1 in certificates, but would be willing to relent if TLS 1.3 told
them not to.  Isn't the language in question tackling a non-problem?

That said, if the only way to rough consensus is a properly qualified
requirement to not rely on such certificate signatures for authentication,
(rather than must hang up with a fatal alert when you see these, must not
send these, ...) then I'll go along with a compromise.

-- 
	Viktor.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 22 May 2017 12:27:52 -0500

> Perhaps so, but I saw only one strong objection from Dave Garrett.  Is that

There was also some discussion when this text was originally going in,
IIRC.  But I do not remember well enough to say who/how many people
wanted it.

> them not to.  Isn't the language in question tackling a non-problem?

It probably is, but I don't feel a need to spend a lot of my time
pushing for it to be removed.

-Ben

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 22 May 2017 17:37:49 +0000

I assert that most uses of TLS are server-authenticated using a PKIX-compliant certificate, no matter if you count users/servers, connections, bytes transferred, or e-commerce dollar value.

It has been this way forever and that is why the TLS RFC’s have always talked about certificates, although left the chain validation up to separate RFC’s.  Note that those RFCs really only talked about *naming* not crypto.

I strongly believe the text should stay as it is, for the most good to the most people.  Viktor is in the weeds, arguably by himself.

--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: [email-masked] Twitter: RichSalz

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 22 May 2017 13:38:52 -0400

> On May 22, 2017, at 1:27 PM, Benjamin Kaduk <[email-masked]> wrote:
> 
>> Isn't the language in question tackling a non-problem?
> 
> It probably is, but I don't feel a need to spend a lot of my time pushing
> for it to be removed.

Well, the reason for this sub-thread is that I just to waste a bunch of cycles
to avoid new code in OpenSSL that would implement the spec as written and
needlessly break applications that don't care about PKIX certificates.

A nameless team member suggested casually that such applications can just
disable TLS 1.3...

And yet TLS 1.3 brings desirable improvements, and should not have needless
restrictions on the supported use cases.

Therefore, the language should go, or needs to be amended to make it clear
that TLS does not prohibit (mandate connection abort, ...) the appearance
of any certificate signature algorithms in the certificate message.  Advice
to not trust such algorithms for authentication is unnecessary, but acceptable.

-- 
	Viktor.

---

From: Yoav Nir <[email-masked]>
Date: Mon, 22 May 2017 20:45:41 +0300

> On 22 May 2017, at 20:27, Benjamin Kaduk <[email-masked]> wrote:
> 
>>> On May 22, 2017, at 1:06 PM, Benjamin Kaduk <[email-masked]> <mailto:[email-masked]> wrote:
>>> 
> There was also some discussion when this text was originally going in, IIRC.  But I do not remember well enough to say who/how many people wanted it.

This came up in one of the F2F meetings. I believe I argued that we shouldn’t have PKIX policy in a TLS document, because if signing certificates with SHA-1 is bad, it’s bad for all users of certificates, and should be prohibited by a PKIX document, not a TLS document.

The room was against me then. So it may look now like it’s just Dave (and now Rich), there was more support for this at the time.

Yoav

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 22 May 2017 13:46:58 -0400

> On May 22, 2017, at 1:37 PM, Salz, Rich <[email-masked]> wrote:
> 

Right, all by myself...  With support from Nico, Ilari, and others who've upthread
accepted that certificate verification is properly RFC5280 and not TLS, before I
suggested removal of the text in question (which solves no real problem, but does
create needless interoperability issues for various TLS use-cases).

The dominant use case is not the only one that needs consideration,
and text that breaks other use-cases is NOT just fine, and the TLS
WG really does need to think more broadly than the Web PKI.  This is
not the HTTPS working group.

-- 
	Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 23 May 2017 04:42:45 +0900

Well, I certainly think past the Web PKI, because one of the cases I care
about
is WebRTC, which doesn't do any PKI validation at all.

In any case, I think there are two issues:
1. Forbid TLS 1.3 implementations from accepting MD5 and SHA-1.
2. Require a specific failure if the peer presents such a certificate.

There was pretty strong consensus to do #1 and I don't support removing
it. That seems like a pretty modest layering violation. If people think that
the mandate for this specific alert is too onerous, I could live with
removing
that.

-Ekr

On Tue, May 23, 2017 at 2:46 AM, Viktor Dukhovni <[email-masked]>
wrote:

> > I strongly believe the text should stay as it is, for the most good to
> the most people.  Viktor is in the weeds, arguably by himself.
>

---

From: Nico Williams <[email-masked]>
Date: Mon, 22 May 2017 15:17:30 -0500

On Tue, May 23, 2017 at 04:42:45AM +0900, Eric Rescorla wrote:
> Well, I certainly think past the Web PKI, because one of the cases I
> care about is WebRTC, which doesn't do any PKI validation at all.
> 

I don't understand how you can have (1) and not (2).

Unlike Viktor (though I also don't like the layering violation) I'm not
proposing removing that text altogether, but tweaking it to allow
opportunistic and other TLS usage.

Instead of altogether forbidding certs with MD5 signatures, forbid them
when the application expects TLS to authenticate the server [with PKIX,
as opposed to certain DANE usage values, or with pre-shared certs,
etc.].  I.e., a server authentication security level knob is needed.

Nico

> > Right, all by myself...  With support from Nico, Ilari, and others
> > who've upthread accepted that certificate verification is properly
> > RFC5280 and not TLS, before I suggested removal of the text in
> > question (which solves no real problem, but does create needless
> > interoperability issues for various TLS use-cases).
> >

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 23 May 2017 05:26:28 +0900

> I don't understand how you can have (1) and not (2).

As Ilari suggests, you could just treat the algorithms as unknown.

> etc.].  I.e., a server authentication security level knob is needed.

I don't think that the current text prohibits that, because of :

   The signatures on certificates that are self-signed or certificates
   that are trust anchors are not validated since they begin a
   certification path (see [RFC5280], Section 3.2).  A certificate that
   begins a certification path MAY use a signature algorithm that is not
   advertised as being supported in the "signature_algorithms"
   extension.

In this case, I think one can argue are treating this as a trust anchor.
Feel free to propose
new text that you think makes that clearer.

-Ekr

> Nico
>
> > On Tue, May 23, 2017 at 2:46 AM, Viktor Dukhovni <[email-masked]
> >
> > wrote:

---

From: Nico Williams <[email-masked]>
Date: Mon, 22 May 2017 15:43:26 -0500

> As Ilari suggests, you could just treat the algorithms as unknown.

How does that square with (1)?

> I don't think that the current text prohibits that, because of :

That takes care of DANE and pre-shared cert uses, but not of
opportunistic use.  And maybe not of TOFU either: since on first use the
server's cert won't be known to the client, it's not a "trust anchor"
yet and cannot fall under this safe-harbor.

> In this case, I think one can argue are treating this as a trust
> anchor.  Feel free to propose new text that you think makes that
> clearer.

Proposal:

   Clients SHOULD/MUST NOT accept server certificates, or certificate
   validation paths, where the server certificate or intermediate
   certificates (but not trust anchors) are signed with "weak" signature
   algorithms, unless the client is not expecting TLS to strongly
   authenticate the server (e.g., for opportunistic use) or where the
   client has previously learned and cached the server's certificate.

   A "weak" signature algorithm is any of <list1>, or any that isn't on
   <list2> and was introduced prior to publication date of this
   document.

The last is a way to eliminate any old hash.  List some of them in
<list1>, list all the allowable ones that we know about today in
<list2>, and the publication date will take care of any that should have
been on <list1> but was not listed in it, while future-proofing <list2>.

Nico
--

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 23 May 2017 05:49:47 +0900

On Tue, May 23, 2017 at 5:43 AM, Nico Williams <[email-masked]>
wrote:

> > > > it. That seems like a pretty modest layering violation. If people
> think
> > > that

I don't understand the question. If you treat them as unknown then either
your path construction code will route around them or once you try to
verify,
it will fail.

> yet and cannot fall under this safe-harbor.

I wouldn't have any trouble interpreting it that way.

>    client has previously learned and cached the server's certificate.

I don't think "strongly authenticate" is useful here. I think the
requirement
is that the RP must not accept these algorithms in any context which would
require validating signatures made using them.

-Ekr

---

From: Nico Williams <[email-masked]>
Date: Mon, 22 May 2017 16:00:20 -0500

On Tue, May 23, 2017 at 05:49:47AM +0900, Eric Rescorla wrote:
> I don't understand the question. If you treat them as unknown then
> either your path construction code will route around them or once you
> try to verify, it will fail.

That *really* seems like a layer violation!

> I wouldn't have any trouble interpreting it that way.

Why not be clear?

> requirement is that the RP must not accept these algorithms in any
> context which would require validating signatures made using them.

Well, I want it to be crystal clear that the "not MD5 and such"
requirement need not apply to opportunistic TLS usage.  If you don't
like my text, maybe you can propose your own.

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 22 May 2017 17:02:20 -0400

> On May 22, 2017, at 3:42 PM, Eric Rescorla <[email-masked]> wrote:
> 
> Well, I certainly think past the Web PKI, because one of the cases I care about
> it.

The operative word here is *was*.  Time has passed, and things have changed:

	1.  The motivating problem (broad use of weak hashes in Web PKI
            certificates) has become a non-problem.  The CAs and the browsers
 	    have moved on.

	2.  We've since had many discussions that make it clearer still that
	    layer violation into RFC5280 space is suboptimal.

	3.  While did not object strongly at the time, I've since seen that the
 	    language in question temps TLS stack authors to implement checks against
	    the specific certificate algorithms at the TLS layer, instead of at the
	    X509 verification layer where X509 security checks belong.

Surely there are some old GOST signature algorithms that could appear in certificates,
that TLS 1.3 does not prohibit, but which are not much stronger than SHA-1, and if not
GOST then something else.  Plucking out the specific code-points in question is both
insufficient and counter-productive.

It is time to revisit the previous consensus, because its motivation is no longer
relevant, and its negative consequences are more apparent.

-- 
	Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 23 May 2017 06:20:18 +0900

This document has WGLC and so has a presumption of consensus. If you want
to re-raise that, this is a process question which is the province of the
chairs, so if you feel strongly, as it appears you do, I would encourage
you raise it with them.

-Ekr

On Tue, May 23, 2017 at 6:02 AM, Viktor Dukhovni <[email-masked]>
wrote:

> care about

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 23 May 2017 06:22:30 +0900

> That *really* seems like a layer violation!

As I said, I don't have a problem with it. It's TLS giving instructions to
the PKI subsystem.

> requirement need not apply to opportunistic TLS usage.

I don't think "opportunistic" is a clearly enough defined category to be
useful
here. Rather, I think the relevant criterion is the one I listed above. If
people
agree, I'd be happy to make that change (and can produce text) because I
think it conforms to the WG consensus.

-Ekr

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 22 May 2017 17:31:55 -0400

> On May 22, 2017, at 5:22 PM, Eric Rescorla <[email-masked]> wrote:
> 
> I don't think "opportunistic" is a clearly enough defined category to be useful
> here.

> context which would require validating signatures made using them.

That's fine.

> Rather, I think the relevant criterion is the one I listed above. If people

The above formulation (where the relying party does not accept certain
signature algorithms as valid in the context of validating issuer
signatures) works for me.  All I'm looking for is not requiring the
RP to abort the handshake as soon as the algorithm is encountered,
even when the signature would never be checked!

So if putting the consensus to ban MD5/SHA-1 in its *proper context*
is consistent with the WG consensus, let's do that.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Mon, 22 May 2017 18:30:41 -0500

> As I said, I don't have a problem with it. It's TLS giving instructions to

It implies more APIs.

> useful here. Rather, I think the relevant criterion is the one I
> listed above. If people agree, I'd be happy to make that change (and
> can produce text) because I think it conforms to the WG consensus.

Opportunistic == "If the server got authenticated great, if not, that's fine too"

If the server was not authenticated, the app might use channel binding,
or learn the server's cert (TOFU), or just use the connection because
the only thing the application cares about is key agreement (defeat
eavesdropers, but not active attackers).  The last one is Viktor's use
case (SMTP).

Nico
--

---

From: Dave Garrett <[email-masked]>
Date: Mon, 22 May 2017 20:19:46 -0400

> is consistent with the WG consensus, let's do that.

Yes, please.

Citing discussion elsewhere in this thread (that probably should've all
been forked off with a different subject long before now...):

> like my text, maybe you can propose your own.

My issue with this area is that we've got this fairly weird two tiered
problem where we're still pretending SHA-1 is vaguely acceptable in some
scenarios where certificates are being validated, and thus we need two
sets of language: one for weak hash MUST NOTs and another for weak hash
SHOULD NOT. The current text was written before SHA-1 was broken back in
February, so, while the topic of changing language we had consensus on is
up, I'd really like to make SHA-1 completely banned for standard certificate
authenticated TLS 1.3+ connections alongside MD5. To do this in a
non-messy way, we'd have to delete the SHA-1 special-casing and state
that TLS 1.3+ implementations can only use deprecated hashes
(MD5/SHA1/SHA224/etc) if explicitly doing opportunistic encryption or some
scenario where trust can be established without validating them. Again,
the trust anchor gets an exception here due to it being trusted directly
without need for validation, and they can get away with just a "NOT
RECOMMENDED". If we can agree to this, then the resulting text will end up
being far less problematic. If we can't get a consensus for this, I seriously
propose citing RFC 6919 s3.

Dave

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 22 May 2017 20:29:13 -0400

> On May 22, 2017, at 8:19 PM, Dave Garrett <[email-masked]> wrote:
> 
> scenario where trust can be established without validating them.

Works for me.  In all the use-cases I care about the hash algorithm in
question is never actually used to validate any certificate signatures,
but the spec seems to require that the handshake be aborted anyway, just
because the codepoint is present in the chain.

I have no objections to banning *actual* use for making verification
decisions of all hash functions with collision resistance less than
say 120 bits (128 - modest fuzz for attacks that don't significantly
damage the algorithm).

What I am trying to avoid is having implementations just hang up
because the peer's certificate message contains "toxic" codepoints,
that will never actually get used, because verification is not
performed at all, or performed by means other than PKIX, or with
different intermediate certificates than presented.

Setting a collision-resistance floor rather than naming some list
of algorithms makes more sense to me, but if the WG really feels
that naming some "verbotten" algorithms is better, so be it.

-- 
	Viktor.

---

From: Dave Garrett <[email-masked]>
Date: Mon, 22 May 2017 20:57:30 -0400

> that naming some "verbotten" algorithms is better, so be it.

My preference would be to do both. Call out the ones we have
codepoints for by name (MD5/SHA1/SHA224), then have a general
collision-resistance floor value for everything else.

Dave

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 22 May 2017 21:06:37 -0400

> On May 22, 2017, at 8:57 PM, Dave Garrett <[email-masked]> wrote:
> 

OK by me, with previous proviso on the appropriate context,
namely actual use by the relying party, not mere appearance
on the wire.  That is, effectively the RP behaves as though
the code points are unknown, but with "lazy evaluation"[1].

-- 
	Viktor.

[1] With "lazy evaluation" one is not forced to fail to parse
the certificate if parsing requires having known code points.
So long as no use of the underlying algorithm is made, the
intent of the prohibition is accomplished.

---

From: Bill Frantz <[email-masked]>
Date: Mon, 22 May 2017 21:19:30 -0700

>create needless interoperability issues for various TLS use-cases).

Please allow me to add my voice to Viktor's. When I wrote the E 
language communication protocol, many people said I should use 
SSL. Some of the reasons we did not use SSL are in a 1998 
document <http://www.erights.org/elib/distrib/vattp/SSLvsDataComm.html>.

Our protocol started with a hash of the peer's public key. With 
that bit of information, other authentications are unnecessary. 
If I were starting today, we could use TLS with PSKs by asking 
the other side for it's key and then using it with a TLS library 
(I think).

Cheers - Bill

---------------------------------------------------------------------------
Bill Frantz        |"Web security is like medicine - trying to 
do good for
408-356-8506       |an evolved body of kludges" - Mark Miller
www.pwpconsult.com |

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 23 May 2017 12:29:22 +0300

> That *really* seems like a layer violation!

The code I have tries to route around (with equivalent to exhaustive
search of all paths).

And altough the code I have has the TLS and certificate code more
tightly bound togethe than most libraries, the certificate validation
algorithm handling is wholly inside the certificate handling part.

The algorithm handling being inside certificate code is even true for
SHA-1 signatures, which have nontrivial validity rules (only allowed
for dedicated OCSP responders).

The certificate code does not concern itself about TLS version it
is running on. The exchange signature (which has differences between
TLS versions) is direct signature validation and does not involve
certificate code.

BTW:

Section 4.4.3. seemingly allows use of unadvertised exchange signature
schemes if advertised one can't be used. This should be fixed: There
is no way that can actually work (even pinning the server's key doesn't
make that work, unlike say EE certificate being signed with something
unknown).

-Ilari

---

From: Nico Williams <[email-masked]>
Date: Tue, 23 May 2017 12:51:55 -0500

+1

> My issue with this area is [...]
>                                            [...]. To do this in a

Works for me!

> propose citing RFC 6919 s3.

Yes, trust anchors are and should always be excepted (and need not be in
the form of certificates anyways).

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 23 May 2017 13:07:11 -0500

> collision-resistance floor value for everything else.

Sure.

In general I prefer setting floors, as Viktor says.  That's because
listing all forbidden algorithms is easy to flub up, and because it's
much easier from an API point of view to specify security levels than to
go listing things that are allowed/forbidden.

I think we should have standard algorithm security profile names that
can be used in multiple protocols.  E.g.,

 - weak         (obsolete weak algorithms allowed)
 - interim      (certain obsolete weak algorithms allowed during migrations)
 - default      (default security floors, no obsolete weak algorithms allowed)
 - stronger     (like standard but with higher security floors)

 - <URN?>       (local/custom security level, perhaps specified
                 additively from standard security levels)

The meaning of each of these would be updated over time by updating the
RFCs for the relevant protocols.  Thus configurations would not have to
change.

Specifying such a security level to TLS would have it apply that level
to its ciphersuite, PRF, key agreement, PSK, and signature algorithms,
and pass it to PKIX when using PKIX.

Specifying such a security level to PKIX would have it apply that level
to certificate public key and certificate signature algorithms, as well
as to path construction and validation.

Specifying such a security level to Kerberos, SSHv2, ... would ...
And so on.

This would make security level configuration much easier in the common
case.  And would avoid periodically having to update configurations to
adjust for recent cryptanalysis advances: just update the meanings of
these standard security levels and update software.

Nico
--