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

[Paul Wouters <[e-mail]>]

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">