On Wed, Oct 17, 2018 at 06:18:27AM -0700, Eric Rescorla wrote: > 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 <bka...@akamai.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.
It's interesting to hear that, as I seem to recall a lot of discussion about how a security mechanism that folds in the presence of an attack .... isn't really a security mechanism. So while I could concoct a few scenarios in which just (1) would be *useful*, the main one that comes to mind isn't really a security mechanism, but would rather be part of a reporting mechanism for seeing what kind of DANE penetration is possible. Well, and I guess any case where the client has some other reason to expect to see this extension and choke if it's absent, such as a "greenfield" case or application-level pinning. So I'm curious what kind of use case(s) you had in mind for just the transport aspect. > > > > (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). Mostly I'm just claiming that the "realistically" in (3) is weasel-words that we don't need to get involved with at the protocol level. Whether or not to hard-fail is an application decision that we don't need to mandate. > > > 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. Seeing as you are busy the next few weeks, perhaps I can ask the chairs to go through the email history and summarize these substantial issues that have been raised -- I am not confident that I could reproduce them from memory, myself. -Ben _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
