On Wed, Feb 21, 2018 at 6:10 AM, Benjamin Kaduk <bka...@akamai.com> wrote:
> On 02/21/2018 05:46 AM, Hubert Kario wrote: > > 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? > > > > It seems to me that such a hypothetical future extension could include a > signaling value in the HRR to indicate that the server understands the > new extension, and the semantics of the extension defined such that when > the server understands the extension the client may change its value > between ClientHello1 and ClientHello2. > > This might be slightly inefficient if the extension's information flow > is only from client to server, but I think it would be a compatible way > to allow an extension value to change after HRR. > Yes. Also, there's not really any good reason to change an extension that is not mentioned in HRR. -Ekr > -Ben > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
