> 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
