Re: [TLS] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps

[Benjamin Kaduk <[e-mail]>]

On Wed, Oct 17, 2018 at 02:48:47PM -0700, Eric Rescorla wrote:
> On Wed, Oct 17, 2018 at 7:40 AM Benjamin Kaduk <[e-mail]> 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 <[e-mail]>
> > 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