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 <s...@sn3rd.com> wrote: > > > On Jul 26, 2016, at 11:11, David Benjamin <david...@chromium.org> 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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
