Subject: [TLS] Cert Enumeration and Key Assurance With DNSSEC

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 1 Oct 2010 11:29:35 -0400

For the past month I have been participating in the KEYASSURE discussions.

One aspect of those discussions that was not made clear in the original
notice sent out is that the group is not only considering key assurance, the
proposals made are also intended to have security policy semantics.

This was not apparent to me from reading the list announcement, the initial
proposed charter or the Internet drafts. I have asked the organizers of the
group to clarify the matter in the wider IETF community but they have not
done so.

In particular I am very concerned about the particular approach being taken
to security policy. What the proposers are attempting to do is to create a
mechanism that allows a site that only uses one particular high assurance CA
to 'protect' themselves against SSL certificates being issued by low
assurance CAs.

As such, this is an objective I approve of and is one that I would like to
see supported in a generalized security policy. It should be possible for a
site to make security policy statements of the form 'all valid PKIX certs
for example.com have cert X in the validation path'.

What I object to is the approach being taken which is to use DNSSEC to
replace PKIX certificate validation entirely.

Now the proponents are trying to downplay this by saying that 'all' they are
doing is to tell people to 'ignore' PKIX validation. But that approach
really offends my sense of layering.

Worse still, the proponents refuse to allow any method of shutting this
system off. So if I have a site where I want to use DNSSEC validated
certificates on the mail server, deployment is going to impact my Web
server.

Specifically the proposal amounts to using the DNS CERT record to publish a
fingerprint of all the certificates permitted for use with TLS at a specific
domain:

example.com CERT TLSFP 0 0 <digest cert 1>
example.com CERT TLSFP 0 0 <digest cert 2>

It is proposed to replace current TLS certificate processing semantics with
the following:

1) Query for CERT record at example.com
2) If no CERT record with TLSFP certificate type exists then perform normal
PKIX validation and return that result
3) Otherwise attempt to match the TLS end entity certificate with one of the
fingerprints specified in the published TLSFP RRs
4) If a match is found return VALID, otherwise return INVALID

Note here that if there is a TLSFP RR that it takes precedence over PKIX
processing rules.

There should of course be DNSSEC validation performed in that process as
well, but the authors have not explained how that is meant to work in the
context of their proposal so I left it out.

The defenses made for this approach are of the form 'you have to wear big
pants to play this game'. In other words if people are going to administer
these systems and not be burned they are going to have to understand what
they are doing. I do not consider this a responsible approach to protocol
design.

What I would prefer is to have systems that do not need to be administered
by people at all. That is not possible when the approach has hidden side
effects that cannot be anticipated by scripts.

I am very much committed to the idea of doing security policy. But this is
not an approach I can support. Any policy mechanism has to be orthogonal to
the key validation strategy in my view. I should be able to use any DNS
security policy mechanism that the IETF endorses with PKIX certificate
processing semantics.

I have proposed an alternative approach in

http://tools.ietf.org/html/draft-hallambaker-esrv-00

This does not currently contain a mechanism to express trust restrictions
but is designed to be extensible to support such. When I proposed ESRV I was
unaware that the KEYASSURE proposal was intended to have a security policy
aspect at all. It is still not made explicit in their draft.

Using the revised version of ESRV I am currently writing, a security policy
of the form 'always use TLS with any protocol at example.com' would have the
form:

example.com ESRV "tls=required"

A security policy that was specific to http would be expressed as:

example.com ESRV "prefix=_http._tcp"
_http._tcp.example.com ESRV "tls=required"

or

example.com ESRV "prefix=*"
_http._tcp.example.com ESRV "tls=required"

The reason for this change from the -00 version is that this approach
supports CNAMEs.

The reason that I started with the requirement to use SSL is that security
policy relating to trust criteria is meaningless until you have a statement
that use of SSL is required.

I have no objection to doing security policy. But I do have a real objection
to an approach that negates PKIX semantics as the TLSFP approach does.

-------- Original Message --------
> Subject: New Non-WG Mailing List: keyassure -- Key Assurance With DNSSEC
> Date: Tue, 17 Aug 2010 11:36:02 -0700 (PDT)
> From: IETF Secretariat <[email-masked]>
> To: IETF Announcement list <[email-masked]>
> CC: [email-masked], [email-masked], [email-masked]
>
> A new IETF non-working group email list has been created.
>
> List address: [email-masked]
> Archive:
> http://www.ietf.org/mail-archive/web/keyassure/current/maillist.html
> To subscribe: https://www.ietf.org/mailman/listinfo/keyassure
>
> Description: This list is for discussion relating to using
> DNSSEC-protected DNS queries to get greater assurance for keys and
> certificates that are passed in existing IETF protocols. The main idea is
> that a relying party can get additional information about a domain name to
> eliminate the need for using a certificate in a protocol, to eliminate the
> need for sending certificates in the protocol if they are optional, and/or
> to assure that the certificate given in a protocol is associated with the
> domain name used by the application. In all three cases, the application
> associates the key or key fingerprint securely retrieved from the DNS with
> the domain name that was used in the DNS query.
>
> For additional information, please contact the list administrators.
>
>
> --
>  Ondřej Surý
>  vedoucí výzkumu/Head of R&D department
>  -------------------------------------------
>  CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
>  Americka 23, 120 00 Praha 2, Czech Republic
>  mailto:[email-masked]    http://nic.cz/
>  tel:+420.222745110       fax:+420.222745112
>  -------------------------------------------
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>

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

---

From: Ben Laurie <[email-masked]>
Date: Fri, 1 Oct 2010 09:02:48 -0700

> that use of SSL is required.

I can't agree with this. If a user types an https URL, say, then
there's every reason security policy should apply despite the lack of
a statement that SSL is required.

> to an approach that negates PKIX semantics as the TLSFP approach does.

Then I'd like to see your proposal for _optionally_ allowing PKIX to
be overridden.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 1 Oct 2010 12:15:00 -0400

> a statement that SSL is required.

I regard typing https as being a policy statement.

I don't think anyone could use the TLSFP scheme as a substitute for DV
validation for about a decade. As of today 0% of the deployed browsers
support TLSFP so if someone types https and the cert is not DV validated
they are going to see the self-signed cert warning box.

What I would see as being much more practical is a scheme that works
automatically when the user types in http.

If the browser does not support the DNS mechanism then the user goes to the
site unencrypted as they do today.

If the browser and site both support the DNS mechanism, the communication is
encrypted and the user need not know anything about it.

I would like to get rid of the padlock entirely and eventually go to a user
experience when the user is only warned when going to one of the few
remaining sites that does NOT offer free transparent security.

> Then I'd like to see your proposal for _optionally_ allowing PKIX to

_http._tcp.example.com ESRV "TLS=required CERTFP=required"

This is still a potential shoot-in-foot situation for humans. But I can
write a script that can extract the necessary information to do the job
right.

---

From: Matt McCutchen <[email-masked]>
Date: Fri, 01 Oct 2010 18:05:05 -0400

On Fri, 2010-10-01 at 11:29 -0400, Phillip Hallam-Baker wrote:
> In particular I am very concerned about the particular approach being
> taken to security policy. What the proposers are attempting to do is
> to create a mechanism that allows a site that only uses one particular
> high assurance CA to 'protect' themselves against SSL certificates
> being issued by low assurance CAs.
> 
> As such, this is an objective I approve of and is one that I would
> like to see supported in a generalized security policy. It should be
> possible for a site to make security policy statements of the form
> 'all valid PKIX certs for example.com have cert X in the validation
> path'.
> 

Realize that I, and I would guess many other site admins, want precisely
that.  PKIX is complicated, whereas once I have a DNSSEC signed zone,
placing my TLS server's certificate in the zone and knowing that clients
will accept that certificate and no other could hardly be simpler.  And
why shouldn't I be allowed to do it?  I have complete authority over my
zone (even for the most part in the present public CA system).  Nobody
gave PKIX a monopoly on the determination of certificate acceptability.

We could support a more general scheme in which positive assurance is
separate from restrictions, but don't be surprised when a significant
fraction of sites use it to effectively "replace PKIX certificate
validation".

> Worse still, the proponents refuse to allow any method of shutting
> this system off. So if I have a site where I want to use DNSSEC
> validated certificates on the mail server, deployment is going to
> impact my Web server.

Yes, there should be a way to make the exclusivity optional, but there
may be better ways to solve the problem you cited, such as placing the
DNSSEC certificate at the SRVName for the mail server.

-- 
Matt

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 1 Oct 2010 19:15:31 -0400

> fraction of sites use it to effectively "replace PKIX certificate
The problem with that approach is that the attacker now has two
infrastructures that they can attack rather than just one.

You are increasing your attack surface, not reducing and simplifying it as
you might imagine.

> DNSSEC certificate at the SRVName for the mail server.

Regardless, I believe that the PKIX and TLS groups should be aware that this
is the change that has been implemented in code and is being proposed before
the WG is chartered.

There are much better ways to express the trust restriction semantics. I do
not see why the ability to express statements concerning your trust roots
needs to require deployment of a completely different mechanism and trust
path for the end entity keys.

For example, the ESRV mechanism is extensible. So it is possible for a site
that has their own PKI and root of trust to specify that there has to be a
trust path that includes that root of trust. Or you could publish a
fingerprint of a cross cert that has to be involved or you could even state
that there must be a cert record with the right fingerprint.

---

From: Ben Laurie <[email-masked]>
Date: Sat, 2 Oct 2010 13:16:19 -0700

> infrastructures that they can attack rather than just one.

If I deploy the DNS solution, stating that DNS is authoritative, then
my attack surface now excludes all CAs. How is that an increase in
attack surface?

Contrast with today's situation, where my attack surface is increased
on a regular basis by the introduction of new CAs, without any
consultation with me at all.

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

---

From: Marsh Ray <[email-masked]>
Date: Sat, 02 Oct 2010 20:49:20 -0500

On 10/02/2010 03:16 PM, Ben Laurie wrote:
> On 1 October 2010 16:15, Phillip Hallam-Baker<[email-masked]>  wrote:
>>

The thing we have to to keep in mind here is that this "attack surface" 
is largely determined on the client of the equation. In other words, if 
you attempt to set policy through DNS, it only applies to clients who 
choose to respect it. And clients do have that annoying habit of not 
consulting the server admins (or the users for that matter) before 
changing their trust. We can blame Netscape, they intentionally set it 
up this way (and are no longer around to defend themselves).

How much consistency is there in the current crop of PKI rules? What if 
DNSSEC info conflicts with other info?

Vendors of client software sometimes give themselves a root cert in the 
client, or at least have a close relationship with some of their CAs. 
There's a lot of money at stake, how eager will they be to allow sites 
to opt-out of that trust? Some of them also sell TLS MitM interception 
products.

The possibility that the bulk of clients will respect DNSSEC records 
which cut their CAs out of the trust equation any time soon seems a bit 
remote. We might as well be discussing the deprecation of SSLv3. It 
could happen eventually, but probably not in the near term.

In the meantime, we'd end up with the DNS root effectively having the 
power of yet another CA. Except that it's not, because the various arms 
of ICANN and VeriSign/Symantec are probably already trusted many times over.

I've seen it said that during the pre-deployment phase, the designers 
and promoters of DNSSEC denied they were making a replacement PKI. But 
the discussion now is to what extent it is inevitable. Regardless, if 
this is PKI 2.0 getting ready to usurp the throne, we should at least 
ensure that its a legitimately designed trust model this time rather 
than stumbling into whatever serves to enable some set of business 
agreements.

- Marsh

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 2 Oct 2010 23:30:27 -0400

The attack surface is the number of paths that are open to an attacker.

In the current model there is only one trust path, the PKIX path.

In the new model, the attacker has a choice of trust paths, the PKIX path
and the DNSSEC path and they can attack either of them.

The problem with the DNSSEC path is that it is vulnerable to attacks against
the information input to the DNS system. The weakest link there is the
safeguards on registration of the DNS names.

I think that whenever a proposal of this type is brought that we should be
told all the considerations and all the events that are motivating the
design.

On Sat, Oct 2, 2010 at 9:49 PM, Marsh Ray <[email-masked]> wrote:

> The thing we have to to keep in mind here is that this "attack surface" is
> largely determined on the client of the equation. In other words, if you
> attempt to set policy through DNS, it only applies to clients who choose to
> respect it. And clients do have that annoying habit of not consulting the
> server admins (or the users for that matter) before changing their trust. We
> can blame Netscape, they intentionally set it up this way (and are no longer
> around to defend themselves).
>
> There's a lot of money at stake, how eager will they be to allow sites to
> opt-out of that trust? Some of them also sell TLS MitM interception
> products.
>
> The possibility that the bulk of clients will respect DNSSEC records which
> cut their CAs out of the trust equation any time soon seems a bit remote. We
> might as well be discussing the deprecation of SSLv3. It could happen
> eventually, but probably not in the near term.
>
> In the meantime, we'd end up with the DNS root effectively having the power
> of yet another CA. Except that it's not, because the various arms of ICANN
> and VeriSign/Symantec are probably already trusted many times over.
>
> I've seen it said that during the pre-deployment phase, the designers and
> promoters of DNSSEC denied they were making a replacement PKI. But the
> discussion now is to what extent it is inevitable. Regardless, if this is
> PKI 2.0 getting ready to usurp the throne, we should at least ensure that
> its a legitimately designed trust model this time rather than stumbling into
> whatever serves to enable some set of business agreements.
>
> - Marsh
>

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 03 Oct 2010 17:14:06 +1300

>In the current model there is only one trust path, the PKIX path.

Which isn't so much a path as a twelve-lane motorway with elevated cloverleaf
interchanges, twenty-four-hour drive-through catering stops, and large neon
signs every few km inviting every attacker to join in.

>In the new model, the attacker has a choice of trust paths, the PKIX path and
>the DNSSEC path and they can attack either of them.

Or you can block off the PKIX motorway and leave only the (possibly) smaller
DNSSEC two-lane road.

(I'm not sure whether DNSSEC has a smaller overall attack surface than PKIX,
but chances are it does because the only security protocol with an even larger
attack surface than PKIX is XMLsec, whose attack surface is so huge that it
won't fit on the planets surface but actually extends several km out into
space).

Peter.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 3 Oct 2010 11:14:23 -0400

If the problem is the lack of checks and balances, the solution should be to
introduce checks and balances.

Moving from a market based solution with multiple CAs to a monopoly with one
trust provider does not help at all. It makes the situation much worse
because there is now no possibility of choice in the future.

This type of decision needs to be taken in the open with the proposers
clearly stating what they are about. The proposed charter as written
misleads the reader into thinking that what is being proposed is to use the
DNSSEC to provide one ADDITIONAL trust provider.

What is actually being proposed is to replace the fifteen year established
system of CAs with a new scheme starting in November.

If you read through the KEYASSURE archives, you will find that whenever the
proposers of this scheme are asked questions that they avoid answering them.
Most often they claim not to understand what is being asked.

I really don't think that we want to replace the existing infrastructure a
new PKI designed by people who claim not to understand the issues involved.
As the proposers of this scheme have done repeatedly.

This whole thing is being hurried through as if the proposers know that if
people actually stop and look at what is really being proposed that they
know the whole proposal will collapse.

Before we go any further with this, I want full disclosure. I want to know
the full extent of what is being proposed. I also want to know anything else
that might affect the consideration of this proposal.

The reaction to asking legitimate security questions has been really rather
awful. Whenever I ask a question, Paul Hoffman has immediately popped up to
claim that nobody can understand it, apparently in an attempt to divert
examination of the question into a flame war.

I do not think it is legitimate for a group of people to bully and threaten
away those of contrary views and then declare that they have achieved
'consensus'. That is the way Trotskyites take over political parties, they
call it 'entryism'.

On Sun, Oct 3, 2010 at 8:15 AM, Tony Finch <[email-masked]> wrote:

> On 3 Oct 2010, at 02:49, Marsh Ray <[email-masked]> wrote:
> >
> power of yet another CA. Except that it's not, because the various arms of
> ICANN and VeriSign/Symantec are probably already trusted many times over.
>
> I agree with your points about the difficulty of rolling out DNSSEC key
> assurance and its coexistence with PKIX.
>
> But the above is a bit off-base, because the DNS has a lot of structural
> constraints that make it weaker than a CA. Although in theory the root zone
> operators could steal any arbitrary name, the organisational checks and
> balances prevent that. CAs have no significant external checks and balances.
> For example they don't have the equivalent of whois that allows third
> parties to check who has been issued a certificate for a particular name.
>
> Tony.
> --
> f.anthony.n.finch  <[email-masked]>  http://dotat.at/
>
>

---

From: Tony Finch <[email-masked]>
Date: Sun, 3 Oct 2010 13:15:54 +0100

On 3 Oct 2010, at 02:49, Marsh Ray <[email-masked]> wrote:
> 
> In the meantime, we'd end up with the DNS root effectively having the power of yet another CA. Except that it's not, because the various arms of ICANN and VeriSign/Symantec are probably already trusted many times over.

I agree with your points about the difficulty of rolling out DNSSEC key assurance and its coexistence with PKIX.

But the above is a bit off-base, because the DNS has a lot of structural constraints that make it weaker than a CA. Although in theory the root zone operators could steal any arbitrary name, the organisational checks and balances prevent that. CAs have no significant external checks and balances. For example they don't have the equivalent of whois that allows third parties to check who has been issued a certificate for a particular name.

Tony.

---

From: Tony Finch <[email-masked]>
Date: Sun, 3 Oct 2010 17:10:39 +0100

On 3 Oct 2010, at 16:14, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> Moving from a market based solution with multiple CAs to a monopoly with one trust provider does not help at all. It makes the situation much worse because there is now no possibility of choice in the future.

It has the advantage of preventing a race to the bottom.

Note that there is a fair amount of choice available at lower levels in the DNS. So long as the registry provides a secure infrastructure, customers of secure registrars need not be concerned that insecure registrars can steal their names. There is no similar regulation of CAs.

Tony.

---

From: Martin Rex <[email-masked]>
Date: Mon, 4 Oct 2010 16:37:29 +0200 (MEST)

> and the DNSSEC path and they can attack either of them.

The PKI-based attack surface includes each and every single CA that
is signed under one of the existing >100 pre-configured trust anchors
shipping with browsers.  An attacker is free to choose to attack
any single one of these CAs and/or their issuing/validation procedures.

Trusting Certificates that are distributed under protection of DNSSEC
would amount to one additional trust anchor.
 
> safeguards on registration of the DNS names.

It seems that you do not realize that the entire TLS PKI security model,
as far as the automatic / no-prompt "server endpoint identification" is
concerned, has always been relying completely on that DNS data being
accurate.

Therefore, security-wise, trusting Certificates that are
distributed through DNSSEC for no-prompt server endpoint identification
is more secure than the TLS PKI pre-configured trusted scheme, and
it does not add any new attack surface.  Only when server certificates
are manually verified by end users, other information from these
certificates besides the DNS f.q.d.n might be considered in
the end users decision to trust a server cert.

But keep in mind that few TLS clients (such as browsers), currently
support "pinning" of PKIX-authenticated server certs, so that on future
connects only the very same server cert (with user-authenticated
attributes other than DNS f.q.d.n) will be accepted from that server.
In is very common misbehaviour in TLS clients to accept arbitrary other
server certs on future connects, as long as the DNS f.q.d.n matches.

One thing that needs to be addressed/solved is the key/cert rollover
for any TLS-Server, so that it is possible to list more than one
server cert as "valid" for a Server through DNS, at least for the
time of the transition/rollover.

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Mon, 04 Oct 2010 10:12:21 -0500

> concerned, has always been relying completely on that DNS data being

How do you figure that?

I can put an entry in /etc/hosts (do this all the time for testing) and 
DNS isn't even queried. Yet the server certificate is validated as usual.

> server certs on future connects, as long as the DNS f.q.d.n matches.

Is there a spec saying this is invalid behavior?

> time of the transition/rollover.

If you're going to trust certs you get out of DNS, you might as well 
just put a self-signed organizational CA cert in there. Maybe that's 
what's being proposed.

Say, what's the link to the Internet Draft proposal we're discussing anyway?

- Marsh

---

From: Ralph Holz <[email-masked]>
Date: Mon, 04 Oct 2010 17:54:36 +0200

Hi,

> server certs on future connects, as long as the DNS f.q.d.n matches.

I have found during a few tests that some companies which give different
IPs for the same DNS name also run some servers with different certs
than the "main one". A closer look at the certs revealed that they had
been issued for the same domain and had been signed by the same CA, i.
e. they were perfectly valid. Pinning certs would prohibit this kind of
behaviour.

Although I am not sure it is intentional - my thought was that these
servers were just misconfigured (older cert?), as only very few
exhibited this behaviour.

-- 
Best regards,
Ralph

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 04 Oct 2010 17:05:03 +0100

> time of the transition/rollover.

Maybe a side-issue here, but this came up in the W3C WSC work and
I wrote up an idea for that (not based on DNS) which is RFC 5697. [1]
No idea if anyone is using or would use it, though I did have a student
implement it, so it *could* work. (Note: that's an experimental-track
RFC, as it ought be:-)

S.

[1] http://tools.ietf.org/html/rfc5697

---

From: Geoffrey Keating <[email-masked]>
Date: 04 Oct 2010 09:18:24 -0700

> exhibited this behaviour.

Some CAs license their certificates for use on a single server.  If
these companies were using one of these CAs, they may have bought
multiple certificates for the same DNS name.  This might be done even
if the CA doesn't require it, as a security/reliability measure, so
that machines do not need to share private keys.

This can also happen for the same IP address, if it's a load balancer
with several servers behind it.

It can also happen if the systems serve different combinations of DNS
names: one machine serves www.a.com and another serves both
mail.a.com and www.a.com so they have different certificates.

---

From: Martin Rex <[email-masked]>
Date: Mon, 4 Oct 2010 18:19:15 +0200 (MEST)

> DNS isn't even queried. Yet the server certificate is validated as usual.

In order to get a TLS server cert issued for a particular DNS f.q.d.n
under most of the existing pre-configured trust anchors, you only need
to provide some vague proof that you leased that DNS domain.

The no-prompt server endpoint identification will ignore any information
in the cert besides the DNS f.q.d.n, no matter how carefully that other
part of information may be validated.

> Is there a spec saying this is invalid behavior?

No.  For the existing specs, this issue fell into the huge
"out-of-scope" gaps between rfc-2818, PKIX and TLS.

I know there is a school of thought popular in the US that is build
around "but it didn't come with a warning label that I must not shoot
in my foot, so it isn't my fault".  

I assume that _very_ few of those TLS-enabled servers that offer
TLS client cert authentication, base their authorization decision
on only one particular certificate attribute and ignore all the
rest of the certificate and allow it to chain to arbitrary CAs
operated under any one of >100 pre-configured trust anchors.

But for the server side, no-prompting usability has always been deemed
MUCH more important than security.

> just put a self-signed organizational CA cert in there. Maybe that's 

That only affects the frequency of the key/cert rollover, not the fact
that key/cert rollover needs to be addressed.

Distributing an organizations CA cert through DNS instead of the
server certs is somewhat incompatible with how a lot of traditional
PKI software works (like Microsoft's CryptoAPI on XP/2003).

PKIX specs define certificate path validation only when you have
a certificate chain to one of your trust anchors.  You probably
will _NOT_ want most of these CAs a trust anchor, even when you might
allow the use of such organizational CA certs for verification of
specific server certificates.

I once received an S/Mime signed Email in Outlook 2003, and the signature
included an end-entity and an intermediateCA cert.  I found myself
unable to make Outlook verify the digital signature of that Email,
because of a lack of the (non-public, organizational) RootCA cert
for that chain.

> Say, what's the link to the Internet Draft proposal we're discussing anyway?

To me it sounded like it is a post-prototype implementation,
pre-draft discussion about the charter of the "keyassurance" WG.

-Martin

---

From: Ondřej Surý <[email-masked]>
Date: Mon, 04 Oct 2010 18:29:35 +0200

Phillip,

you present your views by cross-posting several other IETF mailing list 
without posting this to [email-masked].  This doesn't give potential 
readers full picture about what's happening in the keyassure and what is 
the general consensus in the list.

So please all - if you want to respond to Phillip's message, first go to 
keyassure mailing list archive[1], then join the the list[2] and comment 
there.  I don't think we want to fill our inboxes with this discussion 
(which should really happen in keyassure) in several copies.

While we value input from other working groups it is already hard to 
follow the discussion in one mailing list and when it splits to many, it 
will be just a mess.

Ondrej

1. http://www.ietf.org/mail-archive/web/keyassure/
2. https://www.ietf.org/mailman/listinfo/keyassure

On 1.10.2010 17:29, Phillip Hallam-Baker wrote:
> notice sent out is that the group is not only considering key assurance,
> the proposals made are also intended to have security policy semantics.
>
> This was not apparent to me from reading the list announcement, the
> initial proposed charter or the Internet drafts. I have asked the
> organizers of the group to clarify the matter in the wider IETF
> community but they have not done so.
>
>
> taken to security policy. What the proposers are attempting to do is to
> create a mechanism that allows a site that only uses one particular high
> assurance CA to 'protect' themselves against SSL certificates being
> issued by low assurance CAs.
>
> As such, this is an objective I approve of and is one that I would like
> to see supported in a generalized security policy. It should be possible
> for a site to make security policy statements of the form 'all valid
> PKIX certs for example.com <http://example.com> have cert X in the
> validation path'.
>
>
> Now the proponents are trying to downplay this by saying that 'all' they
> are doing is to tell people to 'ignore' PKIX validation. But that
> approach really offends my sense of layering.
>
> Specifically the proposal amounts to using the DNS CERT record to
> publish a fingerprint of all the certificates permitted for use with TLS
> at a specific domain:
>
> example.com <http://example.com> CERT TLSFP 0 0 <digest cert 1>
> example.com <http://example.com> CERT TLSFP 0 0 <digest cert 2>
>
> It is proposed to replace current TLS certificate processing semantics
> with the following:
>
> 1) Query for CERT record at example.com <http://example.com>
> 2) If no CERT record with TLSFP certificate type exists then perform
> normal PKIX validation and return that result
> 3) Otherwise attempt to match the TLS end entity certificate with one of
> the fingerprints specified in the published TLSFP RRs
> well, but the authors have not explained how that is meant to work in
> the context of their proposal so I left it out.
>
>
> The defenses made for this approach are of the form 'you have to wear
> big pants to play this game'. In other words if people are going to
> administer these systems and not be burned they are going to have to
> understand what they are doing. I do not consider this a responsible
> approach to protocol design.
>
> What I would prefer is to have systems that do not need to be
> administered by people at all. That is not possible when the approach
> has hidden side effects that cannot be anticipated by scripts.
>
>
> I am very much committed to the idea of doing security policy. But this
> is not an approach I can support. Any policy mechanism has to be
> orthogonal to the key validation strategy in my view. I should be able
> to use any DNS security policy mechanism that the IETF endorses with
> PKIX certificate processing semantics.
>
> This does not currently contain a mechanism to express trust
> restrictions but is designed to be extensible to support such. When I
> proposed ESRV I was unaware that the KEYASSURE proposal was intended to
> have a security policy aspect at all. It is still not made explicit in
> their draft.
>
>
> Using the revised version of ESRV I am currently writing, a security
> policy of the form 'always use TLS with any protocol at example.com
> <http://example.com>' would have the form:
>
> example.com <http://example.com> ESRV "tls=required"
>
> example.com <http://example.com> ESRV "prefix=_http._tcp"
> _http._tcp.example.com <http://tcp.example.com> ESRV "tls=required"
>
> or
>
> example.com <http://example.com> ESRV "prefix=*"
> _http._tcp.example.com <http://tcp.example.com> ESRV "tls=required"
>
> The reason that I started with the requirement to use SSL is that
> security policy relating to trust criteria is meaningless until you have
> a statement that use of SSL is required.
>
>
> I have no objection to doing security policy. But I do have a real
> objection to an approach that negates PKIX semantics as the TLSFP
> approach does.
>
>
>     From: IETF Secretariat <[email-masked]
>     <mailto:[email-masked]>>
>     To: IETF Announcement list <[email-masked]
>     <mailto:[email-masked]>>
>     CC: [email-masked] <mailto:[email-masked]>,
>     [email-masked] <mailto:[email-masked]>, [email-masked]
>     <mailto:[email-masked]>
>
>     List address: [email-masked] <mailto:[email-masked]>
>     Archive:
>     certificates that are passed in existing IETF protocols. The main
>     idea is that a relying party can get additional information about a
>     domain name to eliminate the need for using a certificate in a
>     protocol, to eliminate the need for sending certificates in the
>     protocol if they are optional, and/or to assure that the certificate
>     given in a protocol is associated with the domain name used by the
>     application. In all three cases, the application associates the key
>     or key fingerprint securely retrieved from the DNS with the domain
>     name that was used in the DNS query.
>
>       mailto:[email-masked] <mailto:[email-masked]> http://nic.cz/
>     [email-masked] <mailto:[email-masked]>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 4 Oct 2010 14:52:37 -0400

The reason I did so was that I did not believe that the initial presentation
of KEYASSURE to the wider Internet community gave an accurate or full
description of what the intended proposal was.

Since neither of the proposers took any notice of my repeated requests to
correct this situation, I decided that it was time to do so myself.

My original understanding from the announcement made was that 'assurance'
meant to provide additional mechanisms for binding keys to DNS names. It has
since turned out that what is being proposed is very different and has
significant impact across the whole IETF security area.

My problem with KEYASSURE is precisely the fact that people have not been
given the 'full picture'.

Even now after three drafts, the key-linkage draft does not actualy specify
that the purpose of the protocol is to enable a site to specify which
certificates are valid for the site by enumeration of all valid certs. That
is merely an unremarked consequence of the algorithm.

2010/10/4 Ondřej Surý <[email-masked]>

> readers full picture about what's happening in the keyassure and what is the
> general consensus in the list.
>
> While we value input from other working groups it is already hard to follow
> the discussion in one mailing list and when it splits to many, it will be
> just a mess.
>
> Ondrej
>

---

From: Martin Rex <[email-masked]>
Date: Mon, 4 Oct 2010 21:59:43 +0200 (MEST)

> [1] http://tools.ietf.org/html/rfc5697

I do _not_ like the OtherCertificates extension.  If some client would
honour this for a "pinned" cert, it would allow an arbitrary CA under
any of the trusted roots to completely subvert the clients motivation
of pinning the cert.  

A sensible approach would require a certificate extension in the
new cert which provides a proof from the original certificate holder
(i.e. signed with the private key of the old cert), that the new
cert (the public key and at least some of the certificat attributes,
such as subject name, all subjectAltNames, BasicConstraints, keyUsage,
ExtendedKeyUsage, maybe more) are a valid replacement for the original
server cert.

Key continuity without the consent of the original key holder looks
dangerous to me.  

-Martin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 4 Oct 2010 16:04:24 -0400

<Lots of statements concerning how CAs work>

For the past five years, CA certificates have been divided into Domain
Validated and Extended Validated. As some of you know, I instigated the
process that led to the creation of EV certs because I was very worried
about the low quality of many DV certificates.

Some DV certificates are of very low quality. Which is why I would like to
see the padlock icon phased out entirely. Why does the user need to know if
encryption is being used at all?

Actually the reason the user need to know that encryption is being used is
quite an interesting one and has to do with the lack of a security policy
layer for the Internet. If we could guarantee that encryption would always
be used when visiting a site where there is a certificate, there would be no
need for the padlock icon.

But that is a digression. The problem raised by many people here is that a
site example.com can get an SSL certificate with the highest available
assurance level but a MITM attack can be performed with a low assurance
certificate obtained from any of the CAs listed in the browser roots.

There are two possible means of attacking this problem

1) Provide a means for determining if a certificate is authorized for use
2) Sanction CAs that issue unauthorized certificates

The TLSFP approach only allows the first approach to be employed.

My approach, publication of the authorized CA roots permits both approaches
to be employed.

The way I see this working is that each CA would publish a record that
customers could publish in their DNS zone to state that other CAs should not
issue certs. This would have the Digest of either the root key or an
intermediate cert.

example.com  ESRV "pkix=29823dhd2w3298yf2=="

Some sites might have multiple roots advertised for cases where they are
switching providers:

example.com  ESRV "pkix=29823dhd2w3298yf2== pkix=2u2queihwiehiuhe=="

And there could also be provision for advertising CERT records and so on. We
can fill in those details later.

Once the necessary record is allocated, a proposal is made to CABForum to
require all member CAs to verify every cert against these DNS records before
issue. I believe that there should be a very high degree of voluntary
compliance since it is a check that can be automated.

After a short interval the mechanism is made mandatory. The browser and
platform providers have the necessary tools to achieve this. They can
require the checks to be specified in the annual WebTrust audit which means
that every cert would have to be in compliance within a year.

Non compliant certificates would be detected as a matter of course by the
various companies who have reason to crawl the Web and look at SSL certs.

Note that my approach does not require client implementation to be
effective, but allows for client implementation if this is considered
desirable and is equally effective as a means of client side enforcement.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 4 Oct 2010 16:04:24 -0400

---

From: Jakob Schlyter <[email-masked]>
Date: Mon, 4 Oct 2010 19:29:59 +0200

> Say, what's the link to the Internet Draft proposal we're discussing anyway?

https://datatracker.ietf.org/doc/draft-hoffman-keys-linkage-from-dns/, among others.

	j

---

From: Michael StJohns <[email-masked]>
Date: Mon, 04 Oct 2010 14:30:29 -0400

Hi -

DNSSEC seems to be picking on PKIX and vice versa - maybe the right answer is both?

DNSSEC provides a "secure" association FROM the name TO the IP address.  But the DNS domain owner tends not to be the host owner so this asserted association may not reflect the intent of the host owner.  Also, DNSSEC doesn't protect from IP hijacking (re-routing).

PKIX provides a "secure" association TO/FROM "a" name to a public key.  The host owner holds the private key and can prove "ownership" of the related public key.  But the host owner tends not to be the domain owner so the asserted association may not reflect the intent of the DNS domain owner.

What if - the PKIX certificate for the host contained a "permit" for the name signed by the DNS owner?  A signature over the hash of the public key in the certificate, and the DNS name - and maybe some expiration info verifiable by the data in DNSSEC?

The path goes something like:

1) Use DNS and DNSSEC to find the host (or even just DNS)
2) Use TLS to grab the certificate
3) Verify the certificate using the PKIX path to a trust anchor
4) Verify the host knows the private key related to the host certificate
5) Verify the extension in the certificate was signed by the domain's DNSSEC key (pick one of special key, KSK or ZSK)
6) Verify the name offered in the certificate matches the DNS name looked up.

You've verified that:
a) The zone owner has assigned the name to the owner of the cert's private key
b) The host owner has agreed the host has the DNS name.
c) The IP to Name mapping (what might be in the PTR record and signed under DNSSEC - maybe).

The DNSSEC name to IP address mapping becomes irrelevant for trust purposes which means that IP hijacking is no longer an issue.

A random PKIX forming a certificate with a DNS name in it can't form one that proves the name assignment from the DNS, so the large set of PKIX trust anchors becomes less of an issue.  

Mike

---

From: Michael StJohns <[email-masked]>
Date: Mon, 04 Oct 2010 14:30:29 -0400

Hi -

You've verified that:

Mike

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 4 Oct 2010 15:18:16 -0400

> system of CAs with a new scheme starting in November.

[. . .]

> As the proposers of this scheme have done repeatedly.

Suppose all of that is true (and I think it's a gross
misrepresentation of the situation, but never mind that), so what?
Presumably, if this new PKI sucks as much as you say it does, nobody
will use it, and no harm will come.  If it's a kind of snake oil that
appeals to the clueless (i.e. it sucks as much as you say it does, but
it's jumped up and marketed in a way that lures people who don't know
any better), then it will have some spectacular failure and everyone
will thenceforth avoid it.  So what's the problem, even if things are
as bad as you say?

Also, why isn't this on the list devoted to this discussion (followup set)?

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 04 Oct 2010 23:26:45 +0100

(Just bringing the cc down to TLS & PKIX.)

On 04/10/10 20:59, Martin Rex wrote:
> I do _not_ like the OtherCertificates extension.  

I'm all upset:-)

> If some client would

Right. Just like today. OtherCerts wasn't aimed at tackling rogue
CAs. Could be that a solution exists that can handle rogue CAs as
well as allowing clients to track pinning across certs. If so, I'd
be glad to see it written up.

> ExtendedKeyUsage, maybe more) are a valid replacement for the original

Interesting.

> Key continuity without the consent of the original key holder looks

I suspect it'd get too complicated if all 3 parties (CA, TLS server
and client) have to be involved, and PKIX doesn't have a history
of successfully getting more complicated EE/CA protocols deployed.
But if it worked, I'd be for trying it.

S.

---

From: Martin Rex <[email-masked]>
Date: Tue, 5 Oct 2010 02:46:11 +0200 (MEST)

> - maybe the right answer is both?

In theory, PKIX could provide real value.

In practice, the PKIX abuse commonly described as "TLS PKI"
that performs a non-popup server endpoint identification with the help
of target DNS hostnames has infinitesimal close to zero value over DNSSEC.

Conceptually, limiting the certificates that can be used to provide
servers on specific DNS hostnames to certificates explicitly listed
by the DNS admin would significantly reduce the huge attack surface
of the existing "TLS PKI" with >100 independent pre-configured
trust-anchors in most TLS client software.

> 
> DNSSEC provides a "secure" association FROM the name TO the IP address.
> But the DNS domain owner tends not to be the host owner so this asserted
> association may not reflect the intent of the host owner.
> Also, DNSSEC doesn't protect from IP hijacking (re-routing).

Incorrect characterisation.  DNSSEC provides only for secure distribution
of DNS records.  Whether the distributed DNS records are accurate or
trustworthy is a completely distinct issue.

> 
> PKIX provides a "secure" association TO/FROM "a" name to a public key.

This "secure" association is limited to specific "vetted" attributes
(which may or may not be described in a legalese Certificate Practice
 Statement (CPS)), with one notable and serious exception:
Any occurrence of a DNS hostname in a PKIX cert is based entirely
and completely on the DNS delegation records, and all of the popular
non-prompting server endpoint identification completely ignores all
carefully reviewed cert attributes and relies _completely_ on the
DNS hostnames based on the DNS delegation records.

>
> The host owner holds the private key and can prove "ownership" of the
> related public key.  But the host owner tends not to be the domain
> owner so the asserted association may not reflect the intent of the
> DNS domain owner.

While this may be true in practice, the domain owner is a person that
is definitely entitled to get certs issued for hostnames in his domain
from most (probably all) "TLS PKI CAs" and the domain owner is also
the one that can create and is entitled to distribute arbitrary DNS
records in his DNS domain through DNS and DNSSEC protocols.

Authentication that should reliably exclude the DNS admin for a
servers DNS hostname from acquiring a "valid" server cert, will need
to completely ban the DNS hostname from the server endpoint identification.
One means to do this would be to securly authenticate the server by
his public key, also called "certificate pinning",
also mentioned here http://www.w3.org/TR/wsc-ui/#selfsignedcerts 

Selective trust and trust being affected by repeated encounter is
evolutionary heritage and intrinsic to every mammal and most human beings.
Unfortunately, some TLS-clients make it increasingly difficult to practice
such evolutionary proven approaches to server endpoint identification.

-Martin

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 5 Oct 2010 12:32:59 -0400

You are confusing attack surface with vulnerability.  Without getting
into technology specifics, if A .and. B must be successfully attacked in
order to cause a problem, then having two systems can only reduce the
vulnerability even though there are more places to attack.

If the problem is availability, then the best strategy is redundancy -
use multiple sources for a single information item.  If the problem is
integrity, the best strategy is diversity - use different sources for
different information items.  If either source gives the wrong answer
you fail, but fail safely.  (Redundancy and diversity can be combined of
course, but then combining rules such voting thresholds have to be
specified). 

For the DNS/PKI case, if A is an IP address for a dnsname and B is a
public key for a dnsname, then it is necessary to attack the sources of
A and B in order to successfully spoof a named server.  If A and B come
from the same system (e.g., DNS) it is necessary to attack only that
system.  If they come from different systems (DNS and PKI) then it is
necessary to attack both.  Attacking only one may cause an availability
failure, but not an integrity failure.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ben Laurie

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 5 Oct 2010 18:49:26 +0200

You are working on wrong assumptions. The DV certs are exactly as strong as your DNS is. You only need to attack DNS to issue a DV cert.

Ondrej Sury

On 5.10.2010, at 18:32, "Kemp, David P." <[email-masked]> wrote:

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 5 Oct 2010 12:56:49 -0400

David,

When I originally looked at this scheme I thought that it was intended to
reduce the attack surface in the manner you describe.

Clearly if you have two controls, A and B and BOTH must be compromised, the
system is less likely to be compromised than either A or B.

But the design approach taken in the Hoffman et. al. proposal is that
publication of a DNSSEC assurance for a cert disables verification on the
PKIX chain unless the 'preferences' flag is set. This flag will be buried in
a base64 encoded sub-field encoding.

In practice only a proportion of clients will deploy this mechanism. So if A
is PKIX and B is DNSSEC, it will be possible for an attacker to succeed if
either A or B is compromised in one configuration and if either A or A and B
is compromised in the other.

People seem to be confusing the security of the cryptographic protocols with
the security of the infrastructures that support them. The weakest link in
any competently designed security scheme is people and processes. The PKIX
infrastructure has been operating as a security infrastructure for 15 years,
its flaws are reasonably well understood at this point. DNS on the other
hand is a non-security infrastructure that people appear to want to
immediately co-opt to duplicate functions of PKIX.

"What could possibly go wrong"

Given that the problem that instigated this proposal is mis-issue of a
certificate. It would appear to me that we should look at deploying controls
that reduce the probability of mis-issue of a certificate before we rush to
deploy a completely new validation scheme for certificates in the six month
timescale being proposed in this charter.

In particular, it would be rather useful to have controls of the form:

* Certificates only valid if issued into a certificate chain with specified
properties
* Obtain additional authentication according to protocol X and key Y.

---

From: Seth David Schoen <[email-masked]>
Date: Tue, 5 Oct 2010 11:04:23 -0700

> failure, but not an integrity failure.

In the case where an attacker controls the network, they can win
with B only, without A, because they can perform an active attack
even when the client knows the correct IP address for the server.

Consider

http://www.ex-parrot.com/~pete/upside-down-ternet.html

which only attempts to attack HTTP without TLS.  But notice that
it would work correctly even with DNSSEC because it does not rely
on misleading the client about the server's IP address.

In this threat model, attacking the source of A is not necessary
for spoofing a TLS-enabled server, but attacking the source of B
is.  This threat model could apply realistically to many public
networks, particularly because the attacker need not be the
network's legitimate owner in order to control the network (for
instance, through compromised routers, DHCP spoofing, or ARP
spoofing).

In this model, getting the service's correct public key to the
client is necessary and sufficient all by itself.

---

From: Marsh Ray <[email-masked]>
Date: Tue, 05 Oct 2010 13:36:56 -0500

On 10/05/2010 11:56 AM, Phillip Hallam-Baker wrote:
>
> Clearly if you have two controls, A and B and BOTH must be compromised,
> the system is less likely to be compromised than either A or B.
>
> publication of a DNSSEC assurance for a cert disables verification on
> the PKIX chain unless the 'preferences' flag is set. This flag will be
> buried in a base64 encoded sub-field encoding.
>
> In practice only a proportion of clients will deploy this mechanism. So
> if A is PKIX and B is DNSSEC, it will be possible for an attacker to
> succeed if either A or B is compromised in one configuration and if
> either A or A and B is compromised in the other.

+1

In practice, only a proportion of servers will deploy this mechanism 
until such time as Firefox and Chrome are willing to shut them off.

I've read that because DNSSEC records are large, some resolvers cannot 
pass them on. Testing a few months ago indicated that it worked on 
something like 4 out of 5 internet connections I tried it on. But it's 
quite possible that there are little wifi-router-firewall boxes in 
millions of homes that don't expect such large packets on port 53.

So clients will have to continue to operate in the absence of DNSSEC 
information for the forseeable future.

It's also reasonable to suspect that an attacker (who in our analysis is 
already presumed to have a fraudulent server cert and the ability to 
make use of it, i.e., MitM) would also be able to downgrade DNS to strip 
out this "preferences" flag (if some intermediate box isn't doing it 
already).

Therefore the attacker may be able to choose to attack the via a DNSSEC 
problem (e.g., a website vuln at the site's DNS registrar) or via PKI 
(e.g., a rouge sub-CA). So the attack surface is, in fact, increased.

Unless I'm missing something about how DNSSEC prevents downgrade 
attacks, which is quite possible.

> People seem to be confusing the security of the cryptographic protocols
> with the security of the infrastructures that support them. The weakest
> link in any competently designed security scheme is people and
> processes.

Perhaps only because security designers have successfully washed their 
hands of the harder part of the problem?

> The PKIX infrastructure has been operating as a security
> infrastructure for 15 years, its flaws are reasonably well understood at
> this point.

That's a very nice way of saying it.

I would have said it this way:

     IT SUCKS!!!!

The fact that the national telephone company of Qwertystan can delegate 
a sub-CA that can delegate a sub-CA that can issue a certificate which 
enables the MitM of the connection between my notebook and my company's 
VPN server is a scandal. If anyone had ever proposed such a scheme to 
people who weren't already steeped in the status quo, they'd be laughed 
out of their industry.

> DNS on the other hand is a non-security infrastructure that
> people appear to want to immediately co-opt to duplicate functions of PKIX.

Rather than wanting to co-opt or duplicate the current PKI scheme, it 
may be that people are simply eager to rid themselves of it.

Not saying it's perfect, I honestly haven't looked into it very deeply, 
but DNSSEC holds a lot of promise:

1. It builds on top of DNS, which is reasonably mature.

2. It was designed for actual security with knowledge of modern attacks 
and the benefit of hindsight.

3. It was designed at all, rather than simply evolving to enable various 
sets of business deals.

4. It roots to one entity is ostensibly neutral and non-profit. They 
have a track record which can be evaluated. They largely own DNS anyway.

5. Domain holders already understand the need to handle their domain 
name registrations as super-critical assets.

6. It appears to delegate more control to the domain holder to define 
and authenticate his own data. He doesn't have to deal with weird "per 
server licensing" (whatever that means) agreements.

7. It appears to reduce or eliminate some recurring fees associated with 
server authentication.

Of course, this list leaves out anything bad about it. Possibly, it's 
worse on balance.

> "What could possibly go wrong"

Lots, particularly during the transition period when parallel systems 
must be trusted.

Which is why such a proposal needs a lot of thinking and real-world testing.

Which is why it would have been better for it to have been proposed earlier.

> certificate. It would appear to me that we should look at deploying
> controls that reduce the probability of mis-issue of a certificate

It's not a question of probability, it's the option of the attacker. If 
you have something worth protecting, you need to be defending against a 
targeted attack. The attacker may or may not have the capability to 
obtain a usable private key, but if he can, he can be expected to use 
it. So it's not a question of "probability if" but of "who", i.e., who 
are the attackers I wish to defend against.

There are may of users of the technology who do not desire to trust (or 
actively mistrust) many of the entities controlling CAs.

> before we rush to deploy a completely new validation scheme for
> certificates in the six month timescale being proposed in this charter.
 >
> * Certificates only valid if issued into a certificate chain with
> specified properties

Anything limiting the number and scope of CAs would be an improvement.

But such improvements could have been implemented at any time 
previously, yet they were not. Maybe the prospect of DNSSEC replacing it 
will provide motivation for PKI to improve. But by then the train may 
already be rolling.

- Marsh

---

From: Stephen Kent <[email-masked]>
Date: Tue, 5 Oct 2010 14:41:06 -0400

>DNSSEC seems to be picking on PKIX and vice versa - maybe the right 

I don't see the proposed work as a war between X.509 certs and signed 
DNS records. I think that they are potentially complementary security 
mechanisms.

>...
>What if - the PKIX certificate for the host contained a "permit" for 
>the name signed by the DNS owner?  A signature over the hash of the 
>public key in the certificate, and the DNS name - and maybe some 
>expiration info verifiable by the data in DNSSEC?

We have avoided putting additional signatures in a public-key cert, 
so I'm not comfortable with a proposal that does so.  Is there a way 
to reverse this, so that the cert contains a hash of a key from the 
DNS, and there is a (signed) DNS record that covers the cert?

Steve

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 5 Oct 2010 14:02:52 -0500

> really offends my sense of layering.

I think the layering argument is the strongest argument here.  To be
sure, the KEYASSURE approach offends my sense of layering too, but not
in the same way: IMO this is a change to how certificate validation is
done, therefore an update to RFC5280, ISTM, is required.

What I'd like to see is for the DNSSEC approach to certificate
validation be considered as a change to TLS and/or PKIX.  That is:

 - RFC5280 should be updated to describe DNSSEC-based validation of
   certificates.

   There are a number of security considerations here that must be
   considered in the context of PKIX.  For example: can a DNSSEC-
   validated certificate be a CA certificate, and if so, what might its
   scope be?  Are there implied naming constraints?  Or: when is it OK
   to try one (traditional PKIX valdiation) or the other (DNSSEC), and
   when is it OK to fallback on the other?

   (Perhaps this is what you meant by giving the attacker two
   infrastructures to attack.  If the validation policy of the rp can be
   forced to fallback on a less preferred mechanism via a DoS attack,
   then the attacker has something to work with.)

   I've _not_ reviewed the KEYASSURE documents, so I'm not sure if these
   security considerations are being addressed/documented.

 - TLS implementations should offer applications whatever choices the
   update to RFC5280 requires, if any.  Choices such as: validation
   policy choices (trad-PKIX-only, DNSSEC-only, trad-PKIX-and-DNSSEC,
   DNSSEC-fallback-on-trad-PKIX-only-if-NXDOMAIN-is-secured, DNSSEC-
   fallback-on-trad-PKIX).

   TLS doesn't have abstract interfaces, but some text regarding this in
   an update to TLS 1.2 seems appropriate to me.  Alternatively, such
   text could belong in the RFC5280 update, but even then, I think TLS
   implementors specifically need to be made aware of this new
   certificate validation option and its security considerations.

The main security consideration here is, I think, about when to try one,
the other, or both of traditional PKIX or DNSSEC certificate validation.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Tue, 5 Oct 2010 21:46:55 +0200 (MEST)

Phillip Hallam-Baker wrote:
> David P. Kemp wrote:

The DNS admin that controls A can always get a perfectly valid
certificate B issued and successfully impersonate all services
offered on servers in his DNS domain.  Because of this characteristic 
of the TLS PKI, it doesn't matter how much scrutiny the CAs apply,
if you can not trust the DNS admin, you loose.

Requiring the involvement of a pre-trusted commercial CA makes
it less attractive to DNS admins to abuse their position and
harder for attackers that manage to modify DNS records of
DNSSEC signed zones to impersonate servers in that DNS zone.
Obtaining CA-signed server certs may require "official procurement",
so the issuance of the server certs goes on record at the issuing CA
and the domain owners procurement.  This could serve as a deterrent
for outsourced DNS services or unhappy DNS admins.

> a base64 encoded sub-field encoding.

What is the alternative?

I'm constantly hearing some folks that want to obtain DNSname-constrained
organizational CA-certs signed under one of the pre-configured trust anchors
so that their (DNS) admin can issue server certs without involvement
of commercial CAs.  Such CA-certs will probably sell at a significant
premium.

Should the IETF really define TLS technology in a fashion where
everyone will have to buy out of slavery from a commercial CA oligopoly
at a significant premium for every DNS domain one operates?

It is a "trade-off", to hold the whole world hostage to the CA oligopoly
in order to keep the initial investment (the "Coasean floor"[*]) high
for only one specific impersonation attack, but I'm not convinced that
this particular approach is the the best solution or the only solution
and that the benefit is worth the cost.  I could imagine that it
appeals to top-level management, because they do not like to worry
about outsourcing stuff (like DNS administration) or worry about
making employees (like DNS admins) unhappy.

-Martin

[*] There was an article about "Coasean floor" in Bruce Schneiers
Dec-2008 Cryptogram http://www.schneier.com/crypto-gram-0812.html#7

---

From: Marsh Ray <[email-masked]>
Date: Tue, 05 Oct 2010 21:05:32 -0500

On 10/05/2010 02:46 PM, Martin Rex wrote:
> offered on servers in his DNS domain.

By most people's definition, it's not "unauthorized impersonation" if 
the DNS admin does it

Most people seem to be under the impression that current DNS and TCP/IP 
provides such a degree of security that it's "highly improbable" that 
there will be an active attack on their server's incoming connections. 
I'm not saying this is correct, only that it seems to be the 
conventional wisdom.

There may be some organizations that separate the duties of DNS 
administration and key generation, but in general I'd think that 
organizations operating https servers are more concerned about getting 
their domain name stolen than losing control of the PKI chain of trust.

> Because of this characteristic

So you seem to be saying that because some currently widely-trusted CAs 
will issue a new cert to an attacker able to receive email at the target 
domain (e.g. by controlling its DNS as resolved by the attacker's 
preferred CA) that nothing which is built on the current PKI is usefully 
authenticated. Also, DNS admins must be considered possible attackers.

There's probably a lot of truth in there (or maybe I'm not understanding 
you correctly), but it seems like that line of reasoning isn't very 
useful. It could be used to support any conclusion.

"PKI cert auth is no more secure than SMTP email" ->
"PKI cert auth is no more secure than DNS" ->
"https is no more secure than DNS" ->
"no point in using HTTPS authentication" ->
"no point in using HTTPS encryption" ->
"we should all give up and go home".

No doubt I feel like that some days.

Let's keep in mind the goal of bootstrapping whatever the current system 
is to a higher level the security and efficiency for everyone. 
Considering where we are now, this is probably an achievable goal.

> DNSSEC signed zones to impersonate servers in that DNS zone.

Is this the old security - ease of use tradeoff?

Is the solution to increase the cost and difficulty of setting up an 
authenticated server? If so, how much will it take?

I'm extremely skeptical of any system which purports to enable "opt-in" 
authentication. An attacker can usually just opt-out.

> for outsourced DNS services or unhappy DNS admins.

This doesn't seem like a significant factor to me.

> of commercial CAs.  Such CA-certs will probably sell at a significant

Rumor has it that money talks with these CAs. Some will even sell you 
the right to issue certs for other domains (i.e., your very own sub-CA) 
for the right price.

> at a significant premium for every DNS domain one operates?

Well, when you put it that way...

> for only one specific impersonation attack,

Is there another type of impersonation attack on TCP port 443? I think 
I'm not understanding what you're saying here.

> but I'm not convinced that

Again, it doesn't make sense to me that the security model for 
protecting TCP port 443 should be optimized to allow for untrusted 
DNS/DNSSEC admins. But I can't tell if we're agreeing on this or not.

- Marsh

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 06 Oct 2010 23:17:47 +0200

People keep referring to the 100+ vendor CA jungle. It is somewhat 
impolite to point it out, but there are very few major vendors in this 
space, and these vendors have been implicated in some of the most 
publicized attacks. In some cases, hiding behind a "low-cost" brand name.

In other words, the problem with the TLS PKI is not (only) the small fish.

Thanks,
	Yaron

On 10/05/2010 02:46 AM, Martin Rex wrote:
[...]
> of the existing "TLS PKI" with>100 independent pre-configured

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 4 Oct 2010 23:32:19 -0700

> trustworthy is a completely distinct issue.

I think secure distribution of DNS records implies secure distribution of name to IP associations.  

Whether those records are <whatever/> depends on the practices of the domain administrator.  Is a 3rd party CA is more or less (likely to be) trustworthy than the relevant domain administrator?

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: der Mouse <[email-masked]>
Date: Tue, 5 Oct 2010 04:00:55 -0400 (EDT)

>> Incorrect characterisation.  DNSSEC provides only for secure
>> distribution of DNS records.  Whether the distributed DNS records
>> are accurate or trustworthy is a completely distinct issue.

Yes, it does, name-to-IP associations being one of the major things the
DNS is used for.

But the original statement was that DNSSEC provides "secure"
association from name to IP.  This is a stronger property than
providing secure distribution of name-to-IP mapping information; it
also implies that the creation of that information and its injection
into the distribution mechanisms are "secure" (whatever that means - I
note that none of these say what they are talking about being secure
against; perhaps I'm just missing context).

> Is a 3rd party CA is more or less (likely to be) trustworthy than the
> relevant domain administrator?

There are (at least moderately) common scenarios in which it's the one
way around; there are other similarly common scenarios in which it's
the other - at least for most types of trust; again, this doesn't give
much hint of the threat model of interest.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: "Carl Wallace" <[email-masked]>
Date: Tue, 5 Oct 2010 13:01:16 -0400

> You are working on wrong assumptions. The DV certs are exactly as
> strong as your DNS is. You only need to attack DNS to issue a DV cert.
> 
> Ondrej Sury

Certificate issuance is not the end of the game.  Clients have opportunity to avoid being fooled by a DV certificate if they choose.  Why disarm the client?

---

From: Doug Barton <[email-masked]>
Date: Sun, 10 Oct 2010 21:11:10 -0700

> against; perhaps I'm just missing context).

Sorry, almost nothing you wrote above is true. The only thing that 
DNSSEC has ever claimed to be able to do is provide a way for the end 
user of the DNS data to prove to herself that the data they received is 
the data that the administrator of the zone wanted them to have. The use 
of the word "security" in the name of the protocol extension was an 
incredibly unfortunate choice because it conveys all of the 
misunderstandings you listed above, and a lot more.

Doug

-- 

Breadth of IT experience, and    |   Nothin' ever doesn't change,
depth of knowledge in the DNS.   |   but nothin' changes much.
Yours for the right price.  :)   |		-- OK Go
http://SupersetSolutions.com/

---

From: Bruno Harbulot <[email-masked]>
Date: Mon, 18 Oct 2010 18:51:32 +0100

On 04/10/10 21:04, Phillip Hallam-Baker wrote:
> Some DV certificates are of very low quality. Which is why I would like
> to see the padlock icon phased out entirely. Why does the user need to
> know if encryption is being used at all?

I'm still not convinced about the greatness of EV certificates.

Why should an organization that wants to deploy its own PKI have to 
depend on one of the big players who've managed to get their signature 
hard-coded into browsers?

How beneficial are EV certs for the end-users? Green-bar secure v.s. 
Blue-bar insecure (or less secure) really is a confusing 
over-simplification.

A DV certs bind a cert to a domain, whereas an EV cert bind a cert to a 
company name. However, some companies use domain names that have nothing 
to do with their company name, and which could look like competitors 
instead: http://www.ietf.org/mail-archive/web/tls/current/msg06528.html

Best wishes,

Bruno.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 18 Oct 2010 14:19:02 -0400

Looks like your mail went into hyperspace somehow, it only just arrived.

EV is about accountability. The purpose of an EV cert is not to authenticate
the holder, it is to demonstrate that the holder stands a higher risk of
consequences that are designed to make it uneconomic to use EV certs for
typical Internet crimes.

They are certainly not the only security control that is needed in the
Internet, but they are a very usefull one.

On Mon, Oct 18, 2010 at 1:51 PM, Bruno Harbulot <
[email-masked]> wrote:

> Why should an organization that wants to deploy its own PKI have to depend
> on one of the big players who've managed to get their signature hard-coded
> into browsers?
>
> company name. However, some companies use domain names that have nothing to
> do with their company name, and which could look like competitors instead:
> http://www.ietf.org/mail-archive/web/tls/current/msg06528.html
>
>
> Best wishes,
>
> Bruno.

---

From: Martin Rex <[email-masked]>
Date: Mon, 18 Oct 2010 20:28:55 +0200 (MEST)

EV vs. DV is primarily about "risk management", based on the
flawed assumption that "green-bar" vs. blue-bar/white-bar 
would affect user behaviour.

Look at the real world:
signin.ebay.<country> uses an EV-Cert, probably because ebay may
have to pay for damages if someone steals user account credentials
and abuses them.

payments.ebay.<country> uses a DV-Cert, because the user bears all
risks from his payment data getting leaked.

-Martin