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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
