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

On Wed, Feb 21, 2018 at 6:10 AM, Benjamin Kaduk <bkaduk@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
>