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

[David Benjamin <[e-mail]>]

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 <[e-mail]> wrote:

> On Fri, Jul 24, 2015 at 1:02 AM Andrei Popov <[e-mail]>
> wrote:
>
>> 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).
>>
>
> 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.)
>
>
>> > - 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.
>> 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).
>>
>
> 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.)
>
> > - The certificate_types field in CertificateRequest is pretty much
>>   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).
>>
>> > - How does extension_values work? If multiple values for one
>>   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:[e-mail]] On Behalf Of Ilari Liusvaara
>> Sent: Monday, July 20, 2015 4:11 PM
>> To: [e-mail]
>> Subject: [TLS] Commentary on the client authentication presentation slides
>>
>> 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
>>
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>>
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>>
>