On Sat, Apr 28, 2018 at 1:52 PM Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:
> > > > On Apr 28, 2018, at 12:19 PM, Shumon Huque <shu...@gmail.com> 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 > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
