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

[Benjamin Kaduk <[e-mail]>]

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.

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