Subject: [TLS] Summary of discussion regarding spontaneuous authentication

From: Martin Thomson <[email-masked]>
Date: Wed, 22 Oct 2014 03:04:33 -0700

The update proposal that ekr sent around was discussed.

The primary concern was that the properties of the connection were
considered to change with respect to authentication.  Any data
received before the authentication, or messages that appear partially
before and partially after would have ambiguous properties.

Concerns were raised that having the authentication attest to data
that was sent prior to the authentication would expose us to a variety
of attacks that relied on confusion about the state of the connection.
There was also a concern that this would be difficult to analyse.

It was pointed out that update was still interesting, but only from a
rekeying perspective, because that had far lesser risks and no real
API implications.

If we decided to continue with Update, then we would have a place to
add a future extension that re-enabled this feature.

I noted that the use case that renegotiation provides was not going to
be supported with the proposed Update message, since there was no
analogue for the HelloRequest message.

All of this led to the decision not to pursue spontaneous authentication.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 Oct 2014 05:07:29 -0700

I forgot one point that we discussed.

We discussed the removal of the CertificateRequest and we will permit
the client to unilaterally send authentication.

The theory here is that clients tend to know whether they need to
authenticate.  Most uses of mutual authentication start with the
client knowing that they need to authenticate.  Anything more
complicated will require some application protocol signals.

This also avoids the deficiencies with CertificateRequest, allowing -
or requiring - application protocols to provide equivalent
functionality if that is desired (see my -cant proposal for one
potential way to do that).

---

From: Tom Ritter <[email-masked]>
Date: Wed, 22 Oct 2014 08:51:22 -0400

> the client to unilaterally send authentication.

Will permit it to be absent, or will remove CertificateRequest entirely?

> client knowing that they need to authenticate.

Well, the human knows he needs a client certificate for this website, the
Browser does not unless it stores that information. (And still needs to
learn it for first connect)

If CertificateRequest is being removed, it's not clear to me how a browser
would know to include a client cert. An alert and reconnect?  (For other
applications like VPNs, obviously much easier to solve.)

-tom

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 22 Oct 2014 15:53:59 +0300

> the client to unilaterally send authentication.

CertificateRequest has fields certificate_types and
supported_signature_algorithms (there's also third field, but IMO
that's better sent at application level). Where is the equivalent
data put?
 
> > There was also a concern that this would be difficult to analyse.

The behaviour of authentication credentials being updated mid-connection
is highly application-dependent.

In practicular, any application protocol wanting to support such thing
needs to carefully specify, in race-free way, what authority applies
to each piece of data.

So client doesn't send piece of data, thinking it is using authority A,
but server goes and interprets it using authority B.

And for some applications, one wants to be possible to have multiple
authentications at once.

Client and server being confused about authority results in security
holes. And those holes are being exploited in the wild.

> > rekeying perspective, because that had far lesser risks and no real

Note that rekeying interacts with TLS-EXTRACTOR, which is part of API.

In practicular, how to avoid race conditions between key update and
use of TLS-EXTRACTOR output?

-Ilari

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Wed, 22 Oct 2014 15:06:29 +0200

> Will permit it to be absent, or will remove CertificateRequest entirely?
My understanding is it would be entirely removed.

> applications like VPNs, obviously much easier to solve.)
That would be moved to the application layer, eg for HTTP(bis) that would be
addressed by Martin's "cant" draft as he briefly mentioned:
https://tools.ietf.org/html/draft-thomson-httpbis-cant-01

Manuel.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 Oct 2014 06:08:17 -0700

> that's better sent at application level). Where is the equivalent

At the application layer.

These fields, as specified, are not particularly useful in the general
sense.  The suggestion was that these are not valuable:
certificate_types is pretty much either known a priori (or assumed to
be X.509) and signatures have a similarly limited set of options.

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 22 Oct 2014 16:26:23 +0300

> be X.509) and signatures have a similarly limited set of options.

Don't confuse certificate_types with {client,server}_certificate_type{,s}.

The relevant values of certificate_types look to be:
- rsa_sign (RSA signature)
- dss_sign (DSA signature)
- ecdsa_sign (ECDSA signature)

(There are some others, but all are either RESERVED or obviously
incompatible with TLS 1.3).

supported_signature_algorithms looks to be supported combinations
of signature (RSA/DSA/ECDSA) and hash.

Especially supported_signature_algorithms looks to belong to TLS
layer (and also arguably certificate_types).

Now, the "third field" was certificate_authorities. Now that is
better sent on application layer.

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 Oct 2014 07:29:21 -0700

> Don't confuse certificate_types with {client,server}_certificate_type{,s}.

The claim was that this is either known, period, or can be pushed to
the application layer.  Fact is, what we have is this:

Clients have one or zero certificates for a given server and will use
that regardless of what appears in the CertificateRequest.

Servers have one or zero certificates for each name they offer and
will use that no matter what.

I tend to think that we need a more general mechanism for indicating
support for certificate types and signature algorithms.  Maybe we
could unconditionally include those in the early handshake instead.

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Wed, 22 Oct 2014 16:30:58 +0200

> - ecdsa_sign (ECDSA signature)
I think the point is, a client is actually quite unlikely to have many
certificates for the same server, distinguished only by the key type, so that
this information is generally not useful at all for certificate selection.

> layer (and also arguably certificate_types).
Same as above.

Manuel.

---

From: Watson Ladd <[email-masked]>
Date: Wed, 22 Oct 2014 07:31:39 -0700

> before and partially after would have ambiguous properties.

Why is the proposal worse than fixed renegotiation in this regard? I
agree, it's possible to simplify a lot by forcing reconnection to
authenticate, but it isn't necessary to do so.

> analogue for the HelloRequest message.

As far as I can tell, not true with regard to HTTP. I believe (but may
be wrong) that when a client is informed by a server it needs to
authenticate to make a request, that this is done by an error code,
not sending a HelloRequest message.

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

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 22 Oct 2014 16:34:19 +0200

> not sending a HelloRequest message.

That's correct for RFC 7235 authentication (i.e.. Basic and Digest)
but not for TLS Client Authentication.

-Ekr

---

From: Watson Ladd <[email-masked]>
Date: Wed, 22 Oct 2014 07:37:56 -0700

> but not for TLS Client Authentication.

So if we want to get rid of changing authentication state in the
middle of a connection, how do we support that?

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 Oct 2014 07:43:20 -0700

> authenticate, but it isn't necessary to do so.

The concern wasn't that it was worse than renegotiation: the opposite
in fact because fewer things change.

The concern was that it wasn't appreciably better with respect to the
state of authentication.  And it was more complicated.

> not sending a HelloRequest message.

That is only a proposal (my -cant thing).  The way this works in
servers today, in TLS 1.2 and earlier is that servers see the request,
identify the need for client authentication and send a HelloRequest.
Once the renegotiation handshake completes and the client has provided
valid credentials, the server sends the response.  In effect, the
authentication is invisible at the HTTP layer, where -cant proposes to
make this explicit.

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 22 Oct 2014 17:59:00 +0300

> that regardless of what appears in the CertificateRequest.

That's an argument for pushing certificate_types to application layer,
but not IMO valid argument for supported_signature_algorithms.
 
> could unconditionally include those in the early handshake instead.

Yeah, agreed. The supported_signature_algorithms could very well
be pushed to ServerHello (or EncryptedExtensions!).

Also, the current supported_signature_algorithms is not quite expressive
enough for ECC. The problem is, there are implementations like:

- ECDSA/SHA-256 is ok when using 256-bit curve.
- ECDSA/SHA-384 is ok when using 384-bit curve.
- Try to use ECDSA/SHA-256 with 384-bit curve or ECDSA/SHA-384 with 256-
  bit curve and things just blow up.

Such implementation would signal ECDSA/SHA-256 and ECDSA/SHA-384 in
supported_signature_algorithms, but that is not the whole story.

-Ilari

---

From: [email-masked] (Martin Rex)
Date: Wed, 22 Oct 2014 17:18:19 +0200 (CEST)

Martin Thomson wrote:
> authenticate.

This looks like a bad idea to me.
The by far most important information in the current CertificateRequest
handshake message is the "certification_authorities" field, which indicates
certificate issuers which the server considers acceptable.
In SSLv3 and TLSv1.0 the certificate_authorities field was required
to be non-empty and no (server) behaviour was defined for the meaning
of an empty certification_authorities field in CertificateRequest.

The TLSv1.1 and TLSv1.2 specification contain a defect in that they
modified the PDU definition to allow an empty certification_authorities
field in CertificateRequest, but failed to define (require) a server
behaviour when the server does not send this information.
Without the requirement, that the serer MUST NOT abort the TLS handshake
when sending an empty certificate_authorities and receiving a certificate
which it does not trust, the use of an empty certificate_authorities
field does not make sense.

With recent versions of Lync, Microsoft seems to automatically create a
Lync-specific "SSL client identity" that works for nothing but Lync, but
will successfully interfere with SSL client credentials selections when
browsers are using an SSL client identity for accessing regular Web sites.

To make SSL client certificate authentication work reasonably
a CertificateRequest that conveys acceptable certificate_authorities
for the specific handshake is absolutely necessary.

Apple Safari seems to be notoriously broken when it comes to SSL client
certificate selection, because it fails to process the certificate_authorities
field from a CertificateRequest handshake message and remove obviously
unacceptable certs from the list of credentials that the user is
presented to select from.   I've had customers report connection
failures to our AppServers, and from the server-side error messages
I could see that the client was trying to connect with some appleid
certificate that our server didn't trust (and certainly never announced
in the CertificateRequest.certificate_authorities field.

Microsoft had a similar problem in WinHTTP in 2005
http://support.microsoft.com/kb/909425/en

After WinHTTP was fixed to provide the necessary information
to application callers, it is still necessary for application callers
to actually _use_ that information to select only acceptable certificates,
and that seems to take years to happen.
This is the fix for Office/WebDAV:
http://support.microsoft.com/kb/2647954/en

And Apple Safari 4 Windows also still has this bug today.

With the certificate_authorities field in the current CertificateRequest
handshake message, these are only (fixable) bugs.  With the removal
of the CertificateRequest handshake message, this problem would be
promoted to a TLSv1.3 protocol design flaw, and become unfixable.

-Martin

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 22 Oct 2014 11:59:48 -0400

> support for certificate types and signature algorithms.  Maybe we could
> unconditionally include those in the early handshake instead.

Yes.  In two years when MSFT and Google start deprecating SHA-2 for Keccak, it'd be nice to know which cert chain to send.  Or when I don't know whether to send an RSA or ECDSA certificate next year. 

--  
Principal Security Engineer, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Tom Ritter <[email-masked]>
Date: Wed, 22 Oct 2014 12:34:12 -0400

On 22 October 2014 11:18, Martin Rex <[email-masked]> wrote:
]> Apple Safari seems to be notoriously broken when it comes to SSL client
> presented to select from.

Hah, I did not know that, but can confirm this is the case on an
up-to-date Safari+OSX10.9.

-tom

---

From: Joseph Salowey <[email-masked]>
Date: Wed, 22 Oct 2014 09:51:46 -0700

> promoted to a TLSv1.3 protocol design flaw, and become unfixable.
[Joe]  I'm also concerned that removing the certificate request in favor of
some application indication will leave behind applications that do not
currently have a mechanism to communicate this.   If we are going to remove
the certificate request I think we will need to communicate this
information in the handshake itself or perhaps have a "reconnection
request".

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 Oct 2014 11:37:24 -0700

On 22 October 2014 09:51, Joseph Salowey <[email-masked]> wrote:
> If we are going to remove the certificate request I think we will need to
> communicate this information in the handshake itself or perhaps have a
> "reconnection request".

I'd like to be more explicit about algorithm support in general here,
and I don't think that binding authentication methods into the cipher
suite selection is going to be the best way to do this given the
proposals we have on the table regarding proof-of-identity here.

The thought here was that the application layer knows about the need
for authentication and can provide the reconnection request (a la
draft-..-cant).

We're also not saying that it's end-of-the-line for authentication
within TLS.  It was shown that it was trivial to add mid-session
authentication, but the concerns were related more to the way that
interacts with users of TLS.

Thus, at least in my read of this, we are willing to punt on this for
now, and pursue it separately.  That helps us get core use cases for a
simpler TLS 1.3 complete earlier, which I think is a net gain.  I
think that a relatively small amendment could be used to add
Certificate and CertificateVerify messages to Update at some later
point if we convinced ourselves that the implications were manageable.

---

From: Andrei Popov <[email-masked]>
Date: Wed, 22 Oct 2014 19:20:04 +0000

I have the same concern as Joe: not all applications have a mechanism in place to request TLS client auth; such apps would not be able to use TLS1.3. Nor is it desirable to update all the application protocols that use TLS client auth. We need this mechanism in the TLS handshake, and perhaps we can do better than CertificateRequest: certificate type and trusted issuers list are not the only useful credential selection criteria.

Cheers,

Andrei

From: TLS [mailto:[email-masked]] On Behalf Of Joseph Salowey
Sent: Wednesday, October 22, 2014 9:52 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [TLS] Summary of discussion regarding spontaneuous authentication

On Wed, Oct 22, 2014 at 8:18 AM, Martin Rex <[email-masked]<mailto:[email-masked]>> wrote:

[Joe]  I'm also concerned that removing the certificate request in favor of some application indication will leave behind applications that do not currently have a mechanism to communicate this.   If we are going to remove the certificate request I think we will need to communicate this information in the handshake itself or perhaps have a "reconnection request".

-Martin

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

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Wed, 22 Oct 2014 22:32:33 +0200

On 22/10/2014 17:59, Salz, Rich wrote:
> Yes.  In two years when MSFT and Google start deprecating SHA-2 for Keccak,
> it'd be nice to know which cert chain to send.  Or when I don't know whether
> to send an RSA or ECDSA certificate next year.
> 
But you're on the server side, aren't you? There are indeed many reasons (RSA vs
ECDSA, SHA-x vs SHA-y) why a server wants to have many valid certs and pick one
based on what the client supports.

I'm not sure I can imagine so many plausible scenarios where the *client* has
many certs bound to the same identity and would need to pick one based on what
the server supports. Most of the time, the client cert will have been issued by
the same entity that runs the server, anyway.

Manuel.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 27 Oct 2014 15:07:22 -0700

One way to handle this would be to separate out the things that indicate
cryptographic capabilities from those that indicate proposed identity.

Specifically, CertificateRequest currently contains:

      struct {
          ClientCertificateType certificate_types<1..2^8-1>;
          SignatureAndHashAlgorithm
            supported_signature_algorithms<2^16-1>;
          DistinguishedName certificate_authorities<0..2^16-1>;
      } CertificateRequest;

But as is noted in 5246, there is redundancy here:

   The interaction of the certificate_types and
   supported_signature_algorithms fields is somewhat complicated.
   certificate_types has been present in TLS since SSLv3, but was
   somewhat underspecified.  Much of its functionality is superseded by
   supported_signature_algorithms.  The following rules apply:

And since we have removed the non-signing modes in 1.3, arguably we *just*
need signature_algorithms to specify the cryptographic parameters. Further,
I would argue that the certificate_authorities field is an practice a mess
and doesn't belong at the TLS layer (note that we don't have an analog to
it for the client to tell the server which CAs it supports). [0]

I would argue that the natural thing to do is to keep the cryptographic
pieces
in TLS but move them into the extensions (to match what the client sends).
Specifically, in TLS 1.3 do:

1. Modify https://tools.ietf.org/html/rfc5246#section-7.4.1.4.1 to let the
server send the SignatureAlgorithms extension in the ServerHello.

2. Allow the server to send the Supported Elliptic Curves extension
https://tools.ietf.org/html/rfc4492#section-5.1.1 in the ServerHello.

This would have a number of advantages:

1. A more symmetric design since you would use the same extensions in
both directions.

2. A more expressive (and yet simpler) cryptographic negotiation design
since we could indicate both algorithms and groups.

3. Push off the clumsy PKI-based part into the application while leaving the
TLS-relevant crypto part in TLS.

4. It's consistent with both server-solicited and unsolicited authentication
because the client knows what kinds of certificate it is allowed to deliver.

If we make this change, we could still leave CertificateRequest in place,
but
it could be empty, just indicating that the server wants some kind of client
auth and let the client decide. We might also allow the client to say that
he is going to provide it and let the server say OK, to match MT's CANT
draft. The point is that this would leave us with an orthogonal design that
detached capabilities from requests.

-Ekr

On Wed, Oct 22, 2014 at 8:59 AM, Salz, Rich <[email-masked]> wrote:

> Yes.  In two years when MSFT and Google start deprecating SHA-2 for
> Keccak, it'd be nice to know which cert chain to send.  Or when I don't
> know whether to send an RSA or ECDSA certificate next year.
>
> --

---

From: Martin Thomson <[email-masked]>
Date: Mon, 27 Oct 2014 16:03:48 -0700

> detached capabilities from requests.

I think that your proposed change makes a lot of sense.  I think that
what I'd like to see is something very definite: either a certificate
is provided, or not.  If Finished is at all at risk (and I think that
it is), then we'll need a clear demarcation point at the end of the
handshake.

Also, as the discussion on Update highlighted, I think that we want
explicit acknowledgment of any attempt to authenticate.  This is only
really relevant for the client, which needs to be able to know that
the server has received credentials (authorization is, of course, a
decision separate from that).

---

From: Joseph Salowey <[email-masked]>
Date: Mon, 27 Oct 2014 21:27:26 -0700

> it for the client to tell the server which CAs it supports). [0]
[Joe]  While I'm not a huge fan of the certificate authorities list, I'm
not sure that punting this to the application layer is the right thing to
do.  Some uses of TLS do not have a way to signal this in a higher layer.
For example, there are some EAP-TLS clients that will choose what
certificate to use based on this information from the server.   It may be
possible to extend EAP-TLS to send a client identity hint or similar
information in the first message from the server, but there really isn't
space in EAP-TLS for non-tls data.   An alternate approach would be the
client makes a guess as to which cert to use and if it isn't right then the
server sends a message encoded in TLS that tells the client what to do.
I'm not overly excited about wither of these approaches since they will
require changes to the applications.

> detached capabilities from requests.
[Joe]  I'm not convinced about pushing the PKI part to the application yet,
but I like the rest of the concept.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 27 Oct 2014 21:40:19 -0700

On 27 October 2014 21:27, Joseph Salowey <[email-masked]> wrote:
> While I'm not a huge fan of the certificate authorities list, I'm not sure
> that punting this to the application layer is the right thing to do.

Would you be interested perhaps in an optional TLS extension that
allows both client and server to express something about what they are
willing to consider as being authoritative?

---

From: Joseph Salowey <[email-masked]>
Date: Mon, 27 Oct 2014 21:52:39 -0700

> willing to consider as being authoritative?

[Joe] Yes, I was thinking this would be the way to go, especially if there
was interest in this for multiple protocols.

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 28 Oct 2014 16:56:53 +0000

CA list has been a double-edged sword.

For cross certified environments, some clients do not present a valid certificate when the Server root and the client root are cross certified and both parties can build valid paths.  Browsers vendors have not fixed this concern.

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Martin Thomson
Sent: Tuesday, October 28, 2014 12:40 AM
To: Joseph Salowey
Cc: [email-masked]
Subject: Re: [TLS] Summary of discussion regarding spontaneuous authentication

On 27 October 2014 21:27, Joseph Salowey <[email-masked]> wrote:
> While I'm not a huge fan of the certificate authorities list, I'm not 
> sure that punting this to the application layer is the right thing to do.

Would you be interested perhaps in an optional TLS extension that allows both client and server to express something about what they are willing to consider as being authoritative?