> 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