On Wed, Apr 25, 2018 at 10:40:02AM -0500, Nico Williams wrote: > On Wed, Apr 25, 2018 at 09:57:22AM -0500, Nico Williams wrote: > > On Wed, Apr 25, 2018 at 11:51:58AM +0200, Melinda Shore wrote: > > > On 4/25/18 7:33 AM, Viktor Dukhovni wrote: > > > > Perhaps a concrete proposal will make it > > > > easier to reach a mutually-agreeable consensus position, and make it > > > > clear that the requested 16-bits are a reasonable consensus outcome. > > > > > > Hi, Viktor: > > > > > > This doesn't actually reflect the consensus called by the > > > chairs, as I understand what was posted. It may be useful > > > to start work on a new draft describing your proposal. > > > > The chair said there is consensus for (A) with no pinning. Viktor's > > proposal is (A) with no pinning. It's not at all clear to me that the > > two reserved bytes are outside the consensus, and anyways, their cost is > > minimal. > > > > However, if you object to turning the extension contents into a struct, > > then I would propose a slight tweak to Viktor's proposal: > > > > Two-byte elements of the AuthenticationChain are reserved for future > > use. Pending future specifications, clients MUST discard any two- > > byte elements of the AuthenticationChain, and servers MUST NOT send > > any such elements. > > Ay, never mind, this isn't XDR, so that wouldn't work.
Actually, since the extension's body is an opaque<1..2^16-1>, and the extension is itself an opaque<>, it's possible to have data past the end of the body of the extension. But at this point I prefer Viktor's struct proposal. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
