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). > - 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). > - 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
