Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Viktor Dukhovni <[e-mail]>]

> On Apr 16, 2018, at 12:31 PM, Nico Williams <[e-mail]> 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.