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

[Andrei Popov <[e-mail]>]

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:[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