> On Apr 12, 2018, at 2:44 PM, John Gilmore <g...@toad.com> wrote:
>
> If any ever did, the future RFC could specify
> how servers which do not have validated TLSA records should handle the
> situation.
They'd have to violate the text of this draft:
> Different future protocols might choose different ways
> to handle this (e.g. don't send the extension at all; or send a validated
> denial;
The draft precludes sending denial of existence in Section 3.4 which
requires to the first RRset to be the requested TLSA records. Hence
option (A) in the initial last-call announcement.
> or send some kind of flag saying that the server doesn't even have
> a validated denial because it isn't using DNS
That'd be vulnerable to downgrade, defeating the purpose of this
extension to support DANE.
> or because some domain on
> its path to the DNS root isn't doing DNSSEC or isn't using NSECx records).
This can be handled by sending denial of existence. The denial of existence
can either prove lack of TLSA records in the server's signed zone, or can
prove lack of signatures on that zone.
>
> Please, let this RFC go, rather than requiring that this committee
> first insert into it a paper spec for what some future protocol should
> do, without even knowing what the future protocol is.
The present draft limits its own applicability, and neither (A) nor (C)
close off future options. Indeed (A) specifically lifts an unfortunate
restriction, and (C) provides additional information from the server that
would be quite useful to clients. It is hard to see how either preëmpt
future use-cases.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
