On Monday, 27 August 2018 19:24:34 CEST Mounira Msahli wrote: > One could abbrevate the handshake traces to just show the relevant > parts (which could also cut some clutter)? I think the relevant > messages always occur in the same order (clienthello, serverhello/ > encryptedextensions, certificate, certificate).
the draft doesn't change the order of messages, doesn't add new messages and doesn't change the place in which the relevant extensions are placed – so, what is the utility of duplicating the message flow from the TLS RFCs? e.g. RFC 8449 and RFC 7685 don't, and they did define new extensions > The table in section 4.2. Extensions of [RFC 8446] (TLS 1.3) indicates the > messages where a given extension may > appear: > | client_certificate_type [RFC7250] | CH, EE | > | > | server_certificate_type [RFC7250] | CH, EE | > > But in RFC 7250 (TLS 1.2), the same extensions could appear in CH and SH. correct, this RFC 8446 table applies only to connections that negotiated TLS 1.3 -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
