Yeah this doesn't seem unreasonable
-Ekr
On Thu, Feb 8, 2018 at 8:35 AM, Viktor Dukhovni <ietf-d...@dukhovni.org>
wrote:
>
>
> > On Feb 8, 2018, at 9:49 AM, Eric Rescorla <e...@rtfm.com> 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.
>
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
