Re: [TLS] Proposed text for dnsssec chain extension draft

This proposal is quite a bit more than just a two byte reserved field.

On Wed, Apr 25, 2018 at 8:46 AM, Nico Williams <nico@cryptonector.com>
wrote:

> 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
>