Re: [TLS] [dane] Consensus Call on draft-ietf-tls-dnssec-chain-extension [AT LEAST (A)]
> On Apr 12, 2018, at 2:44 PM, John Gilmore wrote: > > Viktor, I believe you have confused a "could" with a "mandate". As to this point, I'm not now and have never been confused about that. The present draft, as explained upthread, perhaps in too many ways and in too many words, offers no value to applications that don't mandate the use of the extension, if the application also excepts WebPKI, and the extension is optional, then a cost/benefit analysis shows that use of the DANE extension offers only complexity and no security benefit. Opportunistic use-cases of the present draft won't get deployed, they make no sense. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [dane] Consensus Call on draft-ietf-tls-dnssec-chain-extension [AT LEAST (A)]
> On Apr 12, 2018, at 2:44 PM, John Gilmore 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
Re: [TLS] [dane] Consensus Call on draft-ietf-tls-dnssec-chain-extension [AT LEAST (A)]
> * 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. Viktor, I believe you have confused a "could" with a "mandate". The text of this RFC does not require future green field applications to mandate the use of this exension. It merely allows them to do so. None need ever do so. If any ever did, the future RFC could specify how servers which do not have validated TLSA records should handle the situation. Different future protocols might choose different ways to handle this (e.g. don't send the extension at all; or send a validated denial; or send some kind of flag saying that the server doesn't even have a validated denial because it isn't using DNS or because some domain on its path to the DNS root isn't doing DNSSEC or isn't using NSECx records). 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. John ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
