Re: [keyassure] Objective: Restrictive versus Supplementary Models

["Richard L. Barnes" <[e-mail]>]

Fair enough.  Revised version below allows for the possibility of short-circuiting based on exact match with an EE cert.  (Trying to maintain an integral version that can be called for consensus later.)

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

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



On Mar 30, 2011, at 2:27 PM, Eric Rescorla wrote:

> On Wed, Mar 30, 2011 at 2:18 PM, Richard L. Barnes <[e-mail]> wrote:
>> I agree with Ekr and Steve that these are the right goals.  I don't have any further goals to add.  Just trying to re-state in bullet-point form:
>> 
>> 1. Cert-lock / CA-lock
>> 1.1. Use case:
>> 1.1.1. Client initiates TLS connection and gets server cert chain
>> 1.1.2. Client performs normal TLS/PKIX validation on cert chain
>> 1.1.3. Client retrieves DANE records from DNS
>> 1.1.4. DANE records specify EE or CA certs that MUST be present in cert chain
>> 1.1.5. Client verifies that TLS cert chain meets DANE constraints
>> 1.2. Security goal: Defend against issuance of other certs for this domain
>> 1.3. DNSSEC RECOMMENDED, not REQUIRED; attacker can only cause connection failure
>> 
>> 2. Domain-managed authentication
>> 2.1. Use case:
>> 2.1.1. Client retrieves DANE records from DNS
>> 2.1.2. DANE records specify Trust Anchors for PKIX certificate validation
>> 2.1.3. Client adds DANE CA certs to TA store (optionally, drops all others)
>> 2.1.3. Client initiates TLS connection and gets server cert chain
>> 2.1.4. Client performs normal TLS/PKIX validation on cert chain
> 
> I don't think this last point has consensus. Certainly, in the case where the
> certificate in question is the terminal certificate, I think at least
> some people
> don't care if it's invalid from a PKIX perspective.
> 
> -Ekr
> 
>> 2.2. Security goal: Allow TLS to work without pre-configured TAs
>> 2.3. DNSSEC REQUIRED; attacker can insert bogus TAs
>> 
>> 
>> 
>> 
>> 
>> On Mar 30, 2011, at 10:48 AM, Eric Rescorla wrote:
>> 
>>> To follow up on my comments at the microphone, there are two potential
>>> objectives for
>>> technology of this type:
>>> 
>>> 1. Protecting against CA mis-issue (as in CA/cert lock).
>>> 2. Allowing TLS to work without getting a certificate from one of the
>>> established trust
>>> anchors.
>>> 
>>> In the first case, the idea would be that the relying party would go
>>> through its ordinary validation
>>> logic and if that failed, would reject the certificate. However, if
>>> the validation succeeded,
>>> it would check DNS and if that check failed, would then reject the
>>> certificate. Only if both
>>> checks succeeded would the certificate be accepted. [0] The objective
>>> of this type of
>>> mechanism would be simply to defend against unauthorized certificate issuance.
>>> Note that in this case, the DANE data need not be DNSSEC secured,
>>> because an attacker
>>> who tampers with it will solely be able to cause a connection failure,
>>> and in many cases
>>> (TLS, SSH, etc.) an attacker with those capabilities can tamper with
>>> the A record and
>>> block the connection that way.
>>> 
>>> In the second case, the intention is to allow clients to effectively
>>> bypass the existing trust
>>> hierarchy by injecting a new trust point via the DNS. Thus, either the
>>> certificate validation
>>> simply will not be used at all (in the case where a terminal
>>> certificate is provided) or will be
>>> used up to a newly inserted trust anchor. In either case, the
>>> presumptive rationale here
>>> is that it's too inconvenient to deal with the existing CAs and that
>>> DANE will be easier.
>>> This version of DANE *does* need to be protected via DNSSEC because tampering
>>> with these records allows the attacker to impersonate the
>>> authenticating party to the
>>> relying party.
>>> 
>>> 
>>> The draft to some extent conflates these two objectives, since it
>>> *both* injects a new trust
>>> anchor and restricts the list of potential certificates. It does not
>>> allow you to simply restrict
>>> the list of CAs/certificates without also injecting a new trust point.
>>> 
>>> 
>>> Opinion follows:
>>> For my money the most important driving use case for this work is the
>>> first case, for two
>>> reasons. First, it's the more pressing problem since it's not really
>>> *that* hard to get a
>>> certificate from one of the existing CAs, but this also means that we
>>> have to worry about
>>> mis-issue by misbehaving CAs, as we have recently seen. Second, the
>>> incremental deployment
>>> story is much easier, since clients which don't speak DANE will just
>>> not be protected against
>>> attack, whereas in the second case clients which don't speak DANE will
>>> experience certificate
>>> errors when connecting to a DANE-only site.
>>> 
>>> -Ekr
>>> 
>>> 
>>> [0] The checks can be done in either order. This is only for clarity.
>>> _______________________________________________
>>> keyassure mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/keyassure
>> 
>>