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
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
