Re: [TLS] Future interoperability issues for HRR for new extensions; Was: UPDATED Last Call: <draft-ietf-tls-tls13-24.txt> (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard

[Benjamin Kaduk <[e-mail]>]

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.

-Ben