> On May 16, 2018, at 1:59 PM, Christian Huitema <huit...@huitema.net> wrote:
>
> The way I understand it, your proposal is not so much to "reserve 16
> bits" but rather to "include a 16 bit field defined as the pinning time
> in hours". Or maybe, "reserve 16 bits as set to zero on send and ignored
> on receive" in the current TLS DNSSEC draft, let it be published as RFC,
> and publish very soon a draft that defines the 16 bit field as the
> pinning time in hours, and presumably explains how to avoid the usual
> pitfalls of pinning. Do I understand correctly?
Yes, with the slightly more precise semantics you mention of
"set to zero on send and ignored on receive" and zero means "do
not pin". This is we expect better then just reserving an undefined
field.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
