On Thursday 16 July 2015 18:09:38 Ilari Liusvaara wrote: > > > > 6.3.1.2. (Server Hello) > > > > > > Well, at least it wouldn't be backward compatiblity hazard to remove > > > session_id_len, since it comes after server version. > > > > I'm sold. > > However, that would change ServerHello parsing. > > Thinking about it, if one decides to be careful with message parsing, one > needs to assign all new/modified TLS 1.3 handshake messages new IDs. > > Currently there is only one offending message type w.r.t. that: 14, which > is server_configuration in 1.3 and server_hello_done in 1.2. > > Some other messages share IDs, but I think those are compatible (even > CertificateVerify, as it is just one digital signature in both).
Server Key Exchange for DHE, ADH, SRP, etc. not to mention TLS1.1 vs TLS1.2 it's not uncommon to have different parsers for "same" message type > > > Also, the record protection used for early handshake messages should be > > > indicated. > > > > Can you expand on that? > > How does the client know what record protection algorithms are valid > for 0RTT transmission for that server? And how does the client know that the algorithms came from the server. We should have a "client MUST wait for the full handshake to finish before recording this information" or we will have a very nice cipher downgrade. Just having it signed is likely not a good idea, as they may depend on ciphersuites advertised by client. > > > Also, with regards to complications of DSA, just dump it? :-) > > > > I'm fine with that if the chairs declare consensus on it. > > As datapoint, either the scan that was used as basis of that curve > pruning doesn't support DSA, or there are no servers that even have > DSA certs. > > I think I heard some time back that there are only 4 (or some other very > small number) valid DSA SSL certs in the entiere public Internet. that scan uses Mozilla trust roots and reports only trusted servers (to weed out unmaintained ones out), Microsoft list is a bit bigger -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
