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
Description: PGP signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls