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 <david...@google.com> wrote: > On Fri, Jul 24, 2015 at 1:02 AM Andrei Popov <andrei.po...@microsoft.com> > 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:tls-boun...@ietf.org] On Behalf Of Ilari Liusvaara >> Sent: Monday, July 20, 2015 4:11 PM >> To: tls@ietf.org >> 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 >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
