Subject: Re: [dane] Starting WGLC on: draft-ietf-dane-use-cases-02

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 24 Jun 2011 11:19:46 -0400

Hey Matt,

Sorry I missed these earlier.  I think they're ultimately mostly addressed by revisions in the new document.  Some responses inline.

--Richard

> - The security considerations in Section 3.1 could be clarified.  Here
> is some alternative text as inspiration:

I think this comment is addressed by the revised security considerations in 3.1.  They're not quite as detailed as your suggested text, but they capture the basic bounds of  the problem.

> - This text does not belong in Section 3.3:
> 
>   Deleted records
>   will only result in connection failure and denial of service,
>   although this could result in clients re-connecting without TLS (a
>   downgrade attack), depending on the application.  Therefore, in order
>   for this use case to be safe, applications must forbid clients from
>   falling back to unsecured channels when records appear to have been
>   deleted (e.g., when a missing record has no NSEC or NSEC3 record).
> 
> Preventing a downgrade from TLS to non-TLS is, strictly speaking, an
> orthogonal issue to TLS server authentication.  My understanding was
> that the scope of DANE was only the latter, and the former would be
> addressed with HASTLS or some such.  If the downgrade prevention is to
> be mentioned here, it should be its own use case; it is not in any way
> specific to the use of domain-issued certificates.

You're correct that downgrade is an issue that applications need to address, but it is something that DANE should keep in mind.  I think the solution is pretty simple -- just require the use of NSEC/NSEC3, which is already standard practice for DNSSEC.

> - Re the newfound power of DNSSEC zone operators under DANE (Section
> 3.3): I would not attempt to minimize this issue.  CAs will not hesitate
> to remind us of the extra checks they perform for certain sites, so the
> comparison to domain validation is not entirely correct.  Sites that
> have special relationships with CAs but do not have proper oversight of
> their DNSSEC zones will, indeed, have their security weakened when
> clients adopt DANE.  If we are concerned about this, I think the natural
> solution is to have a flag with each DNSSEC delegation that indicates
> that the registrant fully trusts the child zone operator and hence
> schemes such as DANE can be enabled.

I've tried to moderate this section in the new version, in particular:
"
It should be noted that DNS operators already have the ability to obtain certificates for domains under their control, under certain CA policies.
"

> - Section 3.4: I don't understand the motivation for constraining the
> certificates used by an outsourcing provider.  If the provider is
> operating the service, what security benefit can there be to forcing the
> provider to use a particular certificate?  Is this something I missed in
> the discussion?

Couple of examples:
- Alice is concerned that Oscar might use a certificate that contains a public key for which a third party (police, criminal associates) also has the private keys, as a way of indirectly exposing Alice's traffic.
- Alice is concerned that Oscar might use a certificate that contains a public key that uses a weaker cryptographic algorithm than Alice requires (say 1024-bit instead of 2048-bit RSA).
- Alice is concerned that Oscar present a DV cert instead of the EV cert she provided him.

--Richard

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 24 Jun 2011 13:25:55 -0400

On Fri, Jun 24, 2011 at 11:19 AM, Richard L. Barnes <[email-masked]> wrote:

> You're correct that downgrade is an issue that applications need to
> address, but it is something that DANE should keep in mind.  I think the
> solution is pretty simple -- just require the use of NSEC/NSEC3, which is
> already standard practice for DNSSEC

I agree on the requirement. But I completely disagree on the proposal.

At the moment we have at least four levels of security either on the
Internet or in discussion in IETF:

0) No security
1) Domain Validated Security
2) Domain Validated + Organizational (inc. EV)
3) 'Strict' Security

I don't like the idea of having DANE be an implicit protection against
downgrade because I want there to be the option of a more thorough downgrade
protection.

It would also mean a big change to browsers. It would require the browser to
check DANE records on every HTTP transaction and not just when HTTPS is
specified.

We could argue that the DV/EV type difference can be dealt with by having
DANE implicitly endorsing the relevant certificate. But that leaves a lot
out of consideration, including the strict security work by Jeff Hodges and
others

Also, there are going to be cases where flaws are discovered in TLS or other
protocols and when those get patched it is going to be necessary to specify
that a particular version of TLS is in use.

The tag mechanism of CAA is designed to allow for this type of assertion to
be made. So there could be a property https that takes a text field that
then has an internal structure to allow the relevant properties to be
declared (always/required/refused + min version no.)

Pushing it off into a separate feature also allows the group to move much
faster as it is not necessary to go into interminable discusion of how the
feature needs to work and what is essential. If something important is
missed out it can be added later. If the requirement to use TLS is implicit,
there can only be one set of implicit criteria.

Another point here is the desire to support promiscuous security. In ESRV I
propose a mechanism that is designed to be called every time a Web browser
attempts to connect to a server. If the server says that TLS is always
offered, it will transparently upgrade.

-- 
Website: http://hallambaker.com/

---

From: Martin Rex <[email-masked]>
Date: Fri, 24 Jun 2011 19:53:21 +0200 (MEST)

Phillip Hallam-Baker wrote:
> downgrade

I do.

>
> because I want there to be the option of a more thorough
> downgrade protection.

I fail to understand.

DANE (with DNSSEC) protects against downgrade of server endpoint
identification and it is entirely impossible to get any stronger
than DANE (the latter is formally provable).

> check DANE records on every HTTP transaction and not just when HTTPS is

I fail to understand.

Since it is possible to replay DNSSEC records for as long as the RRSIG
validity specifies without the resolver being able to notice, caching
TLSA DNS records as well as processing results is trivial and
straightforward.

Certainly a magnitude easier than any of the PKIX revocation processing.

> out of consideration, including the strict security work by Jeff Hodges and

The way server endpoint identification for TLS is defined in
rfc2818 and rfc6125, there is *ZERO* difference between EV, OV and DV.
Any additional attributes vetted for in OV in EV certs matter only to
human users of browsers that provide fancy/colorful chome feedback
about additional OV/EV cert attributes beyond the server endpoint
identification -- if they matter at all (which often, they don't).

> 
> Also, there are going to be cases where flaws are discovered in TLS
> or other protocols and when those get patched it is going to be
> necessary to specify that a particular version of TLS is in use.

Complete non-issue.

DANE is orthogonal to TLS, and server endpoint identification is
*EXPLICITLY* out-of-scope for TLS in every TLS spec in existence.
(Check out the last sentence of Section 1 "Introduction" of 
your favorite TLS spec (rfc2246, rfc4346, rfc5246).

> offered, it will transparently upgrade.

That is commonly done via HTTP 302 or META REFRESH to a https:// address.

What you suggest here sound like:

I'm surfing a trusted resource via https://place-a/some/path that contains
an A HREF=http://place-b/some/path and you suggest that your browser
should connect to https://place-c/some/path instead, based on a
DNS record for place-a?   I hope you see the imperative for
a valid DNSSEC signature of such a DNS record -- but ultimately
this appears to be a security defect in the original resource
https://place-a/some/path that really ought to be fixed there
(and how it will work for all of the installed base already today).

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 24 Jun 2011 20:34:28 +0200 (MEST)

Ooops, typo:  I meant to write "DNS record for place-b" (already fixed below):

> should connect to https://place-c/some/path instead, based on a
! DNS record for place-b?   I hope you see the imperative for

-Martin

---

From: Matt McCutchen <[email-masked]>
Date: Sat, 25 Jun 2011 23:31:34 -0400

On Fri, 2011-06-24 at 11:19 -0400, Richard L. Barnes wrote:
> I think this comment is addressed by the revised security
> considerations in 3.1.  They're not quite as detailed as your
> suggested text, but they capture the basic bounds of  the problem.

I wouldn't consider my text more detailed, but rather more precisely
stated and free of controversial side remarks.  E.g., what does
"increase the scope of PKIX-based assertions about domains" mean, and
what does it mean for there to "be" a strict requirement for DNSSEC?  If
I weren't already deeply engaged in the WG, I would probably have to
come to my own understanding of the situation and then realize that was
what you were talking about.  Compare to "Because these constraints do
not increase the set of cases in which server authentication succeeds,
no security is lost by processing the records even if they are retrieved
without DNSSEC," where the logic of the implication is clear.

Why ever would we not use the more precise text?

> address, but it is something that DANE should keep in mind.  I think
> the solution is pretty simple -- just require the use of NSEC/NSEC3,
> which is already standard practice for DNSSEC.

"Downgrade" is not a single issue, but rather an issue to be considered
in the context of each mechanism.  The scope of DANE is acceptance
testing of TLS server credentials, including downgrade prevention for
that process.  Choice of TLS or non-TLS, including downgrade prevention
for that process, is out of scope of DANE and will most likely be
addressed by HASTLS.

It sounds like your concern here is that if an attacker deletes a
positive DANE assertion, the client may consider the TLS service broken
and fall back to non-TLS.  But there's a much more basic attack:
intercept the TLS connection and replace the certificate with a
completely bogus one, or flip some bits so the record MAC fails, or
whatever.  Clients that fall back to non-TLS on a TLS failure are
vulnerable to downgrade, period; this has nothing whatsoever to do with
DANE.

If you want to discuss downgrade of TLS server authentication, deletion
of positive assertions isn't it: it reduces the set of cases in which
server authentication succeeds.  Deletion of restrictive assertions
(sections 3.1 and 3.2) is.  But referring to NSEC/NSEC3 is a gratuitous
violation of abstraction; instead, refer to an RFC 4033 "insecure"
response as distinguished from "bogus", as in my text.

> It should be noted that DNS operators already have the ability to obtain certificates for domains under their control, under certain CA policies.

But for traditional "high-value domains", none of the public CAs would
apply those policies (or at least so they would have us think), so the
potential for weakening of security is real.

> - Alice is concerned that Oscar might use a certificate that contains
> a public key for which a third party (police, criminal associates)
> also has the private keys, as a way of indirectly exposing Alice's
> traffic.
> - Alice is concerned that Oscar might use a certificate that contains
> a public key that uses a weaker cryptographic algorithm than Alice
> requires (say 1024-bit instead of 2048-bit RSA).

Is Alice concerned that Oscar might post the master secret on his web
site?  If Oscar wants to compromise the session, Alice cannot stop him.

> - Alice is concerned that Oscar present a DV cert instead of the EV

What attack is prevented by requiring Oscar to use the EV cert?

DANE is about security.  If what Alice wants is to meddle in Oscar's
operations, she can operate the DNS zone.

-- 
Matt

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 26 Jun 2011 00:18:17 -0400

If we are choosing between mechanism A and mechanism B the ability of
mechanism A to support use cases that are out of scope while B is
intentionally limited to scope has me thinking we should go for A.

Thus I don't see the validity of an argument that goes 'yes we know there is
more to downgrade than use of TLS but we are only going to address that one
issue that is in scope and do so in a way that cannot be extended to solve
the whole problem'.

As an adopter I would look at a DANE spec that only does half the job and
say 'no thank you' because I know that adopting it is a dead end that is not
going to lead to a full solution.

We have the following options to address downgrade attack

1) Only do prevention of TLS downgrade as proposed in a way that cannot be
extended.

2) Not do it at all but leave an extension mechanism that allows other
aspects to be addressed later on.

3) Only do prevention of TLS downgrade as proposed but have an extension
mechanism

4) Do the full downgrade problem including an extension mechanism.

The most expeditious approach is 2 since all we have to do is convince
ourselves we can address it later.

Options 2,3,4 all allow the job to be done properly.

On Sat, Jun 25, 2011 at 11:31 PM, Matt McCutchen <[email-masked]>wrote:

> > It should be noted that DNS operators already have the ability to obtain
> certificates for domains under their control, under certain CA policies.
> > "
>
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

---

From: Matt McCutchen <[email-masked]>
Date: Sun, 26 Jun 2011 11:12:06 -0400

On Sun, 2011-06-26 at 00:18 -0400, Phillip Hallam-Baker wrote:
> Thus I don't see the validity of an argument that goes 'yes we know
> there is more to downgrade than use of TLS

I think you mean "choice of TLS certificates".

> but we are only going to address that one issue that is in scope and
> do so in a way that cannot be extended to solve the whole problem'.

In most of the "general use" clients DANE is primarily designed to
support, the decision to use TLS is decoupled from the decision of what
server certificates to accept.  E.g., in a web browser, the use of TLS
is specified by the "https" URI scheme.  The division of work between
DANE and HASTLS simply mirrors this aspect of application design.

What makes you think that the whole problem has to be solved by a single
measure?  Consider this analogy: to prevent your office from being
burglarized, you have to close and lock the door, but the door closer
and the lock are different devices.

> As an adopter I would look at a DANE spec that only does half the job
> and say 'no thank you' because I know that adopting it is a dead end
> that is not going to lead to a full solution.

Nonsense.  Adopting DANE will already protect users who have bookmarked
a "https" URI (or the equivalent in other applications), as I generally
do.  When HASTLS gets standardized, you can just add another record to
your zone to advertise the availability of TLS and encourage its use.
You can call HASTLS an extension of DANE if you like; it doesn't matter,
the outcome is the same.

-- 
Matt