On Friday, 16 February 2018 18:06:41 CET The IESG wrote: > The IESG has received a request from the Transport Layer Security WG (tls) > to consider the following document: - 'The Transport Layer Security (TLS) > Protocol Version 1.3' > <draft-ietf-tls-tls13-24.txt> as Proposed Standard
Section 4.1.2 currently states that the only changes allowed to the second ClientHello message (in HelloRetryRequest case) are: - replacing key_share - removing early_data - adding cookie - updating pre_shared_key - adding, removing or changing padding What about extensions undefined now? What if in the future we have another extension like the PSK extension that needs to be updated for the second ClientHello? Do we accept that the above list is set in stone and will never change (except for new protocol versions), requiring all future extensions to also require the same extension payload for first and second ClientHello? -- 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 TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
