On Wed, Oct 17, 2018 at 02:48:47PM -0700, Eric Rescorla wrote: > 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.
Hardly. In particular, I was asking what *you* had in mind -- my listing was intended to be more of a "straw man" sort of thing. -Ben _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
