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

[Eric Rescorla <[e-mail]>]

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.

-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
>