Re: [keyassure] Objective: Restrictive versus Supplementary Models

[Michael Richardson <[e-mail]>]

>>>>> "Richard" == Richard L Barnes <[e-mail]> writes:
    Richard> Fair enough.  Revised version below allows for the
    Richard> possibility of short-circuiting based on exact match with
    Richard> an EE cert.  (Trying to maintain an integral version that
    Richard> can be called for consensus later.) 

okay, but is there a bit that tells the client which case they are
trying to implement?  Or do we even need such a thing?

Paul and I were discussing things from the point of view that the client
does one process only, and that it has to work for both cases.

1. client looks up A/AAAA record. DNSSEC recommended. If no DNSSEC,
          attacker can mis-direct connection.
2a. client initiates TCP socket to target. (Attacker may do IP-level
    redirection, even if A/AAAA is correct)
2b. client looks up DANE/TLSA record (if any).
3. If TLSA found, client adds DANE CA and/or EE certs to TA store,
   dropping all others (*)
4. Client performs normal TLS/PKIX checks.

This is secure for domain-managed authentication if DNSSEC.
This is is also secure for cert-lock even in the face of Comodogate.

This may fail for some corporate environments where there is a forced
proxy of all TLS connections to some auditing firewall device.
Apparently some vendors let you force new sets of trust anchors
to desktops so that the desktops will wind up trusting the official
man-in-the-middle device.   If in step 3, one drops that trust anchor,
then the MitM is detected.  This may be a feature or not.

The question that we came up with was: is the act of dropping other
trust anchors something that should be controlled by the owner the
domain via the TLSA record, or is this a question of local policy?

You *HAVE* to drop them to get the cert-lock to be effective.

    Richard> 1. Cert-lock / CA-lock
    Richard> 1.1. Use case:
    Richard> 1.1.1. Client initiates TLS connection and gets server cert chain
    Richard> 1.1.2. Client performs normal TLS/PKIX validation on cert chain
    Richard> 1.1.3. Client retrieves DANE records from DNS
    Richard> 1.1.4. DANE records specify EE or CA certs that MUST be present in cert chain
    Richard> 1.1.5. Client verifies that TLS cert chain meets DANE constraints
    Richard> 1.2. Security goal: Defend against issuance of other certs for this domain
    Richard> 1.3. DNSSEC RECOMMENDED, not REQUIRED; attacker can only cause connection failure

    Richard> 2. Domain-managed authentication
    Richard> 2.1. Use case:
    Richard> 2.1.1. Client retrieves DANE records from DNS
    Richard> 2.1.2. DANE records specify Trust Anchors for PKIX certificate validation
    Richard> 2.1.3. Client adds DANE CA certs to TA store (optionally, drops all others)
    Richard> 2.1.3. [TBD] If DANE provides EE cert, accept/reject based on exact match
    Richard> 2.1.4. Client initiates TLS connection and gets server cert chain
    Richard> 2.1.5. Client performs normal TLS/PKIX validation on cert chain
    Richard> 2.2. Security goal: Allow TLS to work without pre-configured TAs
    Richard> 2.3. DNSSEC REQUIRED; attacker can insert bogus TAs