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

[Eric Rescorla <[e-mail]>]

Yeah this doesn't seem unreasonable

-Ekr


On Thu, Feb 8, 2018 at 8:35 AM, Viktor Dukhovni <[e-mail]>
wrote:

>
>
> > On Feb 8, 2018, at 9:49 AM, Eric Rescorla <[e-mail]> wrote:
> >
> >> This depends on the mode of DANE in use (i.e. the Certificate Usage
> >> field of the TLSA record). If I recall correctly, this should all be
> >> covered in detail in RFC 7671 ("DANE Updates and Operational Guidance").
> >>
> >> * With DANE-EE, only the EE certificate is matched against the
> >>   certificate data/hash in the TLSA record. There is no CRL/OCSP
> >>   style revocation. Revocation would be performed by removing the
> >>   TLSA record from the DNS.
> >>
> >> * With DANE-TA, the indicated CA certificate referenced in the TLSA
> >>   record may have advertised revocation mechanisms that need to be
> >>   consulted.
> >>
> >> * With PKIX-EE and PKIX-TA modes, the standard PKIX revocation
> mechanisms
> >>   need to be consulted and honored.
> >
> > Well, neither of these modes is useful here, as an attacker will simply
> ignore the
> > extension.
>
> Good point.
>
> Well, if a server publishes "CA constraint" (PKIX-TA(0)) or "service
> certificate constraint" (PKIX-EE(1)) TLSA records, presumably it is
> precisely because they believe that PKIX alone is not enough, and
> would like to require at least one of the specified constraints to
> be satisfied.
>
> So if the records do make it to the client, the client should
> probably honour them if it is doing DANE-based authentication.
>
> However, as you correctly observe, with this in-band TLSA record
> delivery mechanism, an attacker who is able to able PKIX-verifiable
> certificates and keys for the target domain can simply not respond
> with the extension and deliver just the PKIX key material.  So if
> a client is willing to go with just PKIX for servers that don't
> support the extension, then it subject to a "dane-stripping"
> downgrade attack when using this mechanism.
>
> We should also note that clients might cache the obtained TLSA
> records, and so might not accept just PKIX while cached records
> are available, even if TLSA records are stripped on a subsequent
> connection.
>
> But the key question boils down to whether the client is configured
> to *require* DANE for the connection (in which case just PKIX is
> clearly not enough), or whether it is doing a form of "opportunistic
> DANE" (for lack of a better term in this message) with the server
> optionally providing the records, but otherwise the client resorts
> to using just PKIX.
>
> In the "opportunistic DANE" case one might argue that, when PKIX-TA(0)
> or PKIX-EE(1) fail, but PKIX alone would otherwise succeed, the client
> should accept PKIX alone, since a downgrade attack can typically strip
> DANE.  But if the client is caching previously seen TLSA records, then
> the downgrade attack is partially mitigated (for the TTL of the cached
> records).  The client may elect to request new TLSA records before the
> expiration of the previous ones are expired, extending such protection
> until it stops communicating with the server sufficiently regularly to
> be able to keep a copy of unexpired TLSA records in its cache.
>
> So all in all, I think there may be enough merit in rejecting on DANE
> failure, subject to local policy, but the client might elect to trust
> bare PKIX.
>
> For clients that do reject PKIX success based on DANE failure, and
> cache obtained TLSA records, it might have been good to recommend
> refreshing the TLSA records while the cached data is still valid
> (say the smaller of some refresh time or 50% of TTL has expired).
> That way, for a client that keeps communicating regularly may be
> (partially) protected against downgrades.  Perhaps it is too late
> to make such a change at this stage in the document's life-cycle.
>
> 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.
>
>   * "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.
>
> --
>         Viktor.
>
>