Subject: [TLS] TLS 1.3 and OCSP stapling

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 11 Dec 2015 20:52:58 +0200

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

---

From: Martin Thomson <[email-masked]>
Date: Sat, 12 Dec 2015 15:54:36 +1100

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 <[email-masked]> wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 12 Dec 2015 12:45:58 +0200

> Certificate or CertificateVerify.  This is a fairly heavily important

If one wants to incorporate it, I would think Certificate for two
reasons:

- So CertificateVerify signs it without hacks. It is easier to analyze
  things if the only thing not covered are the signature and Finished.
- Because Certificate message is modifed anyway for authentication
  contexts (CertificateVerify is not sent if the client refuses
  authentication, and server should be able to tell which
  authentication is refused).

Something like:

struct {
	opaque certificate_request_context<0..255>
	ASN1Cert certificate_list<0..2^24-1>
	opaque wrapped_status<0..2^24-1>
} Certificate;

Where wrapped_status payload is what would be the CertificateStatus
message payload (empty if CertificateStatus would not have been
sent).

-Ilari

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 12 Dec 2015 15:02:37 +0000

> 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.

---

From: Rob Stradling <[email-masked]>
Date: Mon, 14 Dec 2015 12:29:25 +0000

>> CertificateVerify.  This is a fairly heavily important extension.

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?

[1] https://tools.ietf.org/html/rfc7633

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 14 Dec 2015 15:23:34 +0200

On Mon, Dec 14, 2015 at 12:29:25PM +0000, Rob Stradling wrote:
> 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