Subject: [TLS] Commentary on the client authentication presentation slides

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 20 Jul 2015 17:10:36 +0300

Some commentary on client authentication slides (there is no linked draft
nor other material yet).

- Mechanism like proposed looks dangerous when combined with HTTP/2.
  Multiplexed protocols are in general not safe to authenticate without
  application-layer signaling (which can be implicit via separate
  connections), especially if dealing with something like web
  environment.
- Regarding last point about interleaving: Assuming the scheme works
  in 1RTT (and I see no reason for requiring more rounds), you can't
  prevent application_data transmission after certificate_request.
  The best that can be done is to require the client to send all
  the authentication-related data in one go.
- The certificate_types field in CertificateRequest is pretty much
  useless, since all supported algorithms are of signature type.
- One can't just remove fields without breaking parse compatiblity,
  but adding field breaks parse compatiblity too, so removing
  field at the same time isn't a problem.
- How does extension_values work? If multiple values for one
  OID are allowed, then the OID/value pair is repeated, once for
  each value?

-Ilari

---

From: Andrei Popov <[email-masked]>
Date: Fri, 24 Jul 2015 05:01:37 +0000

Thanks for the detailed comments, Ilari.

Based on the discussion at the TLS WG meeting, I created a pull request: https://github.com/tlswg/tls13-spec/pull/209

> - Mechanism like proposed looks dangerous when combined with HTTP/2.
I believe the same issue already exists in HTTP/1 where multiple requests can be in flight at the same time.
The way we handle this in HTTP/1 is by having the server application query the HTTP stack for the client cred.
If there's no cred available, the HTTP stack triggers client authentication (and the server application waits until the client cred is provided so it can authorize the request).

  in 1RTT (and I see no reason for requiring more rounds), you can't
  prevent application_data transmission after certificate_request.
We discussed at the meeting that this restriction cannot be implemented.
Instead, a server may block the processing of any in-flight requests while waiting for the client to authenticate (if the server's architecture requires this).

  useless, since all supported algorithms are of signature type.
If the signature_algorithms extension officially becomes MTI, then perhaps we can discus getting rid of certificate_types in the CertificateRequest. Except we may want to use this field when we introduce new certificate types (e.g. something like IEEE1609 certs).

  OID are allowed, then the OID/value pair is repeated, once for
  each value?
Multiple values are DER-encoded per RFC that defines the OID that allows multiple values.
The idea here is to simply reuse the existing OID-parsing code. A TLS implementation (or certificate API) that recognizes the OID in the cert, already knows how to parse its representation. A TLS implementation (or certificate API) that does not recognize the OID in the cert will also skip this OID in the extension_values. In the degenerate case, an implementation may choose to skip all extension_values.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Ilari Liusvaara
Sent: Monday, July 20, 2015 4:11 PM
To: [email-masked]
Subject: [TLS] Commentary on the client authentication presentation slides

Some commentary on client authentication slides (there is no linked draft nor other material yet).

-Ilari

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

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 24 Jul 2015 09:32:36 +0300

On Fri, Jul 24, 2015 at 05:01:37AM +0000, Andrei Popov wrote:
> If the signature_algorithms extension officially becomes MTI, then
> perhaps we can discus getting rid of certificate_types in the
> CertificateRequest. Except we may want to use this field when we
> introduce new certificate types (e.g. something like IEEE1609 certs).

Don't confuse signature_algorithms extension and
supported_signature_algorithms field of CertificateRequest. Those two
carry similar tasks in opposite directions, except that ssa is REQUIRED
with signature certs.

There are seemingly no defaults for SSA, so it has to be non-empty
for signature certs to work at all.

And all present types of TLS 1.3 key exchange can only use signature
certs.

As for IEEE1609 certs, those are negotiated via certificate format
negotiation, which is entierely separate mechanism (described in
RFC 7250), not involving CertificateRequest message at all.

-Ilari

---

From: Andrei Popov <[email-masked]>
Date: Fri, 24 Jul 2015 06:42:19 +0000

Sound good to me; if the group agrees to remove certificate_types, I'll make this change in the PR.

-----Original Message-----
From: Ilari Liusvaara [mailto:[email-masked]] 
Sent: Friday, July 24, 2015 8:33 AM
To: Andrei Popov
Cc: [email-masked]
Subject: Re: [TLS] Commentary on the client authentication presentation slides

> introduce new certificate types (e.g. something like IEEE1609 certs).

Don't confuse signature_algorithms extension and supported_signature_algorithms field of CertificateRequest. Those two carry similar tasks in opposite directions, except that ssa is REQUIRED with signature certs.

There are seemingly no defaults for SSA, so it has to be non-empty for signature certs to work at all.

And all present types of TLS 1.3 key exchange can only use signature certs.

As for IEEE1609 certs, those are negotiated via certificate format negotiation, which is entierely separate mechanism (described in RFC 7250), not involving CertificateRequest message at all.

-Ilari

---

From: David Benjamin <[email-masked]>
Date: Tue, 28 Jul 2015 22:30:14 +0000

Sent from the right email this time. (Sorry folks who got it twice. One of
these days I'll not mess this up! :-) )

On Tue, Jul 28, 2015 at 6:28 PM David Benjamin <[email-masked]> wrote:

> On Fri, Jul 24, 2015 at 1:02 AM Andrei Popov <[email-masked]>
> wrote:
>
>> Based on the discussion at the TLS WG meeting, I created a pull request:
>> https://github.com/tlswg/tls13-spec/pull/209
>>
>> The way we handle this in HTTP/1 is by having the server application
>> query the HTTP stack for the client cred.
>> If there's no cred available, the HTTP stack triggers client
>> authentication (and the server application waits until the client cred is
>> provided so it can authorize the request).
>>
>
> The issue only exists in HTTP/1 if the client does pipelining. As far as I
> know, no current[*] major browser deploys HTTP pipelining by default.
> Chrome certainly doesn't.
>
> [*] Wikipedia says Opera used to do it before they switched to Chromium?
>
> Are you intending that this mechanism be enabled by default for HTTP/2 or
> would the prohibition against renego still apply? Without any way for the
> client to tie the CertificateRequest to the HTTP request that triggered it,
> this mechanism would have many of the same problems as renego as far as
> HTTP/2 is concerned. (I realize Microsoft has a draft floating around for a
> TLS_RENEG_PERMITTED HTTP/2 setting. The setting can control this too I
> suppose.)
>
>
>> Instead, a server may block the processing of any in-flight requests
>> while waiting for the client to authenticate (if the server's architecture
>> requires this).
>>
>
> This requires the server buffer arbitrarily many requests from the client,
> which seems poor. For renego-based mid-stream auth, I believe Apache httpd
> does not do this and will actually fail the connection on interleave. (But
> I've never tested this, just glanced at how they use OpenSSL, so I could be
> wrong.)
>
>> CertificateRequest. Except we may want to use this field when we introduce
>> new certificate types (e.g. something like IEEE1609 certs).
>>
>> The idea here is to simply reuse the existing OID-parsing code. A TLS
>> implementation (or certificate API) that recognizes the OID in the cert,
>> already knows how to parse its representation. A TLS implementation (or
>> certificate API) that does not recognize the OID in the cert will also skip
>> this OID in the extension_values. In the degenerate case, an implementation
>> may choose to skip all extension_values.
>>
>> Cheers,
>>
>> Andrei
>>