Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)

[Shumon Huque <[e-mail]>]

On Mon, Feb 26, 2018 at 12:19 PM, Viktor Dukhovni <[e-mail]>
wrote:
>
> I think that as it stands, lack of authenticated denial of existence is
> a *fatal* flaw in the protocol.  I just don't see a sufficiently practical
> scenario in which this extension confers a useful security benefit.

Viktor,

Is this a new realization you've recently arrived at? You've been
commenting on this draft for a number of years now, and I have
assumed that you were well aware of the lack of authenticated denial.
In fact, there is text in the Intro section that declares that
this protocol is unsuitable for SMTP/DANE precisely because it
requires confirmation of the existence or not of the TLSA record -
that text came about because of discussion with you.

Several of us were well aware of this during the early days of the
draft, but perhaps many folks did not fully appreciate the impacts
until I elaborated on them last year, and added text that described
the "adversary with fraudulently obtained PKIX credentials" attack.

It is certainly a limitation/flaw. Whether or not it is fatal is
debatable. What this means is that this protocol allows opportunistic
use of DANE authentication, but guarantee of use needs mechanisms
external to the protocol. Section 8 already describes several such
mechanisms that could be employed. So, I think this topic is covered.

This limitation also may not be applicable at all for green field
TLS/DNSSEC applications that can require the use of the extension
unconditionally.

Having an authenticated denial mechanism would allow the TLS client
to have an inband way to enforce DANE authentication if available.
I suspect though that re-introducing a debate on this topic will
lead us into an argument about what it means for a server to publish
a TLSA record. Is it just a mechanism to use the DNSSEC to authenticate
keys and certificates? Or is it also a policy signal that says DANE
must be used? I do not think the latter idea has any consensus in the
IETF currently.


> Perhaps this draft should go back to the working group, to consider a new
> protocol element, by which the server commits to support the extension for
> a time that is substantially longer than the underlying DNS TTLs.  During
> this time (suggested to be weeks or months, when in production after
initial
> testing), the server MUST support the extension and respond with EITHER a
> valid TLSA RRset chain, or with a valid denial of existence.


This is a rather substantial change proposal. It's worth considering,
but I'd like to hear others chime in. But as I said, there are ways
to use this spec and address some of the limitations outside the
protocol today - you can cache and pin knowledge of TLSA existence,
even without an in-protocol commitment, although the latter would be
better. That may be good enough for the first iteration of the protocol.

Note that extending the protocol to incorporate authenticated denial
also means that the chain data would likey need a DNS response code.
That's a stronger argument to move to a full DNS message format (I'll
answer Paul Wouter's specific comments on that topic separately later).

Shumon.