Re: [TLS] Keeping TLS extension points working

[David Benjamin <[e-mail]>]

I've finally gotten to uploading
https://tools.ietf.org/html/draft-davidben-tls-grease-01 which hopefully
resolves the procedural issues (thanks again!). I've also revised the text
slightly after some off-list feedback about the risks of non-deterministic
failures.

I didn't add text about what middleboxes are allowed to do since I wasn't
sure what text would be useful. Looking at all the changes we've done in
TLS 1.3, they can do is syntax-check the ClientHello. Anything beyond that
we've been considering fair game to change. TLS 1.3's ServerHello is not
compatible with TLS 1.2's ServerHello. The first message may even not be
ServerHello and instead HelloRetryRequest.

David

On Wed, Jul 27, 2016 at 4:02 PM Sean Turner <[e-mail]> wrote:

>
> > On Jul 26, 2016, at 11:11, David Benjamin <[e-mail]> wrote:
> >
> > 1) “Updates: 5246 (if approved)” because typically extension documents
> don’t “update” the base specification.  If you are suggesting that all
> implementations must support these values then an updates header makes
> sense.  Note I’m sure somewhere along the way an extension that isn’t
> expected to be supported by all implementation has an updates header but
> what I described is how we’re doing it now.
> >
> > I wasn't sure and mimicked RFC 7507 and RFC 7685 which both did this.
> >
> > I expect that all servers will "support" this specification in so far as
> it says nothing useful for servers. TLS servers are supposed to ignore
> unknown values. I would certainly like for as many clients to do it as
> possible so the ecosystem effects work out, but I certainly don't intend
> for it to be any kind of requirement. (I suppose the text says MAY so
> existing clients also "support" it by default.)
> >
> > Is it better to remove that line in this case? Happy to do whatever
> works.
>
> I’d probably lean towards removing it.
>
> spt