> On Apr 16, 2018, at 12:31 PM, Nico Williams <n...@cryptonector.com> wrote: > > I wouldn't mind a (C'): a variant of (C) where we get denial of > existence and a one- or two-byte TTL (one by count of weeks or two-byte > count of hours) with de minimis text about it, leaving pinning semantics > to a separate document. In such a (C') we'd elide all pinning (or most*) > in this document.
Specifically, this actually would help the cause of those who don't want pinning, because in (C') we can specify: * Client's MUST NOT employ any pinning for downgrade protection when the extension support TTL sent by the server is ZERO. Only a-priori local policy that mandates DANE TLSA records for particular domains can require the extension, in all other cases the extension MUST be optional in future connections when an authenticated server returns a ZERO extension TTL. * Pending future specifications, the server MUST set the extension support TTL to ZERO. With this, we get to explicitly specify that clients MUST NOT pin, rather than removing text and leaving the option up to the implementors imagination. And implementors will want downgrade protection, and the current list of half-baked downgrade protection measures in Section 8 was in place at the time of the WG LC consensus for moving the draft forward, and these were added in lieu of tackling downgrades in a more systematic way, so ripping it all out does not seem like a minor tweak. If we add a two byte extension support TTL field, that servers will set to ZERO, and tell clients to not attempt downgrade protection when it is so set, we leave room for future downgrade protection without having to change the extension wire format. With the TTL always returned as ZERO in the recent past, the server is equally free to return denial of existence or just not present the extension. Operator's choice. This way, the draft retains the option of future downgrade protection, thus not completely abandoning its promised scope, while deferring any pinning for now, and indeed making it very clear to clients that they MUST NOT (yet) do any TOFU or similar pinning. > * We might want to say that if the TTL is zero then the clients MUST NOT > pin and must clear any pin. And we might do this in spite of not > describing any pinning semantics -- explicitly leaving pinning > semantics to a future document. Exactly. I'd like to suggest that this is the most reasonable common ground, and would urge the WG and authors to get behind this as a consensus position. -- Viktor. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls