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

[Eric Rescorla <[e-mail]>]

On Fri, Mar 10, 2017 at 9:23 AM, Ilari Liusvaara <[e-mail]>
wrote:

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

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.


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.


I could also live with this.

-Ekr




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