Subject: Re: [TLS] Review of PR #209

From: Andrei Popov <[email-masked]>
Date: Tue, 4 Aug 2015 00:21:02 +0000

> use CertificateRequest within the handshake, and the new content type outside of it

Would the client then also use this new content type for Certificate and CertificateVerify messages (when these are sent after the handshake is complete)?

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Martin Thomson
Sent: Saturday, July 25, 2015 8:00 AM
To: [email-masked]
Subject: [TLS] Review of PR #209

Andrei proposes two changes in https://github.com/tlswg/tls13-spec/pull/209

The first expands the ways in which a server can identify certificates.  This is fine.  I do wonder whether we can remove CertificateType entirely for TLS 1.3 though (that can be done separately).

The second is worrisome.  I don't like that a handshake message now has two different potential locations that it might appear in.  That seems like a hazard.  I think that we need a new content type for a new message that can be used after the handshake completes.  Then there are two options:
 a) remove CertificateRequest from the handshake entirely and allow the handshake to complete before authenticating (this has a number of hazards that make it probably worse than the duplication it addresses)
 b) use CertificateRequest within the handshake, and the new content type outside of it

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Martin Thomson <[email-masked]>
Date: Tue, 4 Aug 2015 09:13:12 -0700

> Would the client then also use this new content type for Certificate and CertificateVerify messages (when these are sent after the handshake is complete)?

Yeah, I think that's best.

---

From: Andrei Popov <[email-masked]>
Date: Tue, 4 Aug 2015 17:04:21 +0000

I'm not opposed to using a new content type in this way, if folks feel that this makes things better.

Cheers,

Andrei