Re: [TLS] Server validation of a second ClientHello

[Benjamin Kaduk <[e-mail]>]

On Mon, Feb 11, 2019 at 10:43:39AM +1100, Martin Thomson wrote:
> On Fri, Feb 8, 2019, at 23:53, Hubert Kario wrote:
> 
> > > If we require or allow checking - and I think that we should definitely
> > > allow a check - the details of the conditions under which a check might
> > > fail aren't completely obvious for new extensions.  A new extension might
> > > be defined that has special handling in HelloRetryRequest, so it might be
> > > reasonable to allow new extensions to be changed.
> > 
> > yes, and we already had discussion on this ML about this: if the extension 
> > needs to change (based on protocol definition), the server MUST include it in 
> > HRR to signal to client, "yes, I do know about it, you can update it" and 
> > client MUST NOT change it otherwise
> 
> I remember having that discussion, but I guess the only way it made it into the spec was as:
> 
>    -  Other modifications that may be allowed by an extension defined in
>       the future and present in the HelloRetryRequest.
> 
> Which isn't particularly direct, but I guess that's enough.

I think I pressed for that text, on the grounds that the core spec should state the
core expectations but try to assume as little as possible about future extensions' needs.
It's pretty clear that this implies that (with the current set of extensions) a current
server can rely on the "only extensions in HRR can change" property (modulo the existing
exceptions in the core spec).

-Ben