On Fri, Mar 10, 2017 at 07:02:22AM -0800, Eric Rescorla wrote: > On Fri, Mar 10, 2017 at 4:40 AM, Ilari Liusvaara <ilariliusva...@welho.com> > wrote: > > > - user_mapping: Has extra handshake message. > > - cert_type: All the problems of CCertT and SCertT, combined with > > fixing both to be the same. > > > > Does anyone use this?
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. > > 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. > > Yeah, I think we should probably just consider banning user_mapping, > 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. > 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. > > > > 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" 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
