Not an argument in favor of the proposal, but the issue with firewall certs is not that we would want to override local security policy, but that firewall certs *can* in principle override local security policy, and in principle DANE could be used to prevent that. What is meant by a firewall cert is a cert that's able to sign for any domain; such certs can in principle be obtained by entities other than the operator of the local firewall. We're calling them firewall certs because that's the ostensible reason for their existence, but we shouldn't assume that the name has any power to restrict how they are used. :)
On Tue, Oct 16, 2018 at 3:45 AM Ryan Sleevi <ryan-ietf...@sleevi.com> wrote: > > > On Mon, Oct 15, 2018 at 4:50 PM Viktor Dukhovni <ietf-d...@dukhovni.org> > wrote: > >> Though I am generally an advocate for DANE, and have done much work to >> further its adoption, this is not a realistic proposal. DANE adoption >> in TLS will be incremental and will not be accomplished via a mandate. >> >> > On Oct 15, 2018, at 4:20 PM, Rene 'Renne' Bartsch, B.Sc. Informatics >> <ietf=40bartschnet...@dmarc.ietf.org> wrote: >> > >> > TLS is prone to Man-In-The-Middle attacks with unjustly obtained >> intermediate certificates (e.g. firewall appliances). >> > The DNSSEC KSK-rollover worked like a charm. >> > >> > So I suggest to make DANE-TLS mandatory for TLS to prevent >> Man-In-The-Middle attacks with unjustly obtained intermediate certificates. >> > > I think there's another criticism to be leveled at this proposal, and it's > suitability for this WG - the motivation stated (firewall appliances) is a > question about local policy. I admit my own ignorance here, in that I'm not > sure how https://tools.ietf.org/html/draft-nottingham-for-the-users has > been progressing as a comparable alternative to the HTML Priority of > Constituencies. However, as engineers, we need to recognize that no matter > what is memorialized by the IETF, if you have control over the machine - as > these enterprises inevitably do to install their firewall appliance - all > bets are off. We should not pretend we will prevent that, nor should we > increase costs for the ecosystem in pursuit of that effort. > _______________________________________________ > 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
