On Tue, Apr 10, 2018 at 11:22 AM, Paul Wouters <p...@nohats.ca> 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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
