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 <p...@nohats.ca> 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 > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
