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

[Nico Williams <[e-mail]>]

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.