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

[Ilari Liusvaara <[e-mail]>]

On Fri, Mar 10, 2017 at 08:42:38AM -0800, Eric Rescorla wrote:
> On Fri, Mar 10, 2017 at 8:37 AM, Ilari Liusvaara <[e-mail]>
> wrote:
> 

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

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