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

[Paul Wouters <[e-mail]>]

On Wed, 25 Apr 2018, Eric Rescorla wrote:

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

The pinning is not about DANE pinning but about extension pinning. To
make a 2nd extension to pin a 1st extension seems very wrong to me.

Additionally, as explained before, since all pinning text has consensus
to be removed, this would leave clients completely in the dark about
what to do when the extension vanishes. Adding the two byte zeroes
allows the document to clearly and unequivocally say to NOT pin this
extension with some magic local policy.

> That doesn't seem like a good set of tradeoffs.

This has nothing to do with trade-offs. It has to do with carefully
specifying client behaviour for use with _this_ extension. It makes
no sense to leave that unspecified for another document.

Paul