> On Apr 4, 2018, at 1:50 PM, Joseph Salowey <j...@salowey.net> wrote:
>
> If the answer to 1) is no then please indicate if you think the working group
> should work on the document to include
>
> A) Recommendation of adding denial of existence proofs in the chain provided
> by the extension
> B) Adding signaling to require the use of this extension for a period of time
> (Pinning with TTL)
> C) Both
While I am a vocal supporter of (C), I'd like to take a moment to explain why
AT LEAST (A)
is needed.
* The present text requires (Section 3.4) that the server's response
present a validated TLSA RRset:
The first RRset in the chain MUST contain the TLSA record set
being presented
* The present text (Section 8) says:
Green field applications that are designed to always employ this
extension, could of course unconditionally mandate its use.
Therefore such "green field" applications (presumably some of the ones
ready to implement now) effectively mandate DNSSEC and TLSA records
at the server, NOT JUST support for the extension.
This needlessly limits the usability of such applications. The
server domain cannot continue to support the extension and
interoperate with the client if it at some points decides to
stop publishing TLSA records or perhaps even stop using DNSSEC.
It makes a lot more sense for servers to be able to continue to
support the extension, but respond with denial of existence when
when the have no TLSA records or the zone is unsigned (no DS
RRs at some ancestor). That way a server can communicate its
change of status to a client, which may *then* be willing to
accept alternative authentication (WebPKI, for example).
Option (A) does not change the wire formats, it just relaxes
the requirement to provide TLSA records, and would allow or
encourage the server to return whatever is the truth about
its TLSA records (presense, absence or unsigned zone). The
client can then act accordingly.
Just (A) would of course still many clients in the dark about
when it might be safe to "mandate" the extension for particular
domains, and I'd be sad about that (if anyone cares :-), but it
is important to realize that not doing (A) is a significant
omission.
I'd like to encourage the authors and WG to amend the draft to
relax section 3.4 to allow (and encourage when applicable)
denial of existence replies. This would better serve the
"green field" applications that would like to avail themselves
of this extension and require it of all servers, whether they
have DNSSEC and TLSA records or not.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
