On Wed, Oct 17, 2018 at 7:40 AM Benjamin Kaduk <bka...@akamai.com> wrote:
> 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. > Given that you just described at least two use cases, I feel like you've answered your own question here. -Ekr > > > > > > > (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
