On Tue 2016-10-11 13:26:02 -0400, Nick Sullivan wrote: > The major thing that this proposal achieves is that it makes post-handshake > auth an optional part of the implementation. Instead of this, I would also > be in favor of a simpler change that modifies the text to say that > post-handshake CertificateRequest messages are fatal by default and only > permitted if the application permits their use in a given context (say if > the application is HTTP 1.1, only directly after requests). > > Embedded implementations may choose to simply fail on unexpected > CertificateRequests, and that way not have to implement any code around > post-handshake finished messages or updating the transcript when one > arrives. > > This default wording should also apply to other types of post-handshake > messages, though NST and KU could be exceptions that should always be > supported and non-fatal.
I don't see the advantage of putting this on the wire during the intial
handshake.
In the HTTP case, either (a) the requested resource wants a new
authentication or (b) it does not. If it does not want new
authentication (b), no CertificateRequest message will be forthcoming.
If it does want new authentication, then either (a.1) it requires it
(meaning the HTTP request will fail if the client can't offer a good
cert), or (a.2) it just hopes to send a different response based on some
new authentication. in (a.1), the request will simply fail when the
client can't send a client cert. So the the client needs to know how to
at least reject it gracefully. This is the case even when the client
fully implements client auth anyway, since it might not have a client
cert available.
I don't think it's too much to ask that implementations be able to
reject a post-handshake CertificateRequest gracefully, even if they have
no intention of ever implementing a proper Client Certificate response.
Changes to the wire format here only seems to give a small advantage to
the server in one corner case for HTTP (a.2, when the client has no
implementation of post-handshake client certs): the server can
confidently send the certRequest, knowing that the client will know how
to deal with it. But now clients will also need to decide whether they
should indicate "i do post-handshake client auth" even if they have no
likely client certs available at the time of session establishment, and
to keep track of how they signaled over the lifetime of the session (how
does this interact with session resumption?). I don't think that's a
complexity win overall.
If we make it clear that TLS 1.3 clients MUST at least know how to
gracefully reject a post-handshake Certificate Request, i think that
leaves the ecosystem as a whole with less complexity, and reduces the
fiddliness of the wire format.
--dkg
signature.asc
Description: PGP signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
