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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
