Subject: [TLS] PR#448: CertificateStatus to extension

From: Eric Rescorla <[email-masked]>
Date: Mon, 2 May 2016 13:43:09 -0700

PR: https://github.com/tlswg/tls13-spec/pull/448
Targe landing date: Wednesday

In Buenos Aires we discussed moving CertificateStatus to part of the
Certificate message. In offline conversations, it started to look like that
wasn't optimal in part because it created an asymmetry wrt Signed
Certificate Timestamps. Instead, I propose just carrying the response in
the response extensions.

I just created PR#443, which moves the CertificateStatus response to an
extension in EncryptedExtensions. Comments welcome.

-Ekr

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Mon, 02 May 2016 23:04:59 +0200

Hi,

> extension in EncryptedExtensions. Comments welcome.

Regarding Certificate Status, is it such a good idea to keep both the  
original extension and the newer status_request_v2 extension in TLS 1.3?  
The client may have to signal the original extension in order to be  
interoperable with older TLS implementations, but wouldn't it be best if  
TLS 1.3 mandated the v2 extension in the server response?

-- 
Sincerely,
Yngve N. Pettersen

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 2 May 2016 14:11:29 -0700

> TLS 1.3 mandated the v2 extension in the server response?

I don't think it's a good idea to have the server responding with extensions
that the client didn't offer. If we're going to prefer v2, I would rather
forbid
the v1 version in TLS 1.3

-Ekr

>
> --
> Sincerely,
> Yngve N. Pettersen
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Mon, 02 May 2016 23:30:42 +0200

> the v1 version in TLS 1.3

I was thinking along the lines of saying that TLS 1.3 clients that support  
certificate status MUST send v2, MAY send v1 (to be interoperable with  
older servers that tolerate a 1.3 Hello), and TLS 1.3 servers (in a TLS  
1.3 session) MUST respond with v2 and MUST NOT respond with v1.

-- 
Sincerely,
Yngve N. Pettersen

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 2 May 2016 14:40:45 -0700

On Mon, May 2, 2016 at 2:30 PM, Yngve N. Pettersen <[email-masked]>
wrote:

> older servers that tolerate a 1.3 Hello), and TLS 1.3 servers (in a TLS 1.3
> session) MUST respond with v2 and MUST NOT respond with v1.

Well, what if the client doesn't want the OCSP response?

-Ekr

---

From: Watson Ladd <[email-masked]>
Date: Mon, 2 May 2016 14:45:41 -0700

On Mon, May 2, 2016 at 2:40 PM, Eric Rescorla <[email-masked]> wrote:
>> certificate status MUST send v2, MAY send v1 (to be interoperable with older
>> servers that tolerate a 1.3 Hello), and TLS 1.3 servers (in a TLS 1.3

Wouldn't the client then not send the certificate status extension,
which the proposed text seems to include as an option? Or am I missing
something?

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 2 May 2016 14:54:32 -0700

Sorry, I'm responding to Yngve's "MUST" suggestion.

I think what would be reasonable would be:

- clients MAY send either {(v1,v2), (v2), or ()}
- servers MUST send either {(v2 ) or ()} and MUST only send (v2) if the
client sent {(v1,v2), (v2)}

That I could live with...
-Ekr

On Mon, May 2, 2016 at 2:45 PM, Watson Ladd <[email-masked]> wrote:

> >>>>> Certificate message. In offline conversations, it started to look
> like
> >>>>> that
> older

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Tue, 03 May 2016 00:01:03 +0200

> client sent {(v1,v2), (v2)}

Which is what I suggested; note that I said "clients that support  
certificate status", with "support" meaning "enabled".

>> >>>>> Certificate Timestamps. Instead, I propose just carrying the  
>> response
>> >>>>> in
>> >>>>> the response extensions.
>> >>>>>
>> >>>>> I just created PR#443, which moves the CertificateStatus response  
>> to
>> an
>> >>>> interoperable with older TLS implementations, but wouldn't it be  
>> best
>> if

-- 
Sincerely,
Yngve N. Pettersen

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 2 May 2016 15:09:32 -0700

> certificate status", with "support" meaning "enabled".

My mistake for misreading you. Sounds like we're on the same page. I'll
modify
as you suggest.

-Ekr