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). > > 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. > > -- > Viktor. > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
