Subject: [TLS] Updating for non-X.509 certificate types

From: Eric Rescorla <[email-masked]>
Date: Thu, 9 Mar 2017 16:43:19 -0800

As noted in https://github.com/tlswg/tls13-spec/issues/722, the new fancy
TLS 1.3 Certificate structure doesn't map well to the various non-X.509
cert structures we have defined, specifically:

- Raw Public Keys
- Cached Info
- OpenPGP

Probably mapping each of these to 1.3 is relatively straightforward
(Raw public keys == a list with one key, Cached info == the hash of
each cert + its extensions, and so on), but I tend to think that given the
modest/specialized deployment of these extensions, it's better to do a
set of small bis RFCs to define each of these, rather than add a bunch
of clutter to TLS 1.3 proper.

Does anyone object to this? Volunteers.

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Fri, 10 Mar 2017 14:06:19 +1100

It seems like the minimum thing TLS 1.3 can do is observe that these
extensions exist and that they can't be used with TLS 1.3 (yet).

On 10 March 2017 at 11:43, Eric Rescorla <[email-masked]> wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 9 Mar 2017 19:12:32 -0800

Yes, assuming that people agree with my plan above, I will do so.

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 10 Mar 2017 14:40:13 +0200

> Does anyone object to this? Volunteers.

Ugh, the situation is way worse than what I thought.

Basically, all three assume they have full control of certificate
message, worst of all being OpenPGP, which modifies it in more
complex ways (it isn't a pure element or list anymore).

And even with RPK, which appiles least severe modifications,
still modifies the structure in ways that are not obvious in
implications w.r.t. TLS 1.3.

Oh, and turns out I had implemented RPK in TLS 1.2 wrong by assuming
that it doesn't actually modify the certificate message format.
Which turned out to be wrong assumption (I fixed this after
discovering the format changes).

And then certificate types don't currently work sanely for client
certs, even if you knew how those map to Certificate message.

Client_certificate_type and server_certificate type aren't the
only problematic extensions w.r.t. TLS 1.3. The table of
extensions has the following too (all marked as allowed, I
added short reason I think those are problematic):

- client_certificate_url: Replaces certificate message. Hardcodes
  SHA-1 (which is now provably broken).
- user_mapping: Has extra handshake message.
- cert_type: All the problems of CCertT and SCertT, combined with
  fixing both to be the same.

With user_mapping, applying similar trick as in status_request is
not completely trivial because extensions that are answered in client
Certificate are offered in CertificateRequest. Okay, except that
extension is not an answer to ClientHello extensions, and the
extension assumes offer-answer relationship between client and server
extensions. Might need some special-casing.

Could be useful to have explicit list of extensions (no registry, since
this list can be never updated) that lists extensions that are
deprecated in TLS 1.3.

That is, only allowed in ClientHello and only if also advertising
prior versions.

AFAICT, the list would be:

- client_certificate_url?
- trusted_ca_keys
- truncated_hmac
- client_authz
- server_authz
- cert_type?
- srp
- status_request_v2
- client_certificate_type?
- server_certificate_type?
- encrypt_then_mac
- extended_master_secret
- cached_info?
- SessionTicket TLS (don't ask why it is written like this)
- renegotiation_info

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 10 Mar 2017 07:02:22 -0800

> Ugh, the situation is way worse than what I thought.

That makes it an opportunity!

>   SHA-1 (which is now provably broken).

So that's an easy fix :)

>   fixing both to be the same.

Does anyone use this?

> extensions. Might need some special-casing.

Yeah, I think we should probably just consider banning user_mapping,
at least until someone comes up with a way to use it here.

> this list can be never updated) that lists extensions that are

Currently this is by exclusion. I.e., these aren't listed as usable with
1.3. It does seem to me that we shouldn't ban cached_info and
the cert type ones, because if/when they become usable with 1.3
then they should be permissible. So I think I would rather say
"don't advertise these with 1.3 unless you're willing to do them
with 1.3"

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 10 Mar 2017 18:37:38 +0200

> >   fixing both to be the same.

I don't think anyone uses it. cert_type was defined in order to use
OpenPGP certs (RPK has SCertT and CCertT, altough in theory one could
use cert_type). Nobody uses OpenPGP. Even the most notable TLS library
supporting those (GnuTLS) is deprecating it.
 
> at least until someone comes up with a way to use it here.

IIRC, you asked "does anyone use this" before and some MS guys said
yes, they use it.
 
Or at least I remember some guys saying that they use it.

> "don't advertise these with 1.3 unless you're willing to do them

The problem here is, one can't do that with TLS 1.2+1.3 dual-version
either. If client doesn't know what extension X means in TLS 1.3
(but does know it for TLS 1.2), if it advertises it, it runs the
risk that server does in fact know what X does in TLS 1.3, and then
blows up when server acts accordingly.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 10 Mar 2017 08:42:38 -0800

> blows up when server acts accordingly.

Right. I am saying that you must not offer these and 1.3 simultaneously
unless you implement whatever 1.3 thingy we finally define for it.

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 10 Mar 2017 19:23:49 +0200

> unless you implement whatever 1.3 thingy we finally define for it.

I think that is a bad idea.

And after all, all the currently deprecated extensions are allowed in
multi-version TLS 1.3 ClientHello. And sometimes that is rather
important, given that this list contains security fix extensions like
extended_master_secret and renegotiation_info.

Also, I think that the definition of certificate types is so bad that
making the thing work in TLS 1.3 is not going to be feasible. Which
impiles replicating the functions with new extensions with completely
new semantics.

The reason is, cert_types see fit to completely redefine the certficate
message in all sorts of ways. And mapping those ways to standard TLS
1.3 Certificate message structure is too hard.

cached_info is much much easier. Basically if its extension is moved
to EE, but everything else held constant, it will AFAICT work in 
TLS 1.3 just fine, including in dual-version cases. If you get
the version wrong, things still work (smooth fallback) because of
hash check.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 10 Mar 2017 09:42:21 -0800

> extended_master_secret and renegotiation_info.

Well, those are different: those are extensions which we know will
never work for 1.3, not which have not been defined for 1.3.

> impiles replicating the functions with new extensions with completely

I could also live with this.

-Ekr

---

From: Andrei Popov <[email-masked]>
Date: Fri, 10 Mar 2017 18:04:54 +0000

Ø  Does anyone use this?

Ø  I don't think anyone uses it.

Au contraire: Windows TLS stack supports user_mapping and this mechanism appears to be somewhat in use. However, I agree that this falls into the category of extensions that need to be either deprecated or redefined for TLS 1.3.

Cheers,

Andrei

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 10 Mar 2017 20:42:41 +0200

On Fri, Mar 10, 2017 at 06:04:54PM +0000, Andrei Popov wrote:
> Au contraire: Windows TLS stack supports user_mapping and this
> mechanism appears to be somewhat in use. However, I agree that
> this falls into the category of extensions that need to be either
> deprecated or redefined for TLS 1.3.

Oh, sorry, quoting context fail: I meant that nobody uses cert_type,
not that nobody uses user_mapping.

-Ilari

---

From: Andrei Popov <[email-masked]>
Date: Fri, 10 Mar 2017 18:53:01 +0000

Well, admittedly neither user_mapping, nor cert_type is hugely popular. 
It would not make sense for the TLS 1.3 spec to be on hold until these extensions are reconciled with it.

However, I do think that a TLS 1.3 ClientHello should be able to advertise extensions that are not defined for TLS 1.3, when the client is willing to accept TLS<=1.2.

Cheers,

Andrei

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, March 10, 2017 10:43 AM
To: Andrei Popov <[email-masked]>
Cc: Eric Rescorla <[email-masked]>; [email-masked]
Subject: Re: [TLS] Updating for non-X.509 certificate types

On Fri, Mar 10, 2017 at 06:04:54PM +0000, Andrei Popov wrote:
> mechanism appears to be somewhat in use. However, I agree that this 
> falls into the category of extensions that need to be either 

Oh, sorry, quoting context fail: I meant that nobody uses cert_type, not that nobody uses user_mapping.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 10 Mar 2017 10:52:46 -0800

On Fri, Mar 10, 2017 at 10:04 AM, Andrei Popov <[email-masked]>
wrote:

> Au contraire: Windows TLS stack supports user_mapping and this mechanism
> appears to be somewhat in use. However, I agree that this falls into the
> category of extensions that need to be either deprecated or redefined for
> TLS 1.3.
>

Are you OK with deprecated followed by redefined with a new code point?

-Ekr

---

From: Andrei Popov <[email-masked]>
Date: Fri, 10 Mar 2017 19:26:49 +0000

It will be inelegant to have two code points for what is conceptually the same thing, but I think this is the best option, under the circumstances.

Cheers,

Andrei

From: Eric Rescorla [mailto:[email-masked]]
Sent: Friday, March 10, 2017 10:53 AM
To: Andrei Popov <[email-masked]>
Cc: Ilari Liusvaara <[email-masked]>; [email-masked]
Subject: Re: [TLS] Updating for non-X.509 certificate types

>  I don't think anyone uses it.

-Ekr

Cheers,

Andrei

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 10 Mar 2017 11:28:51 -0800

Thanks

On Fri, Mar 10, 2017 at 11:26 AM, Andrei Popov <[email-masked]>
wrote:

> It will be inelegant to have two code points for what is conceptually the
> same thing, but I think this is the best option, under the circumstances.
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* Eric Rescorla [mailto:[email-masked]]
> *Sent:* Friday, March 10, 2017 10:53 AM
> *To:* Andrei Popov <[email-masked]>
> *Cc:* Ilari Liusvaara <[email-masked]>; [email-masked]
> *Subject:* Re: [TLS] Updating for non-X.509 certificate types
>
>
>
>
>
>
>