Re: [TLS] proposed text for draft-ietf-tls-dnssec-chain-extension-06

[Eric Rescorla <[e-mail]>]

Speaking as an individual, as I said in the meeting, I don't think this is
a helpful change.

-Ekr


On Wed, Mar 21, 2018 at 1:05 PM, Paul Wouters <[e-mail]> wrote:

>
> I think the below change would address my issue, without stepping on the
> things people brought up today (other then suggesting, not mandating,
> to send proof of non-existence when halting TLSA support in the zone)
>
> Paul
>
> diff --git a/draft-ietf-tls-dnssec-chain-extension-07.xml
> b/draft-ietf-tls-dnssec-chain-extension-07.xml
> index 333d2fc..0701b22 100644
> --- a/draft-ietf-tls-dnssec-chain-extension-07.xml
> +++ b/draft-ietf-tls-dnssec-chain-extension-07.xml
> @@ -508,6 +508,15 @@
>        does not exceed the DNS TTLs or signature validity periods of the
>        component records in the chain.
>      </t>
> +    <t>
> +      If the zone using TLSA records stops using TLSA records, those TLS
> servers
> +      that presented TLSA records using this extension SHOULD serve the
> authenticated
> +      denial of existence of TLSA records for some time so their
> deployment remains
> +      distinguishable from an attack. Ending the use of this extension
> SHOULD NOT be
> +      done at the same time as changing the certificate being used on the
> server. This
> +      helps clients from recognising that the current changed deployment
> is not
> +      an attack performed using a different mis-issued PKIX certificate.
> +    </t>
>    </section>
>
>
> @@ -580,26 +588,14 @@
>        specific servers, clients could maintain a whitelist of sites where
>        the use of this extension is forced. The client would refuse to
>        authenticate such servers if they failed to deliver this extension.
> +      Those clients should interpret authenticated denial of existence
> proofs
> +      as valid use of this extension and continue to establish the TLS
> connection,
> +      even if this connection uses a different PKIX certificate.
>        Client applications could also employ a Trust on First Use (TOFU)
> like
>        strategy, whereby they would record the fact that a server offered
> the
>        extension and use that knowledge to require it for subsequent
> connections.
>      </t>
>
> -    <t>
> -      This protocol currently provides no way for a server to prove that
> -      it doesn't have a TLSA record. Hence absent whitelists, a client
> -      misdirected to a server that has fraudulently acquired a public CA
> -      issued certificate for the real server's name, could be induced to
> -      establish a PKIX verified connection to the rogue server that
> precluded
> -      DANE authentication. This could be solved by enhancing this protocol
> -      to require that servers without TLSA records need to provide a
> DNSSEC
> -      authentication chain that proves this (i.e. the chain includes NSEC
> or
> -      NSEC3 records that demonstrate either the absence of the TLSA
> record,
> -      or the absence of a secure delegation to the associated zone). Such
> an
> -      enhancement would be impossible to deploy incrementally though
> since it
> -      requires all TLS servers to support this protocol.
> -    </t>
> -
>    </section>
>
>    <section title="Security Considerations">
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>