[TLS] TLS 1.3 and OCSP stapling
When looking at stuff some more, I noticed that extension status_request_v2, which is used by OCSP stapling and is not deprecated [1]. Now, that extension uses additional handshake message type (certificate_status), which is specified to go between Certificate and SKE. Now, TLS 1.3 does not have SKE, and closest equivalent is server CertificateVerify. But OTOH, Cerficate/CertificateVerify/ Finished are supposed to form a block? Where it is supposed to go? Then there are other supported extensions that add messages. Specifically the following messages: - certificate_url: This can replace client certificate, whic is straightforward (if causing security issues by its sheer nature). - supplemental_data: There's ladder diagrams placing this just before Certificate. Where should this go in TLS 1.3 (there are undeprecated extensions that would use it)? [1] Unlike status_request, which is listed as deprecated. Was that intentional or mistake (if intentional, cert_type would also be a good to deprecate as superceded). -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Keyshare extension spec
I am looking at the specification of the key share extension, section 6.3.2.3 of the 1.3 draft. I think that the behavior is somewhat underspecified. The spec says: ...Clients MAY omit this extension from the ClientHello, and in response to this, servers MUST send a HelloRetryRequest requesting use of one of the groups the client offered support for in its "supported_groups" extension. If no common supported group is available, the server MUST produce a fatal "handshake_failure" alert. I am concerned with the hypothetical case in which the client sends a list of groups in the "named group" extension but only sends keys for a subset of these groups in the "key share" extension. For example, a client might propose secp256r1 and secp384r1 in the named group extension, leading the server to select secp256r1, but only provide a key for secp384r1 in the key share extension. The server has two options: * produce a fatal handshake failure alert, because no common supported group is available, * or, send a HelloRetryRequest requesting use of one of the groups the client offered support for, secp256r1 in the example. Which is the correct interpretation? Is one of these behaviors preferred, or are both available? Also, what is supposed to happen if the client sends an empty Key Share extension? Or, if its listed key share extensions list keys for groups that are not indicated in the "named group" extension? -- Christian Huitema ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Keyshare extension spec
On Friday, December 11, 2015 08:13:05 pm Christian Huitema wrote: > I am looking at the specification of the key share extension, section 6.3.2.3 > of the 1.3 draft. I think that the behavior is somewhat underspecified. The > spec says: > > ...Clients MAY omit this extension from the ClientHello, and in response to > this, servers MUST send a HelloRetryRequest requesting use of one of the > groups the client offered support for in its "supported_groups" extension. If > no common supported group is available, the server MUST produce a fatal > "handshake_failure" alert. There's some cruft in the current draft leftover from ekr and I waffling back/forth on whether to omit or send an empty extension when requesting server selection. (was pointed out on this list by someone else a couple weeks ago) We eventually decided on empty. I have a PR pending review that fixes the merge mistakes and clarifies some bits. https://github.com/tlswg/tls13-spec/pull/349/files > I am concerned with the hypothetical case in which the client sends a list of > groups in the "named group" extension but only sends keys for a subset of > these groups in the "key share" extension. For example, a client might > propose secp256r1 and secp384r1 in the named group extension, leading the > server to select secp256r1, but only provide a key for secp384r1 in the key > share extension. The server has two options: > > * produce a fatal handshake failure alert, because no common supported group > is available, > * or, send a HelloRetryRequest requesting use of one of the groups the client > offered support for, secp256r1 in the example. > > Which is the correct interpretation? Is one of these behaviors preferred, or > are both available? The latter: HelloRetryRequest is the required response. (See also the PR noted above.) The retry mechanism essentially allows key shares to be provided on-demand. Servers selecting a group that is supported, but not provided, request it via the HelloRetryRequest. > Also, what is supposed to happen if the client sends an empty Key Share > extension? With the pending changes this is the explicit HelloRetryRequest request case. Lack of the extension when offering suites requiring it a fatal "missing_extension" alert. (switching to supplying an empty extension when requesting a retry makes this simpler) > Or, if its listed key share extensions list keys for groups that are not > indicated in the "named group" extension? I have a "MUST NOT" for doing that in the pending PR. In order to be thorough, I've just amended it with a specific fatal alert to throw. Though other mechanisms should catch an attempt to inject a bogus key share, implementations not checking for and erroring on unsupported keys here sounds like a recipe for badness. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 and OCSP stapling
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. On 12 December 2015 at 05:52, Ilari Liusvaara wrote: > When looking at stuff some more, I noticed that extension > status_request_v2, which is used by OCSP stapling and is not deprecated > [1]. > > Now, that extension uses additional handshake message type > (certificate_status), which is specified to go between Certificate > and SKE. Now, TLS 1.3 does not have SKE, and closest equivalent is > server CertificateVerify. But OTOH, Cerficate/CertificateVerify/ > Finished are supposed to form a block? Where it is supposed to go? > > Then there are other supported extensions that add messages. > Specifically the following messages: > > - certificate_url: This can replace client certificate, whic is > straightforward (if causing security issues by its sheer nature). > - supplemental_data: There's ladder diagrams placing this just > before Certificate. Where should this go in TLS 1.3 (there are > undeprecated extensions that would use it)? > > > [1] Unlike status_request, which is listed as deprecated. Was > that intentional or mistake (if intentional, cert_type would also be a > good to deprecate as superceded). > > > -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
