Subject: [TLS] Proposed Change to Certificate message (#654)

From: Nick Sullivan <[email-masked]>
Date: Fri, 23 Sep 2016 00:42:09 +0000

PR: https://github.com/tlswg/tls13-spec/pull/654

Hello,

I'd like to propose a small to the Certificate message format to allow for
future extensibility of the protocol.

This change adds a set of extensions to the Certificate message. With this
change, the Certificate message can now hold all extension messages that
are certificate-specific (rather than connection-specific). This change
also resolves the anomaly of OCSP messages appearing before certificates in
the handshake.

Reasoning:
I've come to the conclusion that the current mechanism in TLS 1.3 for OCSP
and SCT is lacking forsight. OCSP and SCT are per-certificate metadata, not
per-connection metadata. By putting these responses in the
EncryptedExtensions, you limit these extensions to being shown once per
connection. This restricts future protocol extensions from using multiple
Certificate messages to support multiple certificates on the same
connection. An example of this is the post-handshake authentication
proposal (
https://tools.ietf.org/html/draft-sullivan-tls-post-handshake-auth-00),
which currently requires a modified post-handshake Certificate message.
This proposed change would simplify the post-handshake auth proposal
significantly and generally make more sense as more certificate-specific
extensions are created.

Nick

---

From: Brian Smith <[email-masked]>
Date: Thu, 22 Sep 2016 16:17:02 -1000

> also resolves the anomaly of OCSP messages appearing before certificates in

There are two ways that such a thing could be done. How your proposal
suggests:

    opaque ASN1Cert<1..2^24-1>;
    struct {
        opaque certificate_request_context<0..2^8-1>;
        ASN1Cert certificate_list<0..2^24-1>;
        Extension extensions<0..2^16-1>;
    } Certificate;

or:

    opaque ASN1CertData<1..2^24-1>;
    struct {
        ASN1CertData cert_data;
        Extension extensions<0..2^16-1>;
    }

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

I think you are right that the SCT and the OCSP response are
per-certificate. In particular, they are not per-certificate-chain, so to
me the latter form, where each certificate in the chain gets its own
extension list, makes more sense to me. Would you consider changing the
proposal to the second form?

Cheers,
Brian
-- 
https://briansmith.org/

---

From: Nick Sullivan <[email-masked]>
Date: Fri, 23 Sep 2016 02:26:38 +0000

This suggestion makes sense to me.

Both the SCT and OCSP v2 extension allow for multiple objects in order to
cover multiple certificates in a chain, but your suggestion makes the
grouping much more explicit and obviates the need for OCSPv2. I'd
definitely consider a modification like this.

Nick
On Thu, Sep 22, 2016 at 7:17 PM Brian Smith <[email-masked]> wrote:

>> This change adds a set of extensions to the Certificate message. With
>> this change, the Certificate message can now hold all extension messages
>> that are certificate-specific (rather than connection-specific). This
>> change also resolves the anomaly of OCSP messages appearing before
>> certificates in the handshake.
>>
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 23 Sep 2016 22:43:46 +0300

> significantly and generally make more sense as more certificate-specific

Also, this would presumably solve the user_mapping problem without
introducing a new handshake message. Basically, there is extension
user_mapping, that wants to send some certificate-associated auxillary
data from client to server. Currnently, there is no place to put such
data.

And yeah, with post-handshake auth, it looks like one would want a lot
more flexibility than currently exists.

BTW: I would rather dump the current post-handshake auth for such
extension proposal. The current post-handshake authentication is just
plain annoying to implement in contexts where the client has no
intention of ever supporting it.

And the current post-handshake auth mechanism seems to be insufficient
for real-world uses too...

I recently got an idea of implementing freezing session state into
octet stream and being able to thaw such. I quickly discovered I
can't implement that without either having freezable hashes (which I
don't have available) or just saying screw it with post-handshake auth
and never responding to the requests, even to reject them.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 23 Sep 2016 12:49:17 -0700

This seems like a reasonable direction.

-Ekr

On Thu, Sep 22, 2016 at 7:26 PM, Nick Sullivan <[email-masked]>
wrote:

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

---

From: Victor Vasiliev <[email-masked]>
Date: Fri, 23 Sep 2016 17:53:56 -0400

The version where each certificate gets its own extension sounds like a
step in the right direction.

One concern I have is the way this would interact with cached_info
extension.  Currently, it allows the entire Certificate message to be
cached -- which just meant the entire chain in 1.2.  With the suggested
change, this makes less sense: while you still want to cache SCTs, this
might be much less desirable for OCSP responses.

On Fri, Sep 23, 2016 at 3:49 PM, Eric Rescorla <[email-masked]> wrote:

> On Thu, Sep 22, 2016 at 7:26 PM, Nick Sullivan <
> [email-masked]> wrote:
>

---

From: Nick Sullivan <[email-masked]>
Date: Fri, 23 Sep 2016 23:05:10 +0000

Thanks for the suggestions. I've restructured my PR to include an array of
SingleCertificate objects in the Certificate structure.

Ilari: I agree that the post-hanshake auth mechanism as currently described
is a bit lacking, but I'd like to sort this out first.

Victor: For cached_info, OCSP responses are relatively long-lived and the
server should know whether or not a cached OCSP is close to expiration, so
cached_info is still useful, but I agree that this makes it less useful.

On Fri, Sep 23, 2016 at 2:53 PM Victor Vasiliev <[email-masked]> wrote:

>>> Both the SCT and OCSP v2 extension allow for multiple objects in order
>>> to cover multiple certificates in a chain, but your suggestion makes the

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 24 Sep 2016 12:17:51 +0300

> SingleCertificate objects in the Certificate structure.

It occured to me that certain extensions might be considered to be per-
chain. Like e.g. type of the certificate. Where do extensions like that
go? Always to the extension block of the first certificate (except that
might cause somewhat of a cyclic dependency in parsing)?

And then there is the user_mapping. I presume mechanism like this is to
be used to transport it (avoiding need to mess with new handshake
messages and such.
 
> is a bit lacking, but I'd like to sort this out first.

Well, more like I was annoyed at having to implement that at all and the
fact that it requires remembering a hash state (which may be a quite
harsh requirement in some cases).

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Sat, 24 Sep 2016 21:31:51 +1000

> might cause somewhat of a cyclic dependency in parsing)?

The type of which certificate?  The end-entity?  Seems like that
belongs with the end-entity cert then.

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 24 Sep 2016 15:08:57 +0300

> belongs with the end-entity cert then.

I mean equivalent of the client_certificate_type/server_certificate_type
extensions.

And the way those extensions are defined, those scope the entiere chain.

E.g. There was some discussion about "subcerts"[1]. One way to add those
would be as a new certificate type.

... Or are new certificate types like new CLASSes in DNS: Heavy objects
dropped by bad idea fairy? :->

But in the future, there might very well be new extensions that are
scoped to certificate chain and not and individual certificate. And
those can't be put into EncryptedExtensions if server can send multiple
certificates (like it can in post-handshake auth extension) or if
client needs to send one.

[1] The usecases can't be practically accomplished today: The mode of
operation is just plain alien to X.509.

-Ilari