Subject: [keyassure] Objective: Restrictive versus Supplementary Models

From: Eric Rescorla <[email-masked]>
Date: Wed, 30 Mar 2011 10:48:53 +0200

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.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 30 Mar 2011 04:51:54 -0400 (EDT)

> 2. Allowing TLS to work without getting a certificate from one of the

3. Enhancing privacy by reducing OCSP lookups to CA operators potentially
keeping statistics on these (as proven recently with Comodogate)

Paul

---

From: Yoav Nir <[email-masked]>
Date: Wed, 30 Mar 2011 11:15:23 +0200

> 2. Allowing TLS to work without getting a certificate from one of the

I think the current draft is mostly focused on the second objective. Unless we declare #2 to be a non-goal, a (web) client cannot do the regular PKIX validation of the certificate.

More specifically, with a type-2 certificate (CA cert in the record) you anyway have to validate the EE certificate using regular PKIX procedure, except that you replace the trust anchor store with the CA certificate in the DNS record. This makes sense for the 2nd objective, but not for the first (you could put the Verisign root certificate in the DNS record, but then you're protected from mis-issue only by the other CAs). So with a type #2 record, you get both objectives

With a type-1 certificate (EE cert in the record) you get objective #1, but how is a client to know whether it is intended to just compare bits or also to validate the certificate? As long as objective #2 is not a non-goal, the client can't rely on such a record containing a certificate that can be validated. Maybe we need three types of records: CA certificate, untrusted EE certificate, and PKIX EE certificate. In that case, I don't the what advantage an "untrusted EE certificate" has over bare keys. So maybe it should be: CA certificate, PKIX certificate (that needs to be validated) and bare keys.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 30 Mar 2011 07:13:08 -0400

>>  1. Protecting against CA mis-issue (as in CA/cert lock).

Eric's text provide a good rationale for this, and I think a solid 
rationale is an important part of the requirements spec.  I would be 
a bit more precise, and note that the CAs that pose a threat are the 
TAs configured into the system, any CAs below those TAs, and any 
other CAs that have been accepted by the client as TAs.

>  > 2. Allowing TLS to work without getting a certificate from one of the

right. also, don't we want the TAs acquired via DANE to be treated, 
for the session in question, to be as god as the configured TAs, 
i.e., yield no error messages/  (I'll duck for the moment the issue 
of EV certs and whether we ought
to have a DANE-validated icon, and what color it should be :-).)

>keeping statistics on these (as proven recently with Comodogate)

Presumably #3 applies only to the configured TAs (and their offspring), right?

Steve

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 30 Mar 2011 13:54:48 +0200

> keeping statistics on these (as proven recently with Comodogate)

This is isomorphic to the use of domain-issued certs, case 2 above.  If the TLS server is using a CA-issued cert, the client *should* use OCSP (or a CRL) to make sure it hasn't been revoked.  With a domain-issued cert, there's probably no place to go for OCSP.

--Richard

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 30 Mar 2011 14:18:15 +0200

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
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:

> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 30 Mar 2011 14:27:34 +0200

> 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

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 30 Mar 2011 14:42:48 +0200

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:

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 30 Mar 2011 17:28:22 +0200

>>>>> "Richard" == Richard L Barnes <[email-masked]> 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

---

From: James Cloos <[email-masked]>
Date: Wed, 30 Mar 2011 11:52:41 -0400

>>>>> "ER" == Eric Rescorla <[email-masked]> writes:

ER> 1. Protecting against CA mis-issue (as in CA/cert lock).

I hadn't though of doing this as Eric later describes (such that dnssec
isn't required for this usage).

I can understand how even an unsigned specification that a resource
uses this-and-only-this CA might be an improvement over the status quo.

But isn't false RR injection combined with a matching false cert chain
still a relevant problem in that scenario?

Perhaps the rfc should spec that, but with a threat analysis.

ER> 2. Allowing TLS to work without getting a certificate from one
ER>    of the established trust anchors.

The above said, this is my primary motivation.  Commercial trust anchors
provide little value and significant burden.  

It isn't just about "convenience".

Obviously there is still a lot of third-party trust involved.  You have
to trust that the DS RRs are properly handled by the registrars, root &
tld zone operators, et al.

But we already have to trust them to do the same with the NS glue RRs.

Ie, if the NS glue is mishandled the game is over anyway.  So why not
trust them correctly to handle the DS glue, too?

The one thing that does become significantly more convenient, though,
is more frequent rollover.

Eric's second scenario should be DANE's primary mission.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

---

From: James Cloos <[email-masked]>
Date: Wed, 30 Mar 2011 11:56:36 -0400

>>>>> "RLB" == Richard L Barnes <[email-masked]> writes:

RLB> 1. Cert-lock / CA-lock
RLB> 1.3. DNSSEC RECOMMENDED, not REQUIRED; attacker can only cause connection failure

If the attacker injects fake dns records pointing to a fake server, they
can include a dane rr.  It only makes the attack slightly harder, doesn't it?

-JimC

---

From: Martin Rex <[email-masked]>
Date: Wed, 30 Mar 2011 20:18:37 +0200 (MEST)

Eric Rescorla wrote:
> through its ordinary validation logic and if that failed, would reject
> the certificate. However, if the validation succeeded,
> 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.
> 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.

Maybe I'm dense at the moment, but I don't understand
"the DANE data need not be DNSSEC secured".

Without DNSSEC, you have a vulnerability, because you can not
enforce a CA or EE cert lock.  An attacker can DNS-spoof DANE records
for the mis-issued certs of his choice or DNS-spoof the absence
of DANE records (and the absence of DANE records will be quite
common for more than just a few days).

>    established trust anchors.
>
>  [...]
>
> *both* injects a new trust anchor and restricts the list of potential
> certificates. It does not allow you to simply restrict

Personally, I would also prefer if the information conveyed through
DANE would include a tag that clearly distinguishes "CA/cert lock" (for
a server cert issued under the traditional TLS X.509 PKI of browsers)
from a certificate path validation based solely on DNSSEC trust.

But ultimately, whoever gains control over the DNSSEC zone contents
will be able to preempt the validation under the traditional TLS X.509 PKI
for a server cert by supplying appropriately crafted DNSSEC-signed DANE
records.

Therefore, the existence of DANE will make DNS admins much more interesting
targets for attacks (as an alternative to attacking issuing procedures
of commercial CAs).

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 30 Mar 2011 20:43:46 +0200 (MEST)

Richard L. Barnes wrote:
> This is isomorphic to the use of domain-issued certs, case 2 above.
> If the TLS server is using a CA-issued cert, the client *should* use
> OCSP (or a CRL) to make sure it hasn't been revoked.  With a
> domain-issued cert, there's probably no place to go for OCSP.

Looking at the recent rush of Browser patches to address Commodogate,
I'm somewhat in doubt that certificate revocation ever really worked.

A sufficiently powerful attacker might be able to interfere with
OCSP lookups and CRL download attempts (making them fail at the
network level).  The necessesity to blacklist the mis-issued certs
seems to indicate that most browser did not (and maybe still don't)
check server certs for revocation when encountering a network error
trying to access OCSP or CRL download URLs from the server's cert.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 30 Mar 2011 21:27:31 +0200

> common for more than just a few days).

It's obviously better if DANE is DNSSEC secured, but it's not dangerous
if they aren't signed, since that just brings you back to where you were
without DANE. However, the DANE records can be set with fairly long
expiries (like HSTS), thus providing a partial firewall against comodo-type
problems.

-Ekr

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 30 Mar 2011 21:32:40 +0200

> can include a dane rr.  It only makes the attack slightly harder, doesn't it?

Yes, but as ekr pointed out, injecting fake DANE RRs can only cause the connection to fail, it won't result in the client connecting to a bogus server.   That's why it's RECOMMENDED instead of REQUIRED.

---

From: Jay Daley <[email-masked]>
Date: Thu, 31 Mar 2011 09:06:46 +1300

> Yes, but as ekr pointed out, injecting fake DANE RRs can only cause the connection to fail, it won't result in the client connecting to a bogus server.   That's why it's RECOMMENDED instead of REQU…

That's still potentially a devastating DOS attack if done well and against an important target.  Worthy of a REQUIRED for that alone.

There is also the layer 9 interpretation issue here - if we say that DANE in its entirety requires DNSSEC then that message can be shouted loud and clear, reinforced and hopefully entrenched.  If we say that only some parts need it then people, for entirely fallible reasons, get confused, doubt DANE, can use this to attack DANE and so on.

Jay

-- 
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 30 Mar 2011 22:17:47 +0200

> There is also the layer 9 interpretation issue here - if we say that DANE in its entirety requires DNSSEC then that message can be shouted loud and clear, reinforced and hopefully entrenched.  If w…

I think this is an important consideration. However a relevant
question for a 2119-level MUST seems
to be whether we wish to have this data rejected if not DNSSEC signed.
What's your view on that?

-Ekr

---

From: James Cloos <[email-masked]>
Date: Wed, 30 Mar 2011 16:13:14 -0400

>>>>> "RLB" == Richard L Barnes <[email-masked]> writes:

JC> If the attacker injects fake dns records pointing to a fake server, they
JC> can include a dane rr.  It only makes the attack slightly harder, doesn't it?

RLB> Yes, but as ekr pointed out, injecting fake DANE RRs can only cause
RLB> the connection to fail, it won't result in the client connecting to a
RLB> bogus server.  That's why it's RECOMMENDED instead of REQUIRED.

If an attacker is going to inject fake RRs, they will inject fake A
and/or AAAA RRs too, not only fake dane RRs.

So the attacker will direct the victem to its fake site with its fake
cert tree which matches the fake dane rr.

I don't see how that is any different than the (non-dnssec) status quo.

-JimC

---

From: Jay Daley <[email-masked]>
Date: Thu, 31 Mar 2011 09:27:36 +1300

> What's your view on that?

If unsigned then the data should be ignored.  That exactly maps to the current situation, which gives a clean split between that or using DANE as an all-or-nothing improvement on top of that.  

Jay

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 30 Mar 2011 22:39:57 +0200

To re-focus this discussion, I would just like to point out that whether DNSSEC is REQUIRED or RECOMMENDED is not material to the structure of the use case.  We can have that debate when it comes time to decide on mechanism.

--Richard

---

From: Martin Rex <[email-masked]>
Date: Wed, 30 Mar 2011 23:55:36 +0200 (MEST)

Eric Rescorla wrote:
> 
> Martin Rex <[email-masked]> wrote:
> >

I still don't understand.

As Bruce Schneier says "security must be evaluated not based
on how it works, but on how it fails".

DANE without DNSSEC is a vulnerability by itself, because it can
be abused by an attacker to make things work that shouldn't work
(the trust rooted to DNS case) and can create a false impression
about security that is not provided (the cert/CA lock case).

Verification of unsigned DANE TLSA records may cause a warm
fuzzy feeling for some, but does not provide any security
against a determined and powerful attacker.

Commodogate may have been a government-backed hack.  The may be
more such about which we don't know yet.  They could prevent OCSP-checks
by making the relevant requests fail at the network layer.
Similarly, they could prevent browser updates (with blacklists of
the mis-issued certs) at the network level.  And they could spoof
DNS replies as well.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 31 Mar 2011 00:14:38 +0200

> I still don't understand.

I don't disagree with you about the facts of the situation, merely about how
they should be interpreted..

Best
-Ekr

---

From: Warren Kumari <[email-masked]>
Date: Thu, 31 Mar 2011 01:14:15 +0200

> against a determined and powerful attacker.

I suspect think that you are talking past each other, so I'm going to try provide scenarios (and also make sure I understand):

In Eric's Case / Objective 1 (where DNSSEC might not be needed):
Scenario 1: If I am the operator of example.com and Mallory manages to trick EzCerts into issuing him a cert for example.com.
Let's say that Mallory is powerful, and can monkey with DNS traffic for users behind ISP Foo (and only behind ISP Foo).  If we allow TLSA without DNSSEC to say "Cert X must appear in the path" Malloy can do bad things to users of ISP Foo (by stripping the record, changing it to his, etc). BUT all users NOT behind ISP Foo (and all users of ISP Foo who do DNSSEC validation) will know not to accept Mallory's cert for example.com.   As the operator of example.com, I am unhappy, but I have at least limited the scope of the attack....

Scenario 2: I am the operator of example.com and Eve is has the ability to spoof DNS. She wants to cause a DoS against example.com, so she inserts a "false" TLSA record -- she does this so that users connecting though that path will fail the DANE check and be unable to connect.... This *is* a new DoS vulnerability, but if Eve is in a position to monkey with the DNS / inject DNS she *already* has the ability to cause a DoS by simply changing A / AAAA records, etc.

In both of these (and all the scenarios I can come up with), TLSA without DNSSEC validation doesn't make problems worse, but sometimes makes things better...

I think that Martin's concerns are all in Eric's Case / Objective 2, where DNSSEC *is* required...

> the mis-issued certs) at the network level.  And they could spoof

Yes, but if we allow TLSA without DNSSEC *only for objective / case 1*, "they" can still attack victims for whom they can spoof DNS replies, but at least everyone else if better protected. Obviously TLSA with DNSSEC is far better, but allowing it without does have some benefits (and can be deployed much faster).

W

---

From: Martin Rex <[email-masked]>
Date: Thu, 31 Mar 2011 02:26:21 +0200 (MEST)

Eric Rescorla wrote:
> 
> Jay Daley <[email-masked]> wrote:
> >
> > Richard L. Barnes wrote:
> > >
> > > Yes, but as ekr pointed out, injecting fake DANE RRs can only
> > > cause the connection to fail, it won't result in the client
> > > connecting to a bogus server.   That's why it's RECOMMENDED
> > > instead of REQUIRED.
> >
> > That's still potentially a devastating DOS attack if done well and
> > against an important target.  Worthy of a REQUIRED for that alone.
> >
> > There is also the layer 9 interpretation issue here - if we say that
> > DANE in its entirety requires DNSSEC then that message can be shouted
> > loud and clear, reinforced and hopefully entrenched.  If we say that
> > only some parts need it then people, for entirely fallible reasons,
> > get confused, doubt DANE, can use this to attack DANE and so on.
> 
> question for a 2119-level MUST seems to be whether we wish to have
> this data rejected if not DNSSEC signed.

I'm much less worried about false positives resulting in DoS, which
can be more easily achieved attacking at the network layer (IP, TCP).

What worries me is the false negatives resulting from a
"successful verification" of an unsigned DANE RR.

The prerequisite for a "successful DANE validation" is that the
DANE TLSA record has been DNSSEC validated.  And my concern is that
some GUIs might get that wrong unless the spec is crystal clear
what constitutes a successful DANE validation (DNSSEC required)
and what not.

I'm OK with interpreting even an unsigned TLSA validation failure
as "something is goofy here, abort the connection", but that causes
the DANE validation result to have 3-states "good/not-obviously-bad/bad"
rather than a boolean "good/bad", and a 3-state may get mapped incorrectly
to binary UI indicators (icon present/absent).

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 31 Mar 2011 02:38:59 +0200 (MEST)

> can be more easily achieved attacking at the network layer (IP, TCP).

Actually, a DoS based on spoofing an DANE TLSA record with incorrect
data and a long TTL into a DNS cache might turn out to be devastatingly
effective when unsiged TLSA records are accepted.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 31 Mar 2011 07:07:33 +0200

> effective when unsiged TLSA records are accepted.

How is this different from a spoofed A record with a long TTL?

-Ekr

---

From: Paul Wouters <[email-masked]>
Date: Thu, 31 Mar 2011 03:40:29 -0400 (EDT)

On Wed, 30 Mar 2011, Eric Rescorla wrote:

> without DANE.

That assumes DANE is an addition to PKIX. Once you assume it is a replacement
for PKIX, you can't have DNSSEC being optional. (If you don't agree, let's
have coffee at starbucks and use their wifi :)

Paul

---

From: Paul Wouters <[email-masked]>
Date: Thu, 31 Mar 2011 03:42:05 -0400 (EDT)

> Yes, but as ekr pointed out, injecting fake DANE RRs can only cause the connection to fail, it won't result in the client connecting to a bogus server.   That's why it's RECOMMENDED instead of REQU…

Not if you are a MITM on the wire as well (more star bucks wifi use cases) and
you're directing the user to your own website with a dane rr matching public key.

Paul

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 31 Mar 2011 09:50:08 +0200

> have coffee at starbucks and use their wifi :)

The context has been lost here, but I was talking about the cert lock
application, not the alternate CA application.

-Ekr

---

From: Michael Richardson <[email-masked]>
Date: Thu, 31 Mar 2011 10:16:37 +0200

>>>>> "Warren" == Warren Kumari <[email-masked]> writes:
    Warren> In Eric's Case / Objective 1 (where DNSSEC might not be
    Warren> needed): Scenario 1: If I am the operator of example.com and
    Warren> Mallory manages to trick EzCerts into issuing him a cert for
    Warren> example.com.  Let's say that Mallory is powerful, and can
    Warren> monkey with DNS traffic for users behind ISP Foo (and only
    Warren> behind ISP Foo).  If we allow TLSA without DNSSEC to say
    Warren> "Cert X must appear in the path" Malloy can do bad things to
    Warren> users of ISP Foo (by stripping the record, changing it to
    Warren> his, etc). BUT all users NOT behind ISP Foo (and all users
    Warren> of ISP Foo who do DNSSEC validation) will know not to accept
    Warren> Mallory's cert for example.com.  As the operator of
    Warren> example.com, I am unhappy, but I have at least limited the
    Warren> scope of the attack....

There is an assumption here that the days of widespread DNS cache
poisioning are over.  That Mallory essentially can now only do an
on-path attack on DNS.

I'm not claiming this isn't true, but just stating this assumption.
There are still lots of open recursive resolvers.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 31 Mar 2011 11:15:31 +0200

> you're directing the user to your own website with a dane rr matching public key.

You're confusing the "Cert Lock" and "Install TA" use cases.  If all the server doing is "Cert Lock", then the bogus DANE record will simply cause the client to reject the server's cert and the connection to fail.  In the "Install TA" case, DNSSEC would be REQUIRED, for exactly the reason you note.

--Richard

---

From: Yoav Nir <[email-masked]>
Date: Thu, 31 Mar 2011 11:39:22 +0200

> You're confusing the "Cert Lock" and "Install TA" use cases.  If all the server doing is "Cert Lock", then the bogus DANE record will simply cause the client to reject the server's cert and the con…

So it's really down to 4 cases:
- CA-lock (I only use Verisign)
- Cert-lock (I only use this cert)
- This CA (This is the CA cert that issues my certificate, and it may not be in your TAS)
- This Cert (this is the cert I'll be using, and I'm not promising that you can validate it)

While I see some value in cert-lock, I don't see much value in CA-lock. It would solve Comodogate if I was a customer of another CA, but not if I was a customer of Comodo.

Cert-lock (and CA-lock) are what EKR calls supplementary, while the others are the restrictive. While the sever (and domain owner) can't dictate client policy, they should be able to indicate whether the Certificate (TA or EE) that's in the TLSA record is supposed to be validatable or not. The client (relying party) may have a policy to ignore records that push a non-valid certificate, but if you're going to publish a record with a certificate that you have just issued using openssl on your laptop and expires in 1975, the TLSA record had better reflect that this certificate is just a container for a public key, not something you can chain and validate.

So I think the requirements document should describe EKR's use cases, and require that the TLSA record be able to differentiate between records that are appropriate for the two use cases.

And yes, a certificate from a known CA can be appropriate for both use cases, and I expect that at least initially those would be more popular, as they work with "legacy" relying parties.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 31 Mar 2011 14:38:16 +0200

>>>>> "Yoav" == Yoav Nir <[email-masked]> writes:
    Yoav> So it's really down to 4 cases:
    Yoav> - CA-lock (I only use Verisign)
    Yoav> - Cert-lock (I only use this cert)
    Yoav> - This CA (This is the CA cert that issues my certificate, and
    Yoav> it may not be in your TAS) 

    Yoav> - This Cert (this is the cert I'll be using, and I'm not
    Yoav> promising that you can validate it) 

    Yoav> While I see some value in cert-lock, I don't see much value in
    Yoav> CA-lock. It would solve Comodogate if I was a customer of
    Yoav> another CA, but not if I was a customer of Comodo. 

Presumably, if you were a customer, they would never issue two certs for
the same DN to different customers.

    Yoav> Cert-lock (and CA-lock) are what EKR calls supplementary,
    Yoav> while the others are the restrictive. While the sever (and
    Yoav> domain owner) can't dictate client policy, they should be able
    Yoav> to indicate whether the Certificate (TA or EE) that's in the
    Yoav> TLSA record is supposed to be validatable or not. The client
    Yoav> (relying party) may have a policy to ignore records that push
    Yoav> a non-valid certificate, but if you're going to publish a
    Yoav> record with a certificate that you have just issued using
    Yoav> openssl on your laptop and expires in 1975, the TLSA record
    Yoav> had better reflect that this certificate is just a container
    Yoav> for a public key, not something you can chain and validate. 

So, you are arguing that the protocol must signal the intent.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 31 Mar 2011 15:01:19 +0200

> So, you are arguing that the protocol must signal the intent.

It's not strictly speaking "intent". It's more of an attribute. Either "this certificate of mine, you can use your regular validation techniques" or "this certificate of mine, just make sure you get this one."

Yoav

---

From: Martin Rex <[email-masked]>
Date: Thu, 31 Mar 2011 15:02:10 +0200 (MEST)

> How is this different from a spoofed A record with a long TTL?

In a first round of attack, the attacker inserts a fake unsigned
TLSA record (DNS poisoning) that the victim is accessing with TLS
frequently and where the DNS admin is not using DNSSEC.

After constantly running into validation failures although one is
connecting to the correct server and gets presented the correct
TLS server cert, either his help desk or the victim will disable DANE
or switch to a browser that doesn't have it yet.  At that point
the victim becomes vulnerable to mis-issued certs even for sites
where the DNS admin uses DANE with DNSSEC.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 31 Mar 2011 15:09:30 +0200 (MEST)

Yoav Nir wrote:
> It's not strictly speaking "intent". It's more of an attribute.
> Either "this certificate of mine, you can use your regular validation
> techniques" or "this certificate of mine, just make sure you get this one."

I also think that leaving it up to the client to make assumptions
about what type of TLS Server cert validation scheme should be used
is likely going to result in a lot of bad decisions among the
implementors.

If the TLSA record includes the information on the intended validation
scheme for this information, then there is going to be more consistency
among the implementations.

When a particular HTML page renders without apparent problems in
one particular web browser, this is no proof that the page is correctly
formed and can be expected to render without problems in other
browsers as well.

-Martin

---

From: Yoav Nir <[email-masked]>
Date: Thu, 31 Mar 2011 15:28:54 +0200

> formed and can be expected to render without problems in other

Just as long as we avoid the rat-hole of calling it "policy"

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 31 Mar 2011 15:29:18 +0200

So it's a social engineering attack?  Might as well just send an email trojan.

This is the same result as
-- Hijacking the TCP session and feeding in a fake cert 
-- Spoofing the A record and sending the client to the wrong host (like ekr said)

--Richard

---

From: Martin Rex <[email-masked]>
Date: Thu, 31 Mar 2011 15:36:41 +0200 (MEST)

> -- Spoofing the A record and sending the client to the wrong host (like ekr said)

To me, processing unsigned TLSA records is similar to
processing unsigned OCSP responses or unsigned CRLs.
I would not do the latter, and I'm in doubt that the former
is a good idea.

-Martin

---

From: James Cloos <[email-masked]>
Date: Thu, 31 Mar 2011 10:02:48 -0400

>>>>> "MR" == Martin Rex <[email-masked]> writes:

MR> In a first round of attack, the attacker inserts a fake unsigned
MR> TLSA record (DNS poisoning) that the victim is accessing with TLS
MR> frequently and where the DNS admin is not using DNSSEC.

Why would an attacker insert a fake tlsa w/o a matching fake a or aaaa?

More likely they inject both and send the user off to a fake site with
matching fake credentials.

The client software might notice that the creds have changed since the
last time it visited (/if/ it has ever visited), but how many do that
for longer than a "session"?  Any?

Without dane the attacker just does the fake a/aaaa, fake server and
fake cert an still wins.  So it isn't a regression.  But dtls w/o
dnssec doesn't actually help either.

Injecting a dtls w/o also injecting other fake RRs might get done as
a lark, but any real attacks will be more sophisticated.

-JimC