[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

[Hubert Kario <[e-mail]>]

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