Subject: Re: [TLS] Review of PR #209

From: Andrei Popov <[email-masked]>
Date: Tue, 15 Sep 2015 20:17:56 +0000

Perhaps we can simplify the protocol by pulling client auth out of the handshake as follows:

1. CertificateRequest, client Certificate, CertificateVerify and NewSessionTicket messages use a new content type distinct from "handshake".
2. The client can send Certificate and CertificateVerify at any time application data is permitted, regardless of whether the server had previously sent CertificateRequest.
3. The server can send CertificateRequest and NewSessionTicket at any time application data is permitted. Alternatively, the server can encapsulate CertificateRequest in an application protocol message.

Encapsulating CertificateRequest in an application protocol message allows the client to determine which specific application request resulted in the need for client auth. The application protocol would of course need to allow this.

As far as I can tell, the above scheme seems to work in both 0-RTT and 1-RTT modes.

We can decide exactly what CertificateVerify would be signing: whether it's the handshake hash or some form of RFC5705 Exported Keying Material (EKM).

Thoughts?

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Martin Thomson
Sent: Saturday, July 25, 2015 8:00 AM
To: [email-masked]
Subject: [TLS] Review of PR #209

Andrei proposes two changes in https://github.com/tlswg/tls13-spec/pull/209

The first expands the ways in which a server can identify certificates.  This is fine.  I do wonder whether we can remove CertificateType entirely for TLS 1.3 though (that can be done separately).

The second is worrisome.  I don't like that a handshake message now has two different potential locations that it might appear in.  That seems like a hazard.  I think that we need a new content type for a new message that can be used after the handshake completes.  Then there are two options:
 a) remove CertificateRequest from the handshake entirely and allow the handshake to complete before authenticating (this has a number of hazards that make it probably worse than the duplication it addresses)
 b) use CertificateRequest within the handshake, and the new content type outside of it

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Sep 2015 14:37:35 -0700

This sounds like a good idea.  I certainly like how it eliminates a
number of variations (particularly the one that #209 added).  It
enables unilateral client authentication, which is a big plus.

My biggest concern would be the one you note and how this interacts
with the session transcript.  It seems OK to me, but I'd like Hugo or
Karthik to spend a few cycles thinking about that one before I'm
confident there isn't an actual problem.

How many Certificate+CertificateVerify messages would a client be
permitted to send.  1? N?  (I think 1)

If the answer to the above is N, does the client's
Certificate+CertificateVerify somehow identify the CertificateRequest?
 That is, how does the server identify whether this is unilateral or
in response to its own request?

How does a client determine if the NewSessionTicket that it receives
includes its authentication? That is, how can a client know whether a
resumed session will need a certificate or not?  (I'm not sure about
this one, but the first thought that occurs is that the server could
include an indicator in the NewSessionTicket message.)

Does the session need to be rekeyed as a result of this new
information?  (I think not, though see above regarding analysis.)

Do we allow for application data between Certificate and
CertificateVerify? (I think not.)

Question: What value do you see in having a spontaneous
NewSessionTicket messages?  Is this just a case of not wanting to bind
it more formally to something that the client sends?  I worry that
we'll have cases where the session tickets encompass new states if we
permit that.

---

From: Andrei Popov <[email-masked]>
Date: Tue, 15 Sep 2015 22:03:20 +0000

> How many Certificate+CertificateVerify messages would a client be permitted to send.  1? N?

I don't see a good reason to restrict to 1, although in many cases it would probably suffice.

> That is, how does the server identify whether this is unilateral or in response to its own request?

The model I'm thinking of is where the server receives a request from the client, determines that the request requires authentication, then queries session state to see whether a suitable client credential is available.
If such client credential is not available, the server sends CertificateRequest. In this model, it does not matter whether the client volunteered a credential or responded to the server's request.

> How does a client determine if the NewSessionTicket that it receives includes its authentication? That is, how can a client know whether a resumed session will need a certificate or not?  (I'm not sure about this one, but the first thought that occurs is that the server could include an indicator in the NewSessionTicket message.)

I'd say the client should send the latest ticket it has, assume that it has all session context including client identity, and the server will request creds if this is not the case.

> Does the session need to be rekeyed as a result of this new information?  (I think not, though see above regarding analysis.)

Agree on both points: the need for rekey is not obvious; until proved otherwise, I'm assuming no rekey.

> Do we allow for application data between Certificate and CertificateVerify? (I think not.)

No application data between Certificate and CertificateVerify.

> What value do you see in having a spontaneous NewSessionTicket messages?  Is this just a case of not wanting to bind it more formally to something that the client sends?  

The reason I want to allow NewSessionTicket messages in mid-stream is to allow the server to include newly obtained client creds in the session state. If the server wants to do this, it can send NewSessionTicket after processing the client's CertificateVerify.

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Tuesday, September 15, 2015 2:38 PM
To: Andrei Popov <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] Review of PR #209

This sounds like a good idea.  I certainly like how it eliminates a number of variations (particularly the one that #209 added).  It enables unilateral client authentication, which is a big plus.

My biggest concern would be the one you note and how this interacts with the session transcript.  It seems OK to me, but I'd like Hugo or Karthik to spend a few cycles thinking about that one before I'm confident there isn't an actual problem.

How many Certificate+CertificateVerify messages would a client be permitted to send.  1? N?  (I think 1)

If the answer to the above is N, does the client's
Certificate+CertificateVerify somehow identify the CertificateRequest?
 That is, how does the server identify whether this is unilateral or in response to its own request?

How does a client determine if the NewSessionTicket that it receives includes its authentication? That is, how can a client know whether a resumed session will need a certificate or not?  (I'm not sure about this one, but the first thought that occurs is that the server could include an indicator in the NewSessionTicket message.)

Does the session need to be rekeyed as a result of this new information?  (I think not, though see above regarding analysis.)

Do we allow for application data between Certificate and CertificateVerify? (I think not.)

Question: What value do you see in having a spontaneous NewSessionTicket messages?  Is this just a case of not wanting to bind it more formally to something that the client sends?  I worry that we'll have cases where the session tickets encompass new states if we permit that.

On 15 September 2015 at 13:17, Andrei Popov <[email-masked]> wrote:
> Andrei proposes two changes in 
> https://github.com/tlswg/tls13-spec/pull/209
>
>  a) remove CertificateRequest from the handshake entirely and allow 
> the handshake to complete before authenticating (this has a number of 
> hazards that make it probably worse than the duplication it addresses)

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Sep 2015 15:25:59 -0700

> If such client credential is not available, the server sends CertificateRequest. In this model, it does not matter whether the client volunteered a credential or responded to the server's request.

I'm concerned that this produces an indeterminate state on the server.
Say that the server receives a Certificate after it sends
CertificateRequest.  What if that Certificate doesn't conform to the
request in some way: was the Certificate just a unilateral offer that
was sent before the client received the CertificateRequest, is the
client unable to understand the CertificateRequest, or is the client
in error?  Depending on which of these is really the case, the server
is unable to decide whether it should continue awaiting a Certificate
or not.

It's not a huge issue, but I'd be happier if we nailed this sort of thing down.

> I'd say the client should send the latest ticket it has, assume that it has all session context including client identity, and the server will request creds if this is not the case.

That doesn't work for clients that send credentials without prompting.

> The reason I want to allow NewSessionTicket messages in mid-stream is to allow the server to include newly obtained client creds in the session state. If the server wants to do this, it can send Ne…

Would you be OK with saying that NewSessionTicket can only be sent in
response to CertificateVerify or Finished?

---

From: Andrei Popov <[email-masked]>
Date: Tue, 15 Sep 2015 23:19:41 +0000

> What if that Certificate doesn't conform to the request in some way: was the Certificate just a unilateral offer that was sent before the client received the CertificateRequest, is the client unable to understand the CertificateRequest, or is the client in error?

Traditionally, it was not an error for the client to send an empty Certificate message, or to offer a credential that does not match the parameters in the CertificateRequest. From the server's perspective, it doesn't matter what went wrong: the server treats the client as unauthenticated in this case (and possibly alerts/disconnects).

Because we want to allow the client to volunteer a certificate, there can be a situation where the server sends a CertificateRequest and receives an unsolicited client cert before the client can respond to CertificateRequest. We can add a flag to the client Certificate message to distinguish unsolicited creds from requested ones. Would this address the concern?

> That doesn't work for clients that send credentials without prompting.

Not sure what you mean, can you elaborate on the scenario?

> Would you be OK with saying that NewSessionTicket can only be sent in response to CertificateVerify or Finished?

Absolutely.

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Tuesday, September 15, 2015 3:26 PM
To: Andrei Popov <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] Review of PR #209

I'm concerned that this produces an indeterminate state on the server.
Say that the server receives a Certificate after it sends CertificateRequest.  What if that Certificate doesn't conform to the request in some way: was the Certificate just a unilateral offer that was sent before the client received the CertificateRequest, is the client unable to understand the CertificateRequest, or is the client in error?  Depending on which of these is really the case, the server is unable to decide whether it should continue awaiting a Certificate or not.

> The reason I want to allow NewSessionTicket messages in mid-stream is to allow the server to include newly obtained client creds in the session state. If the server wants to do this, it can send Ne…

Would you be OK with saying that NewSessionTicket can only be sent in response to CertificateVerify or Finished?

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Sep 2015 16:53:10 -0700

> Traditionally, it was not an error for the client to send an empty Certificate message, or to offer a credential that does not match the parameters in the CertificateRequest. From the server's pers…

Right, but not all applications work on that model.  Some make the
request and block on a response.

> Because we want to allow the client to volunteer a certificate, there can be a situation where the server sends a CertificateRequest and receives an unsolicited client cert before the client can re…

That would work.

> Not sure what you mean, can you elaborate on the scenario?

Client connects to server and completes the handshake.
Client sends certificate immediately after Finished.
Server sends NewSessionTicket after seeing Finished or
CertificateVerify; client is unable to tell which.
Later, Client resumes using the ticket.

The client is now uncertain about whether the server has remembered
their certificate.  That's bad if there are actions that might be
denied to the client in the absence of the certificate.

You could say that the easiest remedy is to offer the certificate
again, because that removes the uncertainty.  But a major reason for
having resumption is to avoid the public key operations on both peers,
so that's not a great solution.

This isn't a problem with TLS <=1.2, because there is no client
authentication without prompting, but that doesn't mean that someone
couldn't build a system that offers different content in response to
client authentication AND that system could have TLS 1.3 clients
authenticate without prompting in order to get that different content.
After all, asking has consequences that you might want to avoid, like
the "pick a certificate" dialog in browsers.  (Maybe you only need
this behavior for bespoke clients.)

---

From: Andrei Popov <[email-masked]>
Date: Wed, 16 Sep 2015 00:42:09 +0000

> The client is now uncertain about whether the server has remembered their certificate.  That's bad if there are actions that might be denied to the client in the absence of the certificate.

But the server will send a CertificateRequest in this case and the client will have a chance to authenticate. 

> You could say that the easiest remedy is to offer the certificate again, because that removes the uncertainty.  But a major reason for having resumption is to avoid the public key operations on both peers, so that's not a great solution.

That's why instead I say the client should send the ticket and if it turns out insufficient, the client will get a CertificateRequest :).

> ... but that doesn't mean that someone couldn't build a system that offers different content in response to client authentication AND that system could have TLS 1.3 clients authenticate without prompting in order to get that different content.

This is a new use case; with PR #209 I'm mostly trying to support existing use-cases. But if you want to enable this new scenario, we can consider something like this:
- CertificateRequest can include a random ID;
- Client Certificate and CertificateVerify would either echo the ID from a CertificateRequest, or use a new random ID if it's unsolicited;
- NewSessionTicket would use an ID matching the client Certificate/CertificateVerify.

This also solves the unsolicited vs. requested client Certificate issue we talked about earlier. This of course introduces a bit of extra complexity.

> After all, asking has consequences that you might want to avoid, like the "pick a certificate" dialog in browsers.  (Maybe you only need this behavior for bespoke clients.)

I'm not sure about this.

"Pick a certificate" dialog means that the client:
a) Does not know whether the user wants to send a credential to a server;
b) Does not know which of the multiple available credentials to send to the server.

If you have a system where the client app knows that a certificate is required, and knows the specific certificate to send, there is no need for the dialog. Such a system is ready to respond to a CertificateRequest (without showing the dialog), or it could send the certificate unsolicited. I think that uncertainty, not CertificateRequest, is the reason for the dialog.

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Tuesday, September 15, 2015 4:53 PM
To: Andrei Popov <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] Review of PR #209

> Traditionally, it was not an error for the client to send an empty Certificate message, or to offer a credential that does not match the parameters in the CertificateRequest. From the server's pers…

Right, but not all applications work on that model.  Some make the request and block on a response.

That would work.

Client connects to server and completes the handshake.
Client sends certificate immediately after Finished.
Server sends NewSessionTicket after seeing Finished or CertificateVerify; client is unable to tell which.
Later, Client resumes using the ticket.

The client is now uncertain about whether the server has remembered their certificate.  That's bad if there are actions that might be denied to the client in the absence of the certificate.

You could say that the easiest remedy is to offer the certificate again, because that removes the uncertainty.  But a major reason for having resumption is to avoid the public key operations on both peers, so that's not a great solution.

This isn't a problem with TLS <=1.2, because there is no client authentication without prompting, but that doesn't mean that someone couldn't build a system that offers different content in response to client authentication AND that system could have TLS 1.3 clients authenticate without prompting in order to get that different content.
After all, asking has consequences that you might want to avoid, like the "pick a certificate" dialog in browsers.  (Maybe you only need this behavior for bespoke clients.)

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 16 Sep 2015 18:30:41 +0300

> Perhaps we can simplify the protocol by pulling client auth out of the

Problem with pulling client auth out of the handshake is that it
complicates applications that can't change identities involved with
active connection.

And applications that can't take dynamic identites may still be
able to take static identities.

As then the application needs to ensure that the authentication
occurs between TLS handshake and actually starting up the protocol.

> 2. The client can send Certificate and CertificateVerify at any
> time application data is permitted, regardless of whether the
> server had previously sent CertificateRequest.

CertificateRequest contains the permitted signature algorithms
for the PoP signature, which TLS library needs to verify before
dumping the certificate chain on application (which can then
figure out things like trust anchors).

Without CertificateRequest, one has little idea what algorithms
are acceptable there.

> 3. The server can send CertificateRequest and NewSessionTicket at any
> time application data is permitted. Alternatively, the server can
> encapsulate CertificateRequest in an application protocol message.

If done with protocols that can't support dynamic authentication
properly, doing that tends not show up as things visibly breaking,
it tends to show up as subtle security holes.

Also, that doesn't properly bind NST with state is for (as already
noted), possibly causing screwy behaviour if TLS resumption is
attempted (client and server not agreeing on client identity, which
actually breaks definition of secure key exchange outright).

> Encapsulating CertificateRequest in an application protocol message
> allows the client to determine which specific application request
> resulted in the need for client auth.

The application protocols that would indicate this seem to be pretty
much the ones where dynamic authentication is unsafe.

Basically, one must clear the pipeline before changing identities,
and with protocols like HTTP/2, this is extremely expensive (seemingly
even more expensive than establishing a new connecion).

> We can decide exactly what CertificateVerify would be signing:
> whether it's the handshake hash or some form of RFC5705 Exported
> Keying Material (EKM).

Also, it should sign the certificate, to avoid possible weirdness
due to signatures not properly binding the key (some schemes do,
most don't).

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Wed, 16 Sep 2015 10:30:30 -0700

> That's why instead I say the client should send the ticket and if it turns out insufficient, the client will get a CertificateRequest :).

I'm not sure about this.  Some servers are built with the expectation
that clients who need to authenticate have done so.  After all, not
all CertificateRequests result in Certificates being sent (i.e., some
are empty).

---

From: Martin Thomson <[email-masked]>
Date: Wed, 16 Sep 2015 10:48:27 -0700

> complicates applications that can't change identities involved with

Why would that be unsupported here?  The server can still send
CertificateRequest immediately after its Finished.  That looks exactly
like it does today, only the order has changed.

> occurs between TLS handshake and actually starting up the protocol.

I'm not sure that is necessarily a problem.  If the claim is that the
authentication attests to everything prior to its appearance, then you
have no problem.  I think that claim is reasonable, but I'm happy to
discuss it.

> Without CertificateRequest, one has little idea what algorithms

Arguably, signature_algorithms covers that adequately.  Though I'll
grant that certificate chain validation often happens in a separate
component to the TLS stuff.

> even more expensive than establishing a new connecion).

There's been some confusion about this with HTTP/2.  I think that if
you adopt the position that authentication applies to the entire
session - even retroactively - then the only remaining concern is the
correlation one.  If you have three tabs to the site open where all of
them are making requests and you see a certificate request, which one
do you pop the dialog on?

> due to signatures not properly binding the key (some schemes do,

I agree with this.

---

From: Andrei Popov <[email-masked]>
Date: Wed, 16 Sep 2015 18:11:06 +0000

Martin's point makes sense to me: applications that need to do authentication upfront can still do that immediately after the handshake.

Cheers,

Andrei

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Wednesday, September 16, 2015 10:48 AM
To: Ilari Liusvaara <[email-masked]>
Cc: Andrei Popov <[email-masked]>; [email-masked]
Subject: Re: [TLS] Review of PR #209

> complicates applications that can't change identities involved with 

Why would that be unsupported here?  The server can still send CertificateRequest immediately after its Finished.  That looks exactly like it does today, only the order has changed.

> As then the application needs to ensure that the authentication occurs 
> between TLS handshake and actually starting up the protocol.

I'm not sure that is necessarily a problem.  If the claim is that the authentication attests to everything prior to its appearance, then you have no problem.  I think that claim is reasonable, but I'm happy to discuss it.

>> 2. The client can send Certificate and CertificateVerify at any time 
>> application data is permitted, regardless of whether the server had 
>> previously sent CertificateRequest.
>
> CertificateRequest contains the permitted signature algorithms for the 
> PoP signature, which TLS library needs to verify before dumping the 
> certificate chain on application (which can then figure out things 
> like trust anchors).
>
> Without CertificateRequest, one has little idea what algorithms are 
> acceptable there.

Arguably, signature_algorithms covers that adequately.  Though I'll grant that certificate chain validation often happens in a separate component to the TLS stuff.

> Basically, one must clear the pipeline before changing identities, and 
> with protocols like HTTP/2, this is extremely expensive (seemingly 

There's been some confusion about this with HTTP/2.  I think that if you adopt the position that authentication applies to the entire session - even retroactively - then the only remaining concern is the correlation one.  If you have three tabs to the site open where all of them are making requests and you see a certificate request, which one do you pop the dialog on?

> Also, it should sign the certificate, to avoid possible weirdness due 
> to signatures not properly binding the key (some schemes do, most 
> don't).

I agree with this.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 16 Sep 2015 11:18:01 -0700

I think the potential issue here is needing a way for the server to tell the
client "don't bother sending me data until you've authenticated" (though,
as MT says, you could argue that the client's signature retroactively
authenticates, which does seem like the simplest way to think about things).

One might imagine dealing with that by a simple signal in a ServerHello
extension that said "authentication will be required, sit tight..."

-Ekr

On Wed, Sep 16, 2015 at 11:11 AM, Andrei Popov <[email-masked]>
wrote:

> Martin's point makes sense to me: applications that need to do
> authentication upfront can still do that immediately after the handshake.
>
> Cheers,
>
> Andrei
>
> CertificateRequest immediately after its Finished.  That looks exactly like
> it does today, only the order has changed.
>
> authentication attests to everything prior to its appearance, then you have
> no problem.  I think that claim is reasonable, but I'm happy to discuss it.
>
> Arguably, signature_algorithms covers that adequately.  Though I'll grant
> that certificate chain validation often happens in a separate component to
> the TLS stuff.
>
> There's been some confusion about this with HTTP/2.  I think that if you
> adopt the position that authentication applies to the entire session - even
> retroactively - then the only remaining concern is the correlation one.  If
> you have three tabs to the site open where all of them are making requests
> and you see a certificate request, which one do you pop the dialog on?
>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 16 Sep 2015 11:20:02 -0700

I should add: I do think this general line of consolidating all the client
auth modes is a good idea, assuming we can work out the details.

-Ekr

On Wed, Sep 16, 2015 at 11:18 AM, Eric Rescorla <[email-masked]> wrote:

> On Wed, Sep 16, 2015 at 11:11 AM, Andrei Popov <[email-masked]
> > wrote:
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 16 Sep 2015 21:25:00 +0300

> have no problem.  I think that claim is reasonable, but I'm happy to

I think it is the attesting (even of present in-flight requests)
that is the problem, not not attesting something.

> component to the TLS stuff.

The extension? IIRC, that is what _client_ can verify. This is about
what _server_ can verify. 

Or the equivalent of current field that specifies that? That's inside
CertificateRequest, which would be optional.

-Ilari

---

From: Andrei Popov <[email-masked]>
Date: Wed, 16 Sep 2015 19:28:00 +0000

> The extension? IIRC, that is what _client_ can verify. This is about what _server_ can verify. 

> Or the equivalent of current field that specifies that? That's inside CertificateRequest, which would be optional.

I don't necessarily buy Martin's argument that signature_algorithms covers this adequately.

But I would argue that the application will only volunteer certs if it has out-of-band knowledge that client auth is required, and also knows exactly which cert is required. Otherwise, CertificateRequest should be used.

Cheers,

Andrei

-----Original Message-----
From: Ilari Liusvaara [mailto:[email-masked]] 
Sent: Wednesday, September 16, 2015 11:25 AM
To: Martin Thomson <[email-masked]>
Cc: Andrei Popov <[email-masked]>; [email-masked]
Subject: Re: [TLS] Review of PR #209

> have no problem.  I think that claim is reasonable, but I'm happy to 

I think it is the attesting (even of present in-flight requests) that is the problem, not not attesting something.

> > CertificateRequest contains the permitted signature algorithms for 
> > the PoP signature, which TLS library needs to verify before dumping 
> > the certificate chain on application (which can then figure out 
> > things like trust anchors).
> >

The extension? IIRC, that is what _client_ can verify. This is about what _server_ can verify. 

Or the equivalent of current field that specifies that? That's inside CertificateRequest, which would be optional.

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Wed, 16 Sep 2015 12:57:57 -0700

> But I would argue that the application will only volunteer certs if it has out-of-band knowledge that client auth is required, and also knows exactly which cert is required. Otherwise, CertificateR…

I'm OK with that.  We might expect that CertificateRequest has been
sent by some other means than TLS in those cases.

(I don't necessarily think that signature_algorithms is sufficient,
just that it might be in some cases.)

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sat, 19 Sep 2015 16:14:28 -0400

> have no problem.  I think that claim is reasonable, but I'm happy to

I think this claim sounds confusing, for (at least) two reasons:

 (a) it interacts oddly with the possibility of > 1 CertificateVerify
     message -- does it imply that all messages in a TLS session
     (past and present) are attested to by every client certificate ever
     sent in the session?

 (b) it has unclear semantics around session resumption.  If i resume a
     session and send a ClientCert+CertificateVerify, am i retroactively
     attesting to all the communications from the previous session(s)?
     What does that even mean to the server which has already processed
     the traffic from previous sessions?

Can we communicate these semantics to application developers who might
have an "accelerating" TLS session cache available, or who might share a
session cache between systems?  Can we help clients make sense of the
implications of retroactive attestation when confronted with a
certificateRequest?

        --dkg

---

From: Martin Thomson <[email-masked]>
Date: Sun, 20 Sep 2015 17:56:12 -0700

>      (past and present) are attested to by every client certificate ever

I think that it would have to.  Though I personally think that 1 is
plenty, if there are more and the attestation is retroactive, then it
naturally applies to all of them.

>      the traffic from previous sessions?

I think that could make an argument for attesting to all previous
communications, but it would be easiest to say that it only applies to
the current session.

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Mon, 21 Sep 2015 07:38:45 +0200

As dkg points out, dynamically authenticating clients later in the connection brings up
API issues of how to notify the application about the scope of this new authentication event.

I think it is inevitable that implementation will store the client credential in the session, and
that the new (authenticated) stream of data will be concatenated to the older (unauthenticated) stream.
Both of these design choices will lead to the following answers to dkg’s questions:
(a) all messages in TLS sessions (past and present) will be attested to by every certificate
(b) all traffic in earlier and future resumed sessions will be attested to by every certificate

In other words, if we do allow this change to client authentication, to be safe, we must analyze the
resulting protocol *as if* applications will use the authentication event to attest to all
data, past and present, that may be associated with the data in the current connection.

-K.

> On 19 Sep 2015, at 22:14, Daniel Kahn Gillmor <[email-masked]> wrote:
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 21 Sep 2015 17:02:35 +0300

On Mon, Sep 21, 2015 at 07:38:45AM +0200, Karthikeyan Bhargavan wrote:
> 
> In other words, if we do allow this change to client authentication,
> to be safe, we must analyze the resulting protocol *as if*
> applications will use the authentication event to attest to all data,
> past and present, that may be associated with the data in the current
> connection.

Under such assumption, even dynamic reauth in HTTP/1.1 is unsafe. If
one additionally assumes causality, dynamic reauth in non-pipelined
HTTP/1.1 may be safe, but dynamic reauth in HTTP/2 (or HTTP/1.1 with
pipelining) is still unsafe.

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Mon, 21 Sep 2015 07:22:22 -0700

> pipelining) is still unsafe.

What do you mean when you say "safe" and "unsafe" here?

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 21 Sep 2015 07:22:34 -0700

> data, past and present, that may be associated with the data in the current connection.

But this combination is pretty weird for servers to deal with.  For
example:

Consider a server has an ongoing session wrapped in TLS that uses client
authentication to approve or deny some requests from the client.  It
remembers what requests the client has made as some sort of relevant
state.  Let's take an imap server working with a client that has state
of a "currently-examined folder", but this applies to servers and
clients with much more complex state as well.

The client is currently examining folder Y.

Some client identities *do not* have authorization to visit folder X.
others do.

The client requests a change to folder X.

The server rejects the change.

The client subsequently authenticates to an identity that is authorized
to access folder X.

What is the currently-examined folder for this session?

The "easy" (and right) answer here is "folder Y, of course" -- but
telling peers that the authentication should apply retroactively to all
previous data sent suggests that maybe it should be folder X.

This is confusing.  Confusing semantics are bound to lead to problematic
implementations and usage :(

Sorry that this mail doesn't have a better suggestion to offer.

     --dkg

---

From: Geoffrey Keating <[email-masked]>
Date: 21 Sep 2015 17:40:02 -0700

> clients with much more complex state as well.
...

I think for such a protocol, you'd want to say that authentication is
not retroactive.

For other protocols, you might want something else.  For example, in a
protocol which uses client authentication for billing, you might want
to treat an authentication half-way through the session as the account
to bill for the entire session.

Some protocols will also want to support multiple identities, and some
will not.  For some protocols a new authentication might want to in
some fashion dis-trust previous authentications, other protocols might
say that all previous authentications are valid until the end of the
session.

I think this is something that TLS should allow higher-level protocols
to specify.  The TLS model could be that each client authentication
happens at a particular point in the session, breaking it up into
segments, and TLS informs the higher-level protocols of where the
segments start and end; it's up to the higher-level protocol to work
out what that means.

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 22 Sep 2015 14:09:47 +0100

> On 22 Sep 2015, at 01:40, Geoffrey Keating <[email-masked]> wrote:
> 

If I get this right: 
1) it will be possible on the same connection to authenticate
with multiple different certificates,
2) the different identities won't ( necessarily ? ) be cumulative
ie, a server getting the identity I1 and then I2 on the same TLS connection
won't be able to conclude that the referent of I1 is the same as the referent 
of  I2 ?

Thinking of a possible use of this over HTTP I find this surprising. So perhaps
it is not meant to be applied there. Where is it?

If that were to work correctly would one not also have to change the encryption
for each user?

(sorry to enter the discussion but I am also just checking because I 
seem to have made a mistaken claim on the HTTP list if 1) is true )

> segments start and end; it's up to the higher-level protocol to work

Social Web Architect
http://bblfish.net/

---

From: Andrei Popov <[email-masked]>
Date: Tue, 22 Sep 2015 15:09:10 +0000

Hi Henry,

> 1) it will be possible on the same connection to authenticate with multiple different certificates,
With the current proposal as it stands, yes.

> 2) the different identities won't ( necessarily ? ) be cumulative ie, a server getting the identity I1 and then I2 on the same TLS connection won't be able to conclude that the referent of I1 is the same as the referent of  I2 ?
I believe the server can conclude this; the caveat is that in practice a server can only support a limited number of client identities simultaneously.

> Thinking of a possible use of this over HTTP I find this surprising. So perhaps it is not meant to be applied there. Where is it?
Indeed there's a surprising number of sites that have a landing page accessible without client auth, but require client auth when a protected resource is accessed. This is currently done via renegotiation; in TLS1.3 we're looking for a way to accommodate such sites.

> If that were to work correctly would one not also have to change the encryption for each user?
So far we don't know that one has to change the encryption keys after each client authentication, but this is still under discussion.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, September 22, 2015 6:10 AM
To: [email-masked]
Subject: Re: [TLS] Review of PR #209

>> Consider a server has an ongoing session wrapped in TLS that uses 
>> client authentication to approve or deny some requests from the 
>> client.  It remembers what requests the client has made as some sort 
>> of relevant state.  Let's take an imap server working with a client 
>> that has state of a "currently-examined folder", but this applies to 
>> servers and clients with much more complex state as well.
> ...
> 

If I get this right: 
1) it will be possible on the same connection to authenticate with multiple different certificates,
2) the different identities won't ( necessarily ? ) be cumulative ie, a server getting the identity I1 and then I2 on the same TLS connection won't be able to conclude that the referent of I1 is the same as the referent of  I2 ?

Thinking of a possible use of this over HTTP I find this surprising. So perhaps it is not meant to be applied there. Where is it?

If that were to work correctly would one not also have to change the encryption for each user?

(sorry to enter the discussion but I am also just checking because I seem to have made a mistaken claim on the HTTP list if 1) is true )

Social Web Architect
http://bblfish.net/

---

From: Geoffrey Keating <[email-masked]>
Date: 22 Sep 2015 10:27:43 -0700

> with multiple different certificates,

I think this is still under discussion.  In the most recent draft, no,
but in that draft you can only send a client certificate before
sending application data.  However a possibility under discussion is
that you could send a client certificate at any point in the stream.

> ie, a server getting the identity I1 and then I2 on the same TLS
> connection won't be able to conclude that the referent of I1 is the
> same as the referent of I2 ?

IMO, this is outside the scope of TLS, a higher-layer protocol will
have to determine what it means.  TLS need only report 'you got a client
certificate here and another client certificate here'.

> encryption for each user?

No.  Even if the client private key is possessed by an untrusted
entity, all that needs to be revealed to that entity to perform the
signature is the current value of the handshake hash.

---

From: Henry Story <[email-masked]>
Date: Tue, 22 Sep 2015 13:22:15 +0100

If I get this right: