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

[Viktor Dukhovni <[e-mail]>]

> On Apr 12, 2018, at 2:20 PM, Willem Toorop <[e-mail]> wrote:
> 
> I notice that existing STS documents (HSTS [RFC6797] and MTA-STS
> [draft-ietf-uta-mta-sts]) are all one layer above TLS.  Is a STS TTL
> conveyed in a ServerHello message secure when it would be just for SSL?

The reason for that of course is that those "STS-flavours" are
commitments to do TLS vs plaintext, and so can't presume TLS as
a transport.  The question being settled is whether the peer does
TLS or not.

> I can see this might be different for the DANE use case because of the
> signed statements that come alongside the TTL, but for example...

Here the issue not whether TLS is supported, but whether the TLS
support includes support for this extension, and so TLS as a
transport is both natural and simultaneously supports all
relevant applications, rather than having to add per-application
mechanisms.

> In case of built-in STS with the extension, what does a 0 TTL mean?
> 
>  - When 0 has been the only value seen ever, it is clear to me that the
>    mechanism is equivalent with what we have in the draft now, but..

	Yes.  Don't pin, we're not promising ongoing support for the
	extension.

> 
>  - When another value has been seen before, is a value of 0 then enough
>    to clear the pin?  Or would a DoE proof (or insecurity proof)
>    alongside it be necessary?
> 
>    In case of the latter, what does that mean for sites that do have
>    DANE records, but no servers that support the extension?  Can they
>    be hampered (for an indefinite period) by a MiTM?  That would be
>    really bad for DANE deployment.

	* Positive TTL values require TLSA records, denial of existence
          should not be able to set a positive value.

	* Once a positive TTL is in effect it can only be set back to 0
	  in one of two ways:

		1.  Along with TLSA records that authenticate the handshake.
                    (possibly limited to PKIX-EE/TA per application profile)

		2.  Along with DNSSEC-authenticated denial of existence of
                    said TLSA records or of zone security.

That is downgrades to not pinning require more than a mis-issued WebPKI
certs.  The domain should either prove non-existence of signed TLSA
RRs, or signal a 0 TTL along with valid TLSA RRs that match the cert
chain.

You can think of the above as an initial draft of the text for
option (C).

-- 
	Viktor.