On Mon, Dec 14, 2015 at 12:29:25PM +0000, Rob Stradling wrote: > On 12/12/15 15:02, Salz, Rich wrote: > >>I think that the best way to deal with the status_request_v2 extension is to > >>make it a proper part of the TLS 1.3 messages, probably Certificate or > >>CertificateVerify. This is a fairly heavily important extension. > > > >I'd be in favor of this. > > Wouldn't switching OCSP stapling from "extension" to "proper part of the TLS > 1.3 messages" mess things up for the TLS Feature certificate extension [1], > which can be used to tell a TLS client that it should expect to receive TLS > extension 5 (status_request) and/or TLS extension 17 (status_request_v2) > from the TLS server?
If one needed to, one could make up rules with regards to extension negotiation. Also, this is just the message, not the extension, so one probably does not have to. Rule that if status_request_v2 is missing, then status_request_v2 with single item with blank responder id list and blank extension is impiled would prbably go bit too far. Or that TLS 1.3 always implicitly ACKs status_request_v2[1]... TLS Extensions 5 (status_request) and 9 (cert_type) are a bit special, as both have essentially been superceded by other extensions that can perform everything those extensions can and more. Also, for some reason status_request is marked as deprecated in TLS 1.3 (status_request_v2 is still there). [1] Considering extended_master_secret always negotiatied in TLS 1.3 might be a good idea, for backward compatiblity with software that checks for EMS as check for "not vulernable to THS". -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
