On Wed, Feb 21, 2018 at 12:05 PM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:
> > > > On Feb 21, 2018, at 10:57 AM, Shumon Huque <shu...@gmail.com> wrote: > > > > On Thu, Feb 8, 2018 at 11:35 AM, Viktor Dukhovni <ietf-d...@dukhovni.org> > wrote: > > > > Summary as I see it: > > > > * Mandatory DANE: MUST Refuse absence of TLSA RRs or failure > > of PKIX-TA(0) and PKIX-EE(1). Must fail when no TLSA RRs > > are cache and the server does not present the extension. > > Just to clarify "failure of PKIX-TA(0) and PKIX-EE(1)" is intended to > consider failure to satisfy the usual PKIX verification requirements > for these certificate usages. Naturally, mandatory DANE can also be > satisfied via matching DANE-TA(2) or DANE-EE(3) or fail via broken > > DANE-TA(2) or DANE-EE(3). > Yup, I understood, but thanks for clarifying ... > > > > * "Opportunistic DANE": MAY refuse failed PKIX-TA(0) and PKIX(1) > > if caching replies, and SHOULD attempt to refresh cache before > > expiration to reduce opportunity for downgrades. Non-caching > > clients don't really gain security by refusing valid PKIX on > > DANE failure, and MAY choose to continue. > > > > This seems reasonable to me too. > > Here too, a client MAY choose to fail when the presented certificate > chain fails all the associated (cached or freshly obtained) DANE TLSA > records whether these are PKIX-TA/EE, DANE-TA/EE or some mixture. > The restricted focus on just PKIX-TA/PKIX-EE is not needed. > Yes, no need to restrict such a policy choice to only the PKIX-* modes. Shumon.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
