Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)

[Shumon Huque <[e-mail]>]

On Wed, Feb 21, 2018 at 12:05 PM, Viktor Dukhovni <[e-mail]>
wrote:

>
>
> > On Feb 21, 2018, at 10:57 AM, Shumon Huque <[e-mail]> wrote:
> >
> > On Thu, Feb 8, 2018 at 11:35 AM, Viktor Dukhovni <[e-mail]>
> 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.