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

On Thu, Apr 26, 2018 at 11:13 AM, Nico Williams <nico@cryptonector.com>
wrote:

> On Wed, Apr 25, 2018 at 11:30:02PM -0700, Eric Rescorla wrote:
> > Thanks for producing some text. I understand why one might think that
> > having a reserved 16-bit field is useful here, but I don't really
> > agree.
> >
> > The conventional reason to reserve this kind of field is that you need
> > to leave space for an extension in some PDU, because it's hard to add
> > later. But that's not true here (or in TLS in general) because we
>
> -07 has text on pinning.  There is no consensus on making that work
> _now_.  There is only consensus on removing that text and revisiting
> pinning later.  Well, later we will need these two bytes.
>
> So there's the conventional reason to reserve this kind of field:
> because we know we will need it, and adding it via some extension
> facility will be harder than... already having it.
>
> And yes, we (the IETF) do use reserved fields even in protocols where
> there is extensibility.
>

[citation-needed]

All the instances of "reserved" I can think of are either due to bit
alignment or blocking off old stuff.

--Richard

> > already have an extension mechanism (indeed, the one that's being used
> > by this specification). If we end up having consensus to do pinning,
> > then it's straightforward to define a new TLS extension that provides
> > it.
>
> Having these two bytes now will mean that they are always present, which
> will make it a lot easier for implementations to a) start sending
> non-zero values, b) start handling non-zero values, once we write a spec
> on what non-zero values mean.  (And we know what that spec will say,
> which is why we know we need two bytes.)
>
> > If you look at HPKP and Expect-CT, you will note that there are a
> > [...]
>
> HPKP is completely different.  The idea here is NOT to pin key material,
> CAs, or anything of the sort.  The idea here is to pin only the use of
> this extension, and this does not even bind one to use DANE because the
> extension can carry a denial of existence.
>
> Nico
> --
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>