On Fri, Mar 10, 2017 at 8:37 AM, Ilari Liusvaara <ilariliusva...@welho.com> wrote:
> 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. > 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 > > > -Ilari > > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
