On Fri, Mar 10, 2017 at 4:40 AM, Ilari Liusvaara <ilariliusva...@welho.com> wrote:
> On Thu, Mar 09, 2017 at 04:43:19PM -0800, Eric Rescorla wrote: > > 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. > > Ugh, the situation is way worse than what I thought. > That makes it an opportunity! 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). > So that's an easy fix :) > - 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? > > 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. 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" -Ekr 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
