Joni,
Paul is right on target with this: On 2/24/14 1:48 PM, "Paul Wouters" <[email protected]> wrote: >If your zone is signed, and you publish a TLSA record, then you would >be proteced (providing apple does not screw up this code either) > >An attacker can with-hold or modify the TLSA DMSSEC record, which should >cause the TLS implementation to hard fail. If the attacker lets the TLSA >record through, then your TLS client knows what to expect, and should >abort when it is something unexpected. > >Note though, that TLSA can pin either the CA or the EE cert. If you pin >the CA cert, then an attacker could just get _any_ cert from the same CA >and still subvert you. If you had choosen to pin the EE cert, then the >attack would have failed completely. What he's talking about with the TLSA record is what is known perhaps more widely as "DANE" or "the DANE protocol", where "DANE" is an IETF acronym that expands into "DNS-based Authentication of Named Entities" and is detailed in RFC 6698: http://tools.ietf.org/html/rfc6698 We put some more info up at: http://www.internetsociety.org/deploy360/resources/dane/ Regards, Dan P.S. Thanks, Paul, for pointing out the CA vs EE cert point. In some quick thoughts about this scenario I hadn't recalled the issue with pinning only the CA. -- Dan York Senior Content Strategist, Internet Society [email protected] <mailto:[email protected]> +1-802-735-1624 Jabber: [email protected] <mailto:[email protected]> Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/deploy360/ _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
