On Sat, Apr 28, 2018 at 2:17 PM, Richard Barnes <[email protected]> wrote: > > > On Sat, Apr 28, 2018 at 1:52 PM Viktor Dukhovni <[email protected]> > wrote: > >> >> >> > On Apr 28, 2018, at 12:19 PM, Shumon Huque <[email protected]> wrote: >> > >> > This specification can also be used to optionally convey >> > authenticated denial of existence of TLSA records. Restrictive uses >> > that might require such proofs (such as the PKIX constraining modes >> > of DANE, or where DANE should always be preferred over other modes of >> > authentication such as traditional PKIX) are thus not in its intended >> > scope. Such restrictive uses can however be supported >> > opportunistically. >> >> The last sentence makes no sense. The term "Restrictive uses" is poorly >> defined. The reduction in scope is effectively a reduction to just the >> cases where the extension is mandatory, if that's what you intend to do >> then say so (expect pushback). >> > Yeah, I agree the assertive and restrictive terms are poorly defined. I was using terminology that this WG has been using for a while, but we can reword.
> >> Please do not imply that any non-mandatory "additive" use-cases are >> viable. They are not. >> > > I agree with Viktor here. > > You could imagine enforcing a restriction you see in a DANE extension the > cert you get milliseconds later, but that's pretty useless given that an > attacker can just not send the extension. Let's just scope this to the > additive case. > > This mean "additive" mandatory or non-mandatory, I assume. Viktor opposes the latter case, I assume based on his (unproven) assertion that there will no incentive to deploy this. I don't agree. Lots of sites already publish DANE for HTTPS records even before browsers can use them (IETF, freebsd, debian, torproject, defcon, ripe, etc). Once code is implemented/deployed they will be using it. Shumon.
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
