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

[Shumon Huque <[e-mail]>]

On Tue, Apr 10, 2018 at 11:22 AM, Paul Wouters <[e-mail]> wrote:

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


Personally, I would be okay with relaxing/clarifying the language in the
draft a bit so that it does not rule out the possibility that a DNSSEC
(NSEC/NSEC3) chain corresponding to an NXDOMAIN or NODATA response can be
returned.

I wonder if that, together with a new extension that can convey DANE
pinning information is a way forward ..

-- 
Shumon Huque