> On Oct 17, 2018, at 9:18 AM, Eric Rescorla <e...@rtfm.com> wrote:
>> (1) provides a channel for DANE records that is reliable in the absence of
>> an attack
>
> I think this alone would be worthwhile -- and is the purpose I have always had
> in mind for the draft.
Well, a security mechanism that "works in the absence of attack" looks
rather pointless to me. Cleartext transmission with no authentication
also works in the absence of attack, and yet does not a security mechanism
make. The -07 draft covers only the use-cases where the extension is
mandatory (pin interval of "from now and forever"), all the other use-cases
fail.
> I don't agree with Viktor's "no substantial issues have been
> raised" claim.
Then, please raise them! Just saying "hostile pinning, QED" is
not a substantial issue. We've argued in detail that:
1. This was never the real problem with e.g. HPKP, and the credible
concern is footgun, not "hostile pinning". We've shown that footgun
is not a substantive problem here.
2. We've also argued that even with "hostile pinning" the domain owner
recovers if he is able to deploy the extension (unlike never known
keys with HPKP). And clients that can do real DNSSEC lookups can
always pay the extra latency, and if necessary do DNS over TLS to
1.1.1.1, et. al. to get around last-mile barriers, and thus clear
any unauthorized pins even prior to server-side extension support.
3. And, frankly, I find hostile pinning not a credible threat, and to
the extent that it yields client-visible side-effects of major prior
compromise, I see any resulting tamper-evidence as a feature, not a
bug.
4. Lastly, if nevertheless the "hostile pinning" concern is what makes
or breaks consensus on this draft, then we're OK with introducing
exponential scaling-up (over time) of max pin TTL, which will keep
it reasonably low until the last few years of the scaling horizon.
>From where I stand, mere repetition of "hostile pinning QED" frankly no
longer counts as a responsive objection. :-(
Likewise, mere repetition of a claimed benefit from downgradable DANE
signalling, without explaining why or how this is useful, is also not
a substantive argument to support a claim that the use-cases are served
without downgrade protection. Which additional attacks does such
signalling militate, beyond those already handled by WebPKI? There
would need to be a use-case where:
* The extension is not mandatory.
* Just WebPKI alone does not protect the server.
* WebPKI + downgradable DANE signal protects the server.
I've not seen any such use-case.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
