Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications

From: Basil Dolmatov <[email-masked]>
Date: Tue, 03 Aug 2010 14:48:04 +0400

01.08.2010 01:01, Jeffrey A. Williams пишет:
> Bill and all,
>
>    Your last point is a good one and I for one agree
> that such is, or may be a problem in some if not many
> instances.
>
In most of the instances...

In current world DNS-admin in _most_ cases have no connection with the 
domain owner, who is  _really_ the target of seeking the trust.

Not going far apart from obvious (implied) scheme of https:// it can be 
stated that the client with the browser at hand want to approach to the 
given legal entity in order to exchange some information (credit card 
number) that requires at least one-way trust...

I wonder how the any kind of trust can be built through the set of of 
people which are not bound by any legal means...

Going to the much more simpler question of establishing SSL/TLS 
connection, as it has been said already here, it does not require _any_ 
level of trust so can be established using _any kind of certs (even 
expired ones). This could be the situation when placing something in DNS 
will help, just to supply the interested party with _any_ cert of the 
given server.

dol@

>
> -----Original Message-----
>> From: [email-masked]
>> Sent: Jul 30, 2010 9:21 PM
>> To: Nicholas Weaver<[email-masked]>
>> Cc: Phillip Hallam-Baker<[email-masked]>, namedroppers<[email-masked]>
>> Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications
>>
>> 	the one thing that worries me is that trust is not transitive, the DNS admin
>> 	is generally not the sysadmin of the node in question and so syncronization
>> 	between the sysadmin and the DNS admin(s) is an exploitable channel.
>>
>> --bill
>>
>

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 4 Aug 2010 09:29:01 +0200

On 3 aug 2010, at 12.48, Basil Dolmatov wrote:

> In current world DNS-admin in _most_ cases have no connection with the domain owner, who is  _really_ the target of seeking the trust.

That might be true today, but it does not have to be true tomorrow. When the use of DNS and DNSSEC change, how we administer it needs to change as well.

	jakob

---

From: [email-masked]
Date: Wed, 4 Aug 2010 11:57:59 +0000

> That might be true today, but it does not have to be true tomorrow. When the use of DNS and DNSSEC change, how we administer it needs to change as well.

	well - that seems to lead to a fork.  one path would lead toward DNS admins taking
	over control of the end system admin function (Since we control the DNS, we have 
	sysadmin from your hosts);  and the second path leads toward sysadmins of the
	nodes holding the domain name taking over the operation of their own DNS.

	That second path is actually very much in line with one of the DNS design principles,
	that heirarchy is fundamentally a good thing.  However that path also leads to a much
	broader diversity in DNS admin expertise - and market trends over the past 15 year
	seem to indicate may are willing/eager to outsource their DNS to others.

	As long as you are also willing to outsource your sysadmin tasks (e.g. cloud computing)
	then I think the first fork  is viable. 

	IMHO, I do not beleive we will ever get rid of either fork, some will want the "ease"
	of completely outsourcing their services, others want to keep them in-house.  And 
	there will be the odd lot who split the two.

	Its not going to be easy to socially engineer a fundamental change in human nature.

-- bill

---

From: Gilles Massen <[email-masked]>
Date: Wed, 04 Aug 2010 15:37:40 +0200

Jakob Schlyter wrote:
>> In current world DNS-admin in _most_ cases have no connection with
>> the domain owner, who is  _really_ the target of seeking the trust.
>> 
> 
> That might be true today, but it does not have to be true tomorrow.

I think it's not even true today: there is always a relationship between
the DNS admin and the domain name owner, but it can range from loose
(e.g. registrar provided DNS) to very strong (same company, same
person). It's not that different to the hosting of a website, where the
content provider and the webserver operator can have any kind of
relationship.

Gilles

-- 
Fondation RESTENA - DNS-LU
6, rue Coudenhove-Kalergi
L-1359 Luxembourg
tel: (+352) 424409
fax: (+352) 422473

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 4 Aug 2010 07:08:50 -0700

>That might be true today, but it does not have to be true tomorrow. When the use of DNS and DNSSEC change, how we administer it needs to change as well.

It is not even true today. How could it be? The DNS admin makes the config that tells the world the data associated with the domain name. If the admin can tell the world data such as the A record associated with a domain name, he/she can tell the world the other data as well.

--Paul Hoffman, Director
--VPN Consortium

---

From: [email-masked]
Date: Wed, 4 Aug 2010 14:52:21 +0000

> It is not even true today. How could it be? The DNS admin makes the config that tells the world the data associated with the domain name. If the admin can tell the world data such as the A record a…

	so the DNS admin can tell the world what SSL certs are installed on the target node,
	what x509 certs are installed, what applications are running on the target node, etc?

	and why would the world beleive that the DNS admin has any clue as to the configuration
	and application profile of the target node?

--bill

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 4 Aug 2010 08:31:12 -0700

>	what x509 certs are installed, what applications are running on the target node, etc?

If there are standards for that, sure. Of course, there aren't, because you (I assume purposely) picked examples of things that discoverable through normal means. But if the IETF wants to define a DNS record that tells the world that, sure.

>	and application profile of the target node?

In your currently-unsupported examples, they would believe it because there was a standard for it. But, of course, there are no such DNS records, so this is probably not a fruitful exercise.

--Paul Hoffman, Director
--VPN Consortium

---

From: [email-masked]
Date: Wed, 4 Aug 2010 15:53:45 +0000

> In your currently-unsupported examples, they would believe it because there was a standard for it. But, of course, there are no such DNS records, so this is probably not a fruitful exercise.

	ah, but there -were- IETF standards for such foolishness (granted, back before
	DNSSEC) that were deemed totally broken, since the DNS admin and the host admin	
	were almost never the same person.

	Ref:  HINFO RRs.

	i.e.  what is the fundamental difference between a DNS RR that says:

	box.example.net	in a 169.254.0.13
			in hinfo httpd

	and

	box.example.net in a 169.254.0.13
			in sslcert "hex-string"

	in neither case does the admin of the domain example.net really have any clue
	what is supposed to be running on node "box".  Or does she? and if so, how?

--bill

---

From: Ted Lemon <[email-masked]>
Date: Wed, 4 Aug 2010 12:13:33 -0400

> 	box.example.net in a 169.254.0.13

The difference is that in the first instance, we are clearly relying on some mechanism other than DNSSEC to validate the cert for the http server at box.example.net.   In the latter case, we are relying solely on DNSSEC.   This makes DNSSEC a very juicy target for attack.   In the former case, attacking DNSSEC doesn't get you very much, but in the latter case, it allows you to impersonate the http server.

So to me the question you've raised leads to this: how much work are you willing to do to keep your own DNS server secure, and how much cash money are you willing to bet that the root is secure enough to make monetary transactions safe?   Because that's the bet you're making.   And while I applaud the folks running the root zone for their very well thought-out security protocol, I think putting this kind of pressure on the root key and all the keys down to your own domain is not something we've budgeted for.

If what you are proposing is that the SSL cert in the DNS be a *confirmation* of the validity of an SSL cert that's also been signed by a known CA, I think that's a different story, and if that is what you were proposing, then I don't think my objection is important.   I've only just started following this conversation, so I may have missed something.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 4 Aug 2010 09:25:10 -0700

>	box.example.net	in a 169.254.0.13

Errr, that's not the lame usage that is standardized in RFC 1035. RFC 1035 says:

HINFO records are used to acquire general information about a host.  The
main use is for protocols such as FTP that can use special procedures
when talking between machines or operating systems of the same type.

What RRTYPE were you thinking of when you wrote the above?

>	box.example.net in a 169.254.0.13

There is no fundamental difference. A host administrator tells the DNS administrator "I have a host I want called box.example.net. It is configured to respond at 169.254.0.13. Further, it has the following features that I believe there are DNS RRTYPES for: ...".

>	what is supposed to be running on node "box".  Or does she? and if so, how?

OOB communication. To turn your question around: how did the DNS admin find out that box.example.net is configured to respond on 169.254.0.13?

--Paul Hoffman, Director
--VPN Consortium

---

From: Alex Bligh <[email-masked]>
Date: Wed, 04 Aug 2010 17:29:49 +0100

--On 4 August 2010 12:13:33 -0400 Ted Lemon <[email-masked]> wrote:

> So to me the question you've raised leads to this: how much work are you
> willing to do to keep your own DNS server secure, and how much cash money
> are you willing to bet that the root is secure enough to make monetary
> transactions safe?   Because that's the bet you're making.   And while I
> applaud the folks running the root zone for their very well thought-out
> security protocol, I think putting this kind of pressure on the root key
> and all the keys down to your own domain is not something we've budgeted
> for.

As most SSL certificates are only domain validated, all an SSL certiticate
does is tell you that at some point in the past few years, the person
in possession of the certificate probably had control over the DNS for
that name (actually being able to spoof DNS and/or intercept email
to the domain is sometimes enough).

I don't see why it's fundamentally more risky to go straight to the
DNS.

-- 
Alex Bligh

---

From: [email-masked]
Date: Wed, 4 Aug 2010 16:40:11 +0000

> There is no fundamental difference. A host administrator tells the DNS administrator "I have a host I want called box.example.net. It is configured to respond at 169.254.0.13. Further, it has the f…

	right.  'cept in my current home case, the DHCP server hands out the IP (IPv6) address
	and dynamically updates the DNS.  :)  Sounds like more DHCP options to me...

	the DNSSEC tools then sign the whole zone (per the DNSSEC spec).

	other, non-DNS data has to come in via an OOB method to the DNS admin.  

> OOB communication. To turn your question around: how did the DNS admin find out that box.example.net is configured to respond on 169.254.0.13?

	bingo! see above.  DNS data, data about the DNS is passed into/through the DNS.
	non-DNS data has to come via OOB methods.  WHEN oob communications break down,
	then there is a transitive trust problem.  

	e.g. student body turnover on a college campus.  campus IT will hand out DNS data
	and (via DHCP) things like NTP and DNS servers, default routers, etc.

	there is little to no method to collect (in the USC case) host specific information
	from the 17,000 undergrads each quarter.

	This is the primary problem with using the DNS to store non-DNS related data.

---

From: Joe Abley <[email-masked]>
Date: Wed, 4 Aug 2010 12:46:59 -0400

> 	what is supposed to be running on node "box".  Or does she? and if so, how?

I continue to be confused by this.

If your argument is that you cannot rely upon DNS administrators to know what information to publish in the DNS with respect to applications run on infrastructure maintained by other people, then there's an obvious counter-example which you even helpfully include in your own message, above: the address (A/AAAA) record.

Joe

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 4 Aug 2010 12:59:13 -0400

It depends on how you do it.

1) Straight DNSSEC giving you only a signed A record has absolutely no
security value. All that is achieved is diverting attacks from the DNS
to the BGP.

2) Augmented DNSSEC with a certificate that is accredited via a CERT
or CERTHASH RR provides end to end cryptography with a very weak trust
chain.

3) Augmented DNSSEC with a certificate accredited as above plus a DV
trust chain accreditation for the DNSSEC Key Signing Key gives you end
to end cryptographic security with an endpoint that is as trustworthy
as their domain name.

4) Augmented DNSSEC with a certificate accredited as above plus an EV
trust chain accreditation for the DNSSEC Key Signing Key allows
greater security than is possible with either DNSSEC alone or SSL+EV
alone.

>From an apps point of view, #1 is really undesirable.

#2 is desirable in that it allows us to make it possible to turn on
strong encryption to a weakly trustworthy key at no cost. That in turn
means that we can start using browsers, web servers and email where
security is the default. This is what I think most people who complain
about CAs really want.

What you can't do with that level of security is to tell the user that
it is safe to give the site your credit card because the other end of
the connection is trustworthy. You have a secure tunnel to an
untrustworthy endpoint. So please do not think about turning on the
padlock icon.

Looking at this as a CA (ob Disclosure, I am now VP & PS at Comodo
Inc.), I am not at all concerned about this. Once someone is using
strong crypto with weakly accredited keys, it is much easier to
persuade them of the value of getting their key strongly accredited.

The value that the CA brings to the table here is that we say 'that
guy you are going to do business with is accountable'. And that is why
I started EV certs with Comodo when I was working for another CA.

Please try to understand the value proposition we bring to the table
before you assume that DNSSEC is useless or will replace the need for
us or whatever.

The common ground here is that we all want to make #2 happen. But lets
do that in a way that also enables #3 and #4. Because then instead of
a stupid and unproductive standards war between PKI and DNSSEC (one
that DNSSEC will lose), we can combine the strengths of both and go on
to do what we should have done in the first place.

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

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 4 Aug 2010 10:16:33 -0700

>	and dynamically updates the DNS.  :)  Sounds like more DHCP options to me...

Could be, sure. However, in the real world, many servers that run TLS don't get their addresses from DHCP: they are manually configured. The server admins tell the DNS admin the relevant information about their box.

>	then there is a transitive trust problem. 

The same is true when DHCP communication break down.

>	This is the primary problem with using the DNS to store non-DNS related data.

That last line is a non sequitur. It is not the type of information that seems to be your problem: it is the source of it. As you say above, there could be a DHCP option to fill in "non-DNS related data" at the same time as the A record is filled in.

--Paul Hoffman, Director
--VPN Consortium

---

From: [email-masked]
Date: Wed, 4 Aug 2010 17:42:06 +0000

> Could be, sure. However, in the real world, many servers that run TLS don't get their addresses from DHCP: they are manually configured. The server admins tell the DNS admin the relevant informatio…

	apparently we inhabit differnet "real" worlds :)

> That last line is a non sequitur. It is not the type of information that seems to be your problem: it is the source of it. As you say above, there could be a DHCP option to fill in "non-DNS related…

	Ok.. so I was making the distinction between data used by the DNS (as an application)
	and data used by non-DNS applications.  The DNS protocol does pretty well moving/passing
	DNS related data around - esp given thatthe target of the data is the DNS.

	Using the DNS for NON-DNS applications seems a bit specious, since there will be 
	constant debate about who has to talk to whom about coordinating what needs to happen
	when - OUTSIDE the DNS protocol.  Argues for either:

	pushing DNS administration to the host admin

	or

	pushing system administration to the DNS admin

---

From: Alex Bligh <[email-masked]>
Date: Wed, 04 Aug 2010 19:03:18 +0100

> I started EV certs with Comodo when I was working for another CA.

But EV accounts for only a tiny % of total number of certs
in issue, doesn't it? Obviously EV does more, but it seems to me
properly implemented DNSSEC does little less than non-EV certs.

-- 
Alex Bligh

---

From: Ted Lemon <[email-masked]>
Date: Wed, 4 Aug 2010 14:31:01 -0400

> I don't see why it's fundamentally more risky to go straight to the

That's certainly something to consider, but in fact the validation process is a *little* more stringent than that, ranging up to quite a bit more stringent (although the mechanism whereby this distinction is communicated to the end-user isn't particularly functional at the moment).

Also, risky or not, two separate confirmations done at separate times using separate systems make it quite a bit harder for an attacker to compromise the certification process.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 4 Aug 2010 14:33:33 -0400

> properly implemented DNSSEC does little less than non-EV certs.

For the case where all I want is a secure connection between the browser and the endpoint, and I have no trust for the endpoint, you are right, and I think Phillip said that.   The trick is to avoid creating a system based solely on the DNS that gets used for e-commerce.

---

From: Alex Bligh <[email-masked]>
Date: Wed, 04 Aug 2010 20:06:56 +0100

--On 4 August 2010 14:33:33 -0400 Ted Lemon <[email-masked]> wrote:

> For the case where all I want is a secure connection between the browser
> and the endpoint, and I have no trust for the endpoint, you are right,
> and I think Phillip said that.   The trick is to avoid creating a system
> based solely on the DNS that gets used for e-commerce.

Perhaps I am just cynical about EV. If you take a non-EV certificate,
and add EV, the difference to the normal user is the colour of their
browser bar. If they investigated further, they'd find that the
EV certificate is categorically and without question registered
to "Foo Trading Inc, of 1 Acacia Avenue [blah]". I'd argue that
for the majority of certificate holders (by number), that gives
the end user very little information of whether they will actually
get what they ordered, and it will conform to expectation.

If an EV type functionality was required for extended validation
of a DNSSEC secured name (i.e. if the customer wanted to know
who the name was registered to), a whois type function
would be just as good a technical solution, provided the
back end checks were the same. In some circumstances (e.g.
where the TLD/SLD is restricted to e.g. government entities)
that step is largely unnecessary. And if the customer merely
wants to know "they are buying from amazon.com" then
"amazon.com" DNSSEC validated is surely sufficient?

-- 
Alex Bligh

---

From: Alex Bligh <[email-masked]>
Date: Wed, 04 Aug 2010 20:10:49 +0100

--On 4 August 2010 20:06:56 +0100 Alex Bligh <[email-masked]> wrote:

> back end checks were the same.

I wrote that incredibly badly. I didn't mean a live whois
connection, I mean the registry signing the whois data.

-- 
Alex Bligh

---

From: Ted Lemon <[email-masked]>
Date: Wed, 4 Aug 2010 15:28:03 -0400

> back end checks were the same.

No, the point I was making is that they are very different.   In the case of EV validation, the company getting the validation is paying quite a bit of money for what's at least advertised as a fairly secure system.   The CA is supposed to keep their keys secure, so that it would be difficult to get an EV Cert without going through this process.   They charge a lot of money to pay for that security.   If you don't need that much security, you don't pay for it.   Everybody wins.

Contrast this with DNSSEC.   With DNSSEC, the root seems to be fairly secure.   Maybe COM will be too, someday, but will the level of security for COM be sufficient to trust for e-commerce applications, or the even higher degree of security required for banking?  What about the security of the bank's DNS service, which right now is probably outsourced?

If we were to entrust banking information to the ZSK for .COM, that would make the ZSK for .COM extremely valuable.   Keeping a key that's that valuable really secure will cost a lot of money.   I don't want to have to pay $100/year for every .com domain I have.   Most people don't.   Hence, .COM's ZSK is not going to be secure enough to be used for banking.

Even the potential pressure on .COM's ZSK is probably one reason why .COM isn't signed yet.   I haven't heard that said, but I suspect it's true.   If we make DNSSEC the basis for banking-level security, it will be too expensive to use for its actual intended purpose, which is making sure that the information in secure zones is not forged.

---

From: Basil Dolmatov <[email-masked]>
Date: Wed, 04 Aug 2010 23:45:18 +0400

> If your argument is that you cannot rely upon DNS administrators to know what information to publish in the DNS with respect to applications run on infrastructure maintained by other people, then t…

Yes. A record information _could_be_ equally unreliable... And the 
proper certificate is the means _to_check_ whether A-record information 
returned from DNS is _in_this_very_case_ reliable.

Putting cert information in the same DNS-zone implicitly states that 
_every_byte_ of information, which has come as a DNS-answer is totally 
reliable and could be trusted upon even financially.

Who will guarantee (give an insurance) this assumption? Who will stand 
forward and be willing to pay expenses and losses when and if this 
information happened to be wrong?

dol@

---

From: Alex Bligh <[email-masked]>
Date: Wed, 04 Aug 2010 20:48:01 +0100

--On 4 August 2010 15:28:03 -0400 Ted Lemon <[email-masked]> wrote:

> If we were to entrust banking information to the ZSK for .COM, that would
> make the ZSK for .COM extremely valuable.   Keeping a key that's that
> valuable really secure will cost a lot of money.   I don't want to have
> to pay $100/year for every .com domain I have.   Most people don't.
> Hence, .COM's ZSK is not going to be secure enough to be used for banking.

Who says it needs to cost $100 a year? There are 100 million domains
(approx) in .com. $10bn a year would, I suspect, be overkill even for this
security application. I suspect even $1 per domain ($100m / year) would be
more than sufficient to keep such a valuable ZSK secure. That gives (at
worst) comparable security to non-EV certs to 100% of registrants, at a far
lower cost, which is all (I would argue) all but 0.001% of registrants
actually need. Those 0.001% of registrant's requirements are not fixed by
EV certs alone anyway and have larger holes in their security usage they
don't choose to fix (look at the 3D-Secure mess for instance). I suspect we
may be wandering out of charter though.

-- 
Alex Bligh

---

From: Basil Dolmatov <[email-masked]>
Date: Thu, 05 Aug 2010 00:00:21 +0400

> If we were to entrust banking information to the ZSK for .COM, that would make the ZSK for .COM extremely valuable.   Keeping a key that's that valuable really secure will cost a lot of money.   I…
Please, keep in mind that all information that is coming into .COM zone 
from the registrars will be signed with ZSK of .COM zone nearly 
automatically.
So, you have no need at all to compromise .COM ZSK, yu have to perform 
the much easier task of compromising either database of one small 
registrars or data channel between the registrar and .COM zone whichever 
is easier (I bet for the first one).

Nearly all of TLDs have systems now which distributes "trust" to its 
registrars inherently.
But this "trust" concerns only manipulation with direction of 
information flows (A-records for all protocols, MX-records for SMTP), 
and one have the means to _check_ the validity of this direction with 
totally independent means (cert validating) and if something goes wrong 
- simply refuse to communicate in the wrong direction to the wrong 
recipient. So, the level of failure of this "trust" is quite limited - 
real service become _available_ until problem is rectified, so there are 
no direct possible financial losses, only indirect ones (waist of time 
and possibility).

Putting cert information in DNS will greatly raise the necessary level 
of trust (real, without the quotes), and this trust will demand either 
total restructuring of the current distributed domain and DNS 
registration system or ensuring the _equal_ security of all registrars 
involved.
Neither of it I think is feasible now.

dol@

---

From: Ted Lemon <[email-masked]>
Date: Wed, 4 Aug 2010 16:11:59 -0400

> is easier (I bet for the first one).

A very good point.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 4 Aug 2010 16:55:05 -0400

On its own DNSSEC does less than DV certs do.

The combination of DNSSEC plus certs is what is powerful. And there is
going to be a range of needs.

Only a small portion of Internet users are going to qualify for an EV
certificate. But they all need encryption.

Don't worry about the commercial side. Let the industry work that out.
I want DNSSEC to be a part of the best no-cost security solution, the
best low cost security solution and the best security solution.

---

From: Frederico A C Neves <[email-masked]>
Date: Thu, 5 Aug 2010 10:13:17 -0300

> > is easier (I bet for the first one).

Take in account that the current registration model gives you choices
of registrars. You could select the one that provides you the
adequate level of security for your domain needs.

At the currently x509 environment you could compromise one of the 60+
CAs present at mainstream browsers or one of the thousands of certs
resellers databases.

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 05 Aug 2010 16:20:17 +0200

> to end cryptographic security with an endpoint that is as trustworthy

This two points have in fact exactly the same strength as long as the DV 
cert is validated (and issued) by sending email to admin@<domain> (or to 
whois data) which is common these days.

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 5 Aug 2010 10:50:52 -0400

The difference is that under DNSSEC there is (currently) no means of
expressing the validation criteria in an authenticated form.

Modern browsers do not treat the 60+ roots as being directly
equivalent. They are only equivalent for the purpose of turning on
encryption, they are expressly not equivalent from the point of view
of the user experience. The DV user experience is pretty inconspicuous
and is likely to become more so. The EV user experience is
considerably more noticeable because the validation process is
establishing accountability.

Speaking as a CA, the idea of DNSSEC replacing DV validated
certificates is not a concern. I want as many people to use crypto as
possible as that gives me upsell opportunities from what we agree are
relatively weak validation processes to stronger ones.

Given that we have to impedance match the DNSSEC validated chains to
the existing browser infrastructure, it makes sense to use certs
(possibly self-signed, possibly CA-issued) to wrap the application
keys in the DNS.

In addition to the technical advantage of doing so (I do not want to
have to wait to rev the TLS standard, I want as few new code paths
being tested as possible), I can then drop in the business logic that
allows for control of liability. Specifically, I do not say 'this is
the key for example.com', I say, 'this is the key that I validated by
sending an email to [email-masked] and disclaim all warranties with
respect to that claim, asset a maximum liability of $50 per cert while
undertaking to insure transactions with respect to that certificate in
the amount of $50'.

Essentially I have managed to insert a little clickwrap license which
is likely to allow me to mitigate the risk of unlimited liability in
the case of a tort action since anyone who comes along and decides to
rely on this certificate to authenticate the digital signature on a
$500,000 mortgage agreement has been thoroughly warned.

Unlike some people who raise what they consider 'roadblock'
objections, I am raising issues for which I know the solution. I have
a proven track record in this industry that pre-dates the formation of
VeriSign. I have written a book on the subject, I reviewed parts of
Ford and Baum's book on the subject.

I would have brought up these issues earlier, but I rather needed
ICANN to sign the root and the less for them to worry about the
better. Everyone was waiting for ICANN to sign the root before they
acted.

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 05 Aug 2010 16:50:20 +0200

On 4.8.2010 21:28, Ted Lemon wrote:
>> If an EV type functionality was required for extended validation of
>> a DNSSEC secured name (i.e. if the customer wanted to know who the
>> name was registered to), a whois type function would be just as
>> good a technical solution, provided the back end checks were the
>> same.
>
> No, the point I was making is that they are very different.   In the
> case of EV validation, the company getting the validation is paying
> quite a bit of money for what's at least advertised as a fairly
> secure system.   The CA is supposed to keep their keys secure, so
> that it would be difficult to get an EV Cert without going through
> this process.   They charge a lot of money to pay for that security.
> If you don't need that much security, you don't pay for it.
> Everybody wins.
>
> Contrast this with DNSSEC.   With DNSSEC, the root seems to be fairly
> secure.   Maybe COM will be too, someday, but will the level of
> security for COM be sufficient to trust for e-commerce applications,
> or the even higher degree of security required for banking?  What
> about the security of the bank's DNS service, which right now is
> probably outsourced?

I agree that EV and DNSSEC-validated certs provide different type of 
service (identity vs. security).

But I don't agree with the security part on DNSSEC et al.  The security 
requirement is _already_ there.  As a proof I have just created FREE DV 
certificate for www.sury.org and it took me less than 10 minutes and it 
was validated by 2 (two) emails.

I would even say that the DV certificates are as strong as access to 
whois - with first email I have validated my email address and the 
second email went to the data in the whois.

And now tell me how the common internet user can distinguish from _real_ 
bank certificate and this one.  Will he even notice that the "green" bar 
is missing?

Ondrej

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 05 Aug 2010 16:52:51 +0200

> registration system or ensuring the _equal_ security of all registrars

Nope.  There is no increase in security.  If you can mangle MX to 
receive emails for that domain name then you can issue DV cert in less 
than 10 minutes for free.

Ondrej

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 5 Aug 2010 11:05:48 -0400

What you are doing here is to compare the weakest DV with DNSSEC and
concluding that DNSSEC is no worse.

There are some differences, they come from the fact that in SSL you
know the date the cert was issued, in DNSSEC you have no idea.

We don't really need to argue about this. Do you think that either DV
or DNSSEC certs merit telling the user that they are secure? Both are
strong enough to turn on crypto (as is a self-signed cert). Neither
merits a padlock icon.

I can't build a DNSSEC business by trying to undercut the price of DV
certs. If DNSSEC certs are free then CAs will be forced to make DV
certs free. You can already have a 90 day cert for free:

http://www.instantssl.com/ssl-certificate-products/free-ssl-certificate.html

Come on folks, you think you can disrupt an incumbent business with a
15 year head start by competing on price against their loss leader?

There has to be another advantage. Which is what I believe I have
found in preventing downgrade attack. In my book dotCrime Manifesto, I
describe how to use DNS policy records to fill in the missing pieces
on SSL and S/MIME.

On Thu, Aug 5, 2010 at 10:50 AM, Ondřej Surý <[email-masked]> wrote:
> I agree that EV and DNSSEC-validated certs provide different type of service
> (identity vs. security).
>
> certificate for www.sury.org and it took me less than 10 minutes and it was
> validated by 2 (two) emails.
>
> I would even say that the DV certificates are as strong as access to whois -
> with first email I have validated my email address and the second email went
> to the data in the whois.
>
> bank certificate and this one.  Will he even notice that the "green" bar is
> missing?
>
> Ondrej
> --
>  Ondřej Surý

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 05 Aug 2010 17:17:46 +0200

> concluding that DNSSEC is no worse.

And is that wrong?  How?

> know the date the cert was issued, in DNSSEC you have no idea.

And what benefit this does have?  Does anybody check the date of the cert?

> strong enough to turn on crypto (as is a self-signed cert). Neither

I am arguing that either both need to have the padlock or none of them. 
  So, yes no need to argue.

> found in preventing downgrade attack.

True.  The benefit from publishing "you should see this certificate" is 
also important piece of this DNSPKI (as I call it).  And I like that 
this enables to have SelfSigned+DNSSEC and EV+DNSSEC, and both will 
improve the situation.

O.

> On Thu, Aug 5, 2010 at 10:50 AM, Ondřej Surý<[email-masked]>  wrote:

---

From: Alex Bligh <[email-masked]>
Date: Thu, 05 Aug 2010 16:22:55 +0100

--On 5 August 2010 11:05:48 -0400 Phillip Hallam-Baker <[email-masked]> 
wrote:

> certs free.

You say it like this is a bad thing. I suspect many registries will
provide DNSSEC at no incremental costs. If this results in a drop in
the price of DV certificates, great.

-- 
Alex Bligh

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 5 Aug 2010 12:18:11 -0400

That assumes that VeriSign as the monopoly registry of .com is
prepared to incur substantial costs and liabilities with respect to
DNSSEC without charging additional fees for the new product.

Does this seem likely?

---

From: Alex Bligh <[email-masked]>
Date: Thu, 05 Aug 2010 17:38:49 +0100

Philip,

> DNSSEC without charging additional fees for the new product.

I wasn't thinking about .com, I was thinking about CCTLDs who tend
to have a different outlook in life and a different set of drivers.

If the result is that a CCTLD effectively included the equivalent of
a DV cert, and a .com didn't, I would expect Verisign to react, yes.
Even if the largest CCTLD is currently "only" 10% of the size of
.com.

-- 
Alex Bligh

---

From: Paul Vixie <[email-masked]>
Date: Thu, 05 Aug 2010 17:00:50 +0000

> Date: Thu, 5 Aug 2010 10:13:17 -0300
> From: Frederico A C Neves <[email-masked]>
> ...
> At the currently x509 environment you could compromise one of the 60+ CAs
> present at mainstream browsers or one of the thousands of certs resellers
> databases.

or, if you're a government, you could just demand from some in-country CA
a wildcard cert, to facilitate interception and wiretapping.  what a silly
system X.509/TLS is turning out to be.

---

From: Ted Hardie <[email-masked]>
Date: Thu, 5 Aug 2010 10:19:03 -0700

> system X.509/TLS is turning out to be.

A while back I suggested creating an RR that indicated which CA was expected to
sign any certs presented at the relevant host/domain.  A
DNSSEC-protected RR of this
type would allow the application to compare whether the cert presented
in a TLS session
came from the CA named in the RR.  That at least forces the government to get a
wildcard cert from each CA, and it would allow business and others to act based
on the reputation of the CA with regards to its willingness to issue wildcard or
other problematic certs.   You'd still have to use the normal PKI
checking methods
for the cert itself (has it been invalidated, is it too old etc.), but
this still seems to
me to get a reasonable balance between useful information and ease of
administration.  As long the CA doesn't change its issuer information and
the host/domain doesn't change CAs, this is close to file it and forget it.

When I last mentioned this, several pointed out that the functionality
was subsumed
by other more complex methods; this is true, but I still wonder
whether something
cheap and cheerful might not be valuable here.

regards,

Ted

---

From: Paul Vixie <[email-masked]>
Date: Thu, 05 Aug 2010 17:28:15 +0000

> Date: Thu, 05 Aug 2010 16:22:55 +0100
> From: Alex Bligh <[email-masked]>
> 
> provide DNSSEC at no incremental costs. If this results in a drop in the
> price of DV certificates, great.

ouch!  right in the middle of Hart-Scott-Rodino on the verisign/symantec
transaction, and with a quote from a former verisign employee, too.
"that's gotta hurt."

+1, though.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 5 Aug 2010 14:01:41 -0400

Colleagues,

<moderator-hat>

> Even if the largest CCTLD is currently "only" 10% of the size of

This is not to pick on Alex, but a general observation.  The
discussion here seems to be drifting very far from the remit of
dnsext.  How X.509 works is pretty clearly not our problem.  Moreover,
Olafur and I already suggested that, whereas the topic of support for
applications, and APIs generally, are interesting and acceptable
topics for the list, we're not going to add work items in this general
area: it's too far outside our remit.

It'd be good if we cooled heads on this topic.

Thanks,

Andrew

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 5 Aug 2010 14:46:50 -0400

And you think that the .cc registries will be immune from such pressure?

We already know that ICANN is not.

Security issues are always easy to solve if you are allowed to pretend
that you have one entirely trustworthy actor that can be trusted to do
the right thing. If we are going to hypothesize about defection by the
trusted parties then you have to show why your favored trusted parties
which operate under monopoly government contract are more trustworthy
than the ones you criticize.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 5 Aug 2010 14:49:35 -0400

That is a very sensible and useful suggestion.

I had not considered that precise configuration, but I have earlier
proposed a similar one. There are some slight complications to be
considered (not all applications can chain to the same root so there
will be roots not a root). But I think the basic principle is sound.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 5 Aug 2010 17:35:42 -0400

Ok, to repeat more strongly my earlier moderator-hat remark: please stop with the strongly worded arguments about security models &c.  Thanks. 

-- 
Andrew Sullivan
<[email-masked]>

---

From: Alex Bligh <[email-masked]>
Date: Fri, 06 Aug 2010 00:33:37 +0100

> area: it's too far outside our remit.

Actually, picking in me would be fair enough, as I suspect most of
this tangent is my fault. Sorry. xTLD operator business models
are definitely not on charter.

Question to chairs so I don't get myself further into trouble:
is interface to DNSSEC (e.g. library calls
where library may or may not include stub resolver) on charter?
Is discussion of potential use of DNSSEC to replace/augment
SSL certs (from a technical point of view) on charter? I
suspect the answers are "yes" and "no" respectively.

-- 
Alex Bligh

---

From: Tony Finch <[email-masked]>
Date: Fri, 6 Aug 2010 18:27:22 +0100

On Wed, 4 Aug 2010, [email-masked] wrote:
>
> well - that seems to lead to a fork.  one path would lead toward DNS
> admins taking over control of the end system admin function (Since we
> control the DNS, we have sysadmin from your hosts);  and the second path
> leads toward sysadmins of the nodes holding the domain name taking over
> the operation of their own DNS.

The second path is already happening, to support certain kinds of load
balancing appliances. However even packaged solutions are not immune to
your warning about bad DNS installations - see for example
http://fanf.livejournal.com/107721.html

There's a third possibility that applications could use dynamic updates to
publish their metadata in the DNS. I'm not sure how this can be made easy
enough to be deployable, though.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
THAMES DOVER: SOUTH VEERING SOUTHWEST, 4 OR 5, OCCASIONALLY 6 AT FIRST. SLIGHT
OR MODERATE. OCCASIONAL RAIN, THEN SHOWERS. MODERATE OR GOOD, OCCASIONALLY
POOR.

---

From: Tony Finch <[email-masked]>
Date: Fri, 6 Aug 2010 18:39:40 +0100

On Wed, 4 Aug 2010, [email-masked] wrote:
>
> ah, but there -were- IETF standards for such foolishness (granted, back
> before DNSSEC) that were deemed totally broken, since the DNS admin and
> the host admin were almost never the same person.
> 	Ref:  HINFO RRs.

I think you mean "are" not "were" - see MX, SRV, SSHFP, NAPTR, CERT.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
SHANNON ROCKALL MALIN HEBRIDES: CYCLONIC IN MALIN AT FIRST, OTHERWISE
NORTHERLY OR NORTHWESTERLY 5 TO 7, DECREASING 4 OR 5. MODERATE OR ROUGH.
SHOWERS THEN FAIR. MODERATE OR GOOD.

---

From: Tony Finch <[email-masked]>
Date: Fri, 6 Aug 2010 18:46:19 +0100

On Wed, 4 Aug 2010, [email-masked] wrote:
> > OOB communication. To turn your question around: how did the DNS admin
> > find out that box.example.net is configured to respond on
> > 169.254.0.13?
>

Data about the DNS is configured out-of-band too - i.e. delegations are
configured using non-dns protocols. I don't see any fundamental difference
between a delegated zone and an application's configuration.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
WIGHT PORTLAND PLYMOUTH NORTH BISCAY: SOUTHWESTERLY VEERING WESTERLY OR
NORTHWESTERLY, 4 OR 5, OCCASIONALLY 6 AT FIRST. MODERATE, OCCASIONALLY ROUGH
IN PLYMOUTH AND NORTH BISCAY. RAIN OR SHOWERS, FAIR LATER. MODERATE OR GOOD,
OCCASIONALLY POOR.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 6 Aug 2010 21:29:33 -0400

Yes we could beef up the protocols for dynamic update. But it is not
possible to correctly configure the DNS by means of applications
maintaining their own entries (I tried).

The corner case that caused me to abandon this idea is the case where
I have 4 mail servers (or SRV advertised Web Services) that I want to
load balance between them. The load balancing data requires real-time
update so that servers that are under load can tell the DNS to slacken
off.

The problem here is that there is no way to do this unless the servers
know what their load is relative to the other servers. If you have two
servers that are both at 100% load they will wind down their
priorities to zero. OK, well maybe there is, but I can't get my mind
round how to do it as pure peers and if I could the algorithm would
have to assume a certain set of optimization objectives.

This works even less well when there are dependencies and resource
contentions. For example, the mail server is also the auth server.

These are not issues that I think can be addressed except on a site
policy basis. And any site policy is best concentrated in a service
registration service accessed via SRV record, not mangled into the DNS
publication system.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 7 Aug 2010 07:34:04 -0700

>maintaining their own entries (I tried).

The fact that one person tried and failed is not an indicator that it cannot work if many people try.

>have to assume a certain set of optimization objectives.

The IPsec world has this exact problem, and initial attempts to solve it were clumsy, but there are now many vendors with robust solutions to the load-balancing problem based on solutions that map well to the SRV solution.

I propose that we don't give up on "correctly configure the DNS by means of applications maintaining their own entries". It has huge benefits for making the DNS responsive to the end nodes for which it serves data.

--Paul Hoffman, Director
--VPN Consortium

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 7 Aug 2010 12:35:59 -0400

What I am saying here is that while it may appear that configuring the
DNS is simply a matter of the endpoints telling the DNS what records
to advertise for it, the problem is more involved.

While you can extend any protocol to serve any purpose, I think that
there is a natural break here and this problem is best addressed in a
separate protocol. Which is in fact the current situation since many
people already have DHCP configured so that when a host requests an IP
address in DHCP, the relevant entry is pushed out to the DNS.

I don't think overloading DHCP is a good approach either, I think we
need a new protocol.

While it might be possible to address the problem I raise in the
context of DNS, it would take considerable ingenuity to do so. If we
have a decomposition of the problem where one approach requires
research and another is straightforward, I suggest we go for
straightforward.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 7 Aug 2010 10:19:26 -0700

>to advertise for it, the problem is more involved.

Thank you for the correction. "is more involved" is quite different than the "is not possible" that you claimed earlier.

>context of DNS, it would take considerable ingenuity to do so.

And you are claiming that we don't have enough of that here?

> If we

I propose that we do both. Having different protocols for different deployment scenarios (that is, different hosts will have different levels of introspection and communication with peers) is appropriate.

--Paul Hoffman, Director
--VPN Consortium

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 7 Aug 2010 13:47:58 -0400

Sure, but apropos the charter discussion, are you proposing to have
DNSEXT look at the DNS way of doing this and another group look at how
to do it with a dedicated protocol?

I think it would be better to have one working group look at this
whole issue and then specify whatever DNS records or whatever are
required with advice from this WG.

---

From: Florian Weimer <[email-masked]>
Date: Mon, 09 Aug 2010 10:08:41 +0000

> 	ah, but there -were- IETF standards for such foolishness
> 	(granted, back before DNSSEC) that were deemed totally broken,
> 	since the DNS admin and the host admin were almost never the
> 	same person.

But that ship has already sailed.  nowadays, DNS doesn't provide
addresing for hosts (individual machines), but for a more abstract
service.  People do not access the host named "www" in the
"example.com" zone, but a web server on "www.example.com", and chances
are good that this isn't even the primary host name of the box.  In
such an environment, the DNS administrator already has to know quite a
lot about the organization's infrastructure (which servers can handle
what load etc.).  Maybe the person actually making the changes to the
zone does not know all the details, but the process around zone
updates surely has to take them into account.

I really don't see how putting public key material would constitute a
fundamental change of the DNS model.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99