Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Paul Wouters <[e-mail]>]

On Tue, 10 Apr 2018, Willem Toorop wrote:

I just want to clarify one misconception in Willem's statement. See my
previous emails to thist list for my full arguments on this issue.

> The chain extension already contains verification of Denial Of Existence
> proofs, because that is needed for verifying wildcard expansions.

This might confuse people. I am talking about denial of existence of any
TLSA record. You are talking about proof of non-existance of other TLSA
records besides the one you are returning. These are completely
different issues. I just want to ensure people realise when I said we
need proof of non-existence, that people do not read your line "already
contains this" as me being wrong.


> It does not explicitly mention the fallback to non-PKIX with a Denial of
> Existence proof or insecurity proof for the TLSA record, because it is
> (currently) irrelevant when the extension could simply be left out too.

So that's not one bug, but two bugs. Defining them out of scope is not
what we should do. For instance, the document could already assume that
the proof of TLS extension (pinning) is going to be solved elsewhere,
and therefor a full denial of existence proof in this document would be
valuable.

The document does not specify what to do when it does not find a TLSA
record to include. It does state:

     If the server is configured for DANE
    authentication, then it performs the appropriate DNS queries, builds
    the authentication chain, and returns it to the client.

So if the server is configured for DANE, and it only finds denial of
existence proofs of its own TLSA record, what is the expected behaviour?

This hints at returning the proof of non-existence, but clearly even the
authors are now saying they did not mean this and a server is not
required to do this. Clearly the text needs clarification, and if it
then leaves out denial of existence, it needs a justification for that
as well.

Paul