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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls