I'm responding to Ben here, because I think it's worth adding some clarity. However, I want to flag that I'm going to be rather short on time for the next few week and not able to spend a lot of time replying to traffic on this topic. Even more than usual, non-response to some point does not necessarily indicate agreement.
On Tue, Oct 16, 2018 at 6:15 PM Benjamin Kaduk <[email protected]> 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. > (2) reduces the ability of an attacker to cause the client to ignore the > server's authentication preference > > I think that just meeting the above two conditions could provide enough > value to merit publishing, even without attempting to add something > like: > > (3) allows the client to realistically hard-fail connections where DNSSEC > validation returns bogus or indeterminate. > I'm not sure I see a meaningful difference between (2) and (3), given that the mechanism for (2) is likely (3). > Getting (1) is probably trivial (though with middleboxes you never > know), and it seems fairly clear that a pinning scheme can provide (2). > Yes, the question is whether such a scheme is worth the other costs that it imposes (in particular, hostile pinning, and in the version that people have currently proposed, the ability to break yourself by inconsistent deployments, though that's at least conceivable fixable). In case it's not clear, I don't agree with Viktor's "no substantial issues have been raised" claim. -Ekr
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
