Subject: [dnsext] Re: A custom DNS record for mandatory SSL/TLS

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 24 Feb 2009 16:29:47 +0100

> http://www.circleid.com/posts/20090105_problem_with_https_ssl_md5/

And an (IMHO) improved version of the same proposal here:

http://www.circleid.com/posts/20090219_https_web_hijacking/

[...] First, we use DNS to publish a list of websites that must
operate in HTTPS through custom DNS records. Second, the web browser
will automatically force a connection to an HTTPS page if instructed
to do so by DNS and it will maintain a list of websites that are only
to operate in secure HTTPS mode. We do this second part because we
cannot always assume that DNS is trustworthy especially in the case of
wireless hotspots. The DNS mechanism would only work as a toggle on to
force HTTPS for all future web browsing sessions but it would not be
permitted to toggle off HTTPS unless it was a trustworthy DNSSEC
server. [...]

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 24 Feb 2009 17:08:21 +0100

> permitted to toggle off HTTPS unless it was a trustworthy DNSSEC

Second time that guy posts the same thing, I guess he thinks repeating
himself helps, original 'article':
http://www.circleid.com/posts/20090105_problem_with_https_ssl_md5/

My simple attack vector for this case: on an 'unsecured network' publish
that a site is HTTPS-only, while it is not (which is the case a lot of
times) and voila, you have denied the user access to that site forever
as it won't come out of that mode unless you do trickery again, when
trickery is possible... ;)
This "HTTPS-only-mode-never-get-out should only be entered when you are
sure that the record you get back is real and valid. There is of course
also always a chance that a site comes out of HTTPs mode, how do you
retract those records?

Remember that the biggest issue is a user and interface problem, they
click everywhere and they can't know if the site they are going to is
really the site they are going to. Especially as long as one can get
certificates for sites like p4ypal.com.

oh, and nevertheless, see also:
https://media.blackhat.com/bh-dc-09/video/Marlinspike/blackhat-dc-09-marlinspike-slide.mov
Who cares that one forces SSL again?

Greets,
 Jeroen

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 24 Feb 2009 17:13:43 +0100

I would go one step further. Publish SSL fingerprint into DNS and flag
it as mandatory (or not).
We already have SSHFP, so why we don't create SSLFP in form like this:

owner IN SSLFP(or some other name)
proto_and/or_port?(HTTPS,SMTPS,POP3S,IMAPS,TELNET-SSL,FTP/TLS)
mandatory(0/1) hash_algo(SHA1/SHA2) sslfp

And with DNSSEC you can even use self-signed cert (duck and hide),
since the trust chain
is already established. Without DNSSEC it will need to go through
usual CA check.

Ondrej.

-- 
 Ondrej Sury
 technicky reditel/Chief Technical Officer
 -----------------------------------------
 CZ.NIC, z.s.p.o.  --  .cz domain registry
 Americka 23,120 00 Praha 2,Czech Republic
 mailto:[email-masked]  http://nic.cz/
 sip:[email-masked] tel:+420.222745110
 mob:+420.739013699     fax:+420.222745112
 -----------------------------------------

---

From: Ted Lemon <[email-masked]>
Date: Tue, 24 Feb 2009 09:27:20 -0700

I think it's important to avoid tying DNSSEC and SSL security  
together.   When you have to crack both DNSSEC *and* SSL to fool a  
browser, that's better than when you can crack just DNSSEC or just SSL  
and fool a browser.   So I am skeptical of plans to publish SSL  
information in the DNS secured by DNSSEC - I don't think you've  
actually fallen down the slippery slope here, but you're treading on  
the verge.

I think that to really address this problem, there needs to be some  
concept of a relationship with a site.   Rather than just validating  
the connection from scratch each time you connect, you remember  
something about the connection from visit to visit, and this allows  
you to detect a spoof.   But of course this is far afield from the DNS  
- I mention it only because I think if you try to push too much  
responsibility on the DNS, you will wind up making things *less*  
secure, not more.   DNSSEC should secure the DNS, and nothing more.

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 24 Feb 2009 17:37:33 +0100

> trickery is possible... ;)

But does this really change anything? 'Unsecured network' could publish
different A record - and you have same denial as with mandatory-SSL.
Or am I missing something?

Ondrej.

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 24 Feb 2009 17:43:49 +0100

> Or am I missing something?

When you leave the 'unsecured network' this "special record" (special
also because it came from the attacker) is recorded for eternity stating
"this is an SSL only site".

DNSSEC could resolve that of course ;)

Ted Lemon wrote:
> information in the DNS secured by DNSSEC - I don't think you've actually
> fallen down the slippery slope here, but you're treading on the verge.

Unless we do away completely with SSL of course and use DNS to
distribute the key information instead ;) [*]

Greets,
 Jeroen

* = Generating DNSSEC keys upto now didn't have a cost yet and they
effectively come along with your domain. SSL certs though you have to
cough up.

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 24 Feb 2009 17:44:02 +0100

Ted Lemon wrote:
> concept of a relationship with a site.   Rather than just validating the
> connection from scratch each time you connect, you remember something
> about the connection from visit to visit, and this allows you to detect
> a spoof.   But of course this is far afield from the DNS - I mention it
> only because I think if you try to push too much responsibility on the
> DNS, you will wind up making things *less* secure, not more.   DNSSEC
> should secure the DNS, and nothing more.
> 
> 
> --

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 24 Feb 2009 08:57:29 -0800

>>>>> On Tue, 24 Feb 2009 16:29:47 +0100, Stephane Bortzmeyer <[email-masked]> said:

SB> And an (IMHO) improved version of the same proposal here:

SB> http://www.circleid.com/posts/20090219_https_web_hijacking/

FYI, here's an older presentation about the same sort of solution:

http://www.w3.org/2005/Security/usability-ws/presentations/24-ozment-dont-rely
-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

---

From: Paul Vixie <[email-masked]>
Date: Tue, 24 Feb 2009 17:46:48 +0000

one of the many reasons i've been pushing for ubiquitous dnssec is so that
we can dump x.509 into the wastecan of history.  web users should not have to
know whether to use https or http, and browser vendors should not be in a
position to charge money for the inclusion of x.509 roots.  once dns is secured
we'll see innovation in the browser/server communications security space again.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 24 Feb 2009 17:52:09 +0000

> DNSSEC should secure the DNS, and nothing more.

dnssec will secure everything that's in the dns.

---

From: Michael StJohns <[email-masked]>
Date: Tue, 24 Feb 2009 13:08:57 -0500

This comes under the heading of  "HUH?"

Are you saying that DNSSEC should replace the authentication portion of a TLS negotiation?  Or that DNSSEC replaces TLS (and X.509)?  Or that DNSSEC can be used to do digital signatures over documents?

Or something else?

---

From: Ted Lemon <[email-masked]>
Date: Tue, 24 Feb 2009 11:12:11 -0700

> we'll see innovation in the browser/server communications security  

That would be great!   However, what is the total yearly value  
protected by DNSSEC?   What is the total yearly value protected by x. 
509?   How much more work will people be willing to do on subverting  
the DNS when all that x.509-protected value gets dumped into the  
DNSSEC bucket?

I am not arguing that x.509 is the right thing.  But you and I have  
both worked for organizations in the past whose motto was "one  
company, one egg, one basket."   And that worked out *so* well.

Like you, I look forward to the day, hopefully soon, when my DNS  
queries are protected by DNSSEC.   However, were my credit card  
transactions to be protected by DNSSEC alone, I would be very, very  
worried.

---

From: Michael Graff <[email-masked]>
Date: Tue, 24 Feb 2009 12:20:07 -0600

> Or something else?

I read what he said as "Once DNSSEC makes DNS secure, just think of all
the wonderful things that enables."

- --Michael

---

From: Paul Vixie <[email-masked]>
Date: Tue, 24 Feb 2009 18:36:46 +0000

Michael StJohns <[email-masked]>:
> Are you saying that DNSSEC should replace the authentication portion of a
> TLS negotiation?

not that it "should" but rather that it inevitably "will".  i'm thinking of
an opportunistic system whereby the presence of a secure _HTTPS._TCP SRV RR
and a secure CERT RR whose fingerprint matches that of a self-signed on-wire
TLS certificate will obviate the on-disk X.509 CA for trust arbitration.  or
something else will come along; the internet is full of smart people who want
to get rich and dnssec's going to be helpful.

> From: Ted Lemon <[email-masked]>
> 
> That would be great!

yes, in the sense that glass ceiling and controlled-entry-sandbox destruction
and technological disintermediation is often great.

> Like you, I look forward to the day, hopefully soon, when my DNS queries
> are protected by DNSSEC.  However, were my credit card transactions to be
> protected by DNSSEC alone, I would be very, very worried.

i am already very, very worried about the number of X.509 MD5 hashes out in
the world, by the number of X.509 CA's and resellers who don't check ID
when granting bits, by the lack of transparency or oversight in the process
by which opera, mozilla, microsoft, apple, KDE, and google add new root CAs
to their browsers... your credit card is already meat on the hoof.  even if
you could somehow keep dnssec from killing x.509, you would not want to,
since only more free and open innovation is going to get us out of our long
standing browser security mess.  we're going to make security ubiquitous.
it will not be possible, ten years after the root is signed, to find an
unsecure web server anywhere in the developed world... because secure ones
won't cost more and they won't be harder to set up or operate.

if the only point to dnssec was to secure the data already in the dns, there
would be no way to cost-justify that benefit.  however, when you count all
the data that's not in the dns BECAUSE DNS IS NOT SECURE, and re-ask the
question, the costs of dnssec become insignificant.  that's the ball game.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 24 Feb 2009 14:43:27 -0500

<no-hat>

Ted,

The purpose of DNSSEC is to protect DNS data to enable "more reliable"
operation of DNS.

Once DNS data is protected, DNS can be used to distribute higher
"value" contents, such as keying information for various services.

The questions is:
Can we tell people about some of the possible uses before
DNSSEC is widely distributed ?

Later on people need to ask:
How appropriate is it to store information X in DNS?

IMHO, saying right now if and how X is stored in DNS is premature.

         Olafur (just myself no hat)

---

From: Ted Lemon <[email-masked]>
Date: Tue, 24 Feb 2009 13:08:30 -0700

> The purpose of DNSSEC is to protect DNS data to enable "more reliable"

With this I completely agree.

> "value" contents, such as keying information for various services.

With this I don't.

> DNSSEC is widely distributed ?

Obviously we can.   :')

> IMHO, saying right now if and how X is stored in DNS is premature.

I think having a big debate about it now is probably premature, simply  
because to me the DNSSEC has value whether you agree with my position  
or yours and Paul's, for the reason you stated at the top of your  
message.   But the reason why I interjected now is that again, whether  
one agrees with you and Paul, or with me, it is in fact premature to  
be talking about stuffing SSL fingerprints into the DNS.

And whether I like it or not, whether it's done with TXT records or  
purpose-specific records, I think once DNSSEC is widely deployed  
people very definitely will try to secure things other than DNS with  
DNSSEC.

Some of them will work out fine; others may create dangerous profit  
incentives.   Internet protocols have been designed in the past  
without accounting for the cleverness or motivation of thieves and  
scammers.   I think it's worth reminding ourselves of that as we start  
to bite off larger and larger chunks of the security problem space.

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 24 Feb 2009 12:30:21 -0800

> DNSSEC is widely distributed ?

It is actually these uses where the real value of DNSSEC lies.

DNS data per se is NOT valuable from a security viewpoint.  Well it is  
but it isn't.

It is valuable to out-of-path adversaries (eg, conventional cache  
poisoning), but it isn't really valuable to in-path adversaries (eg,  
someone on the wire), save for the recursive resolver (who's an in- 
path adversary for DNS but out-of-path for everything else).

Basically because any protocol that is resistant to in-path  
adversaries never trusted the DNS name in the first place, while every  
protocol that trusts the DNS name is also vulnerable to in-path  
adversaries.

What DNSSEC buys, practically, is a LOWER COST PKI.  The domain owners  
already have contractual relationships with the registrars, just like  
in a PKI.  So turning on DNSSEC gives a "PKI for free", which as a  
bonus has fewer roots of trust which can be screwed up.

Thus instead of Verisign charging $100 per cert per name, DNSSEC  
allows one to use the normal DNS registration process and then mint  
arbitrary certificats within your domain.

Thus I not only think that focusing on these uses is valuable, but  
ESSENTIAL.

---

From: Thierry Moreau <[email-masked]>
Date: Tue, 24 Feb 2009 16:31:23 -0500

> dnssec will secure everything that's in the dns.

Just like SSL/TLS and X.509 nowadays secures everything on the web that 
deserves "security".

When DNSSEC will take the lead, you'll see the same lousy operational 
habits of CAs in registrars' operations. But great, you will spare the 
waste of time reading liability disclaimers in X.509 certification 
practice statements!

The same idea can be explained differently. If DNSSEC provides enhanced 
integrity assurance between registry and validating resolvers, this is 
far from "securing" any DNS contents semantic.

The argument that DNSSEC provides no more than data origin 
authentication (which turns into enhanced integrity assurance) between 
registry and validating resolver is used to avoid liability and policy 
issued surrounding DNSSEC deployment. The argument should not later be 
ignored when the ultimate technology potential is used as a promotion 
argument.

Regards,

-- 

- Thierry Moreau

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 24 Feb 2009 22:48:04 +0100

> the DNS when all that x.509-protected value gets dumped into the  

I think we have:

- DNSSEC for securing the domain names
- X.509 for encryption of the connection (and possibly, but  
questionable, authentication of the server)
- Authentication on the application layer for authentication and  
authorization

I.e. this is not an OR question. We need any (and all) security  
mechanisms we can find.

    Patrik

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Mon, 23 Feb 2009 16:46:56 -0800

Ted and all,

  Ted, FWIW, and IMPO your absolutely correct.  The other problem
that has been one for some time is what/who is or is not a valid or
trusted CA.

Regards,

Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln
"YES WE CAN!"  Barack ( Berry ) Obama

"Credit should go with the performance of duty and not with what is
very often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS.
div. of Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail
[email-masked]
My Phone: 214-244-4827

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Mon, 23 Feb 2009 16:56:15 -0800

Paul and all,

  Very good point.  However what does such a notion do for the
NOW?  Later far often as you likely know, never comes or in the
instances when it does often times creates yet more confusion,
conterversy, and ill suited inovations with great marketing jingo's.

Regards,

---

From: Alex Bligh <[email-masked]>
Date: Tue, 24 Feb 2009 23:16:09 +0000

--On 24 February 2009 18:36:46 +0000 Paul Vixie <[email-masked]> wrote:

> not that it "should" but rather that it inevitably "will".  i'm thinking
> of an opportunistic system whereby the presence of a secure _HTTPS._TCP
> SRV RR and a secure CERT RR whose fingerprint matches that of a
> self-signed on-wire TLS certificate will obviate the on-disk X.509 CA for
> trust arbitration.  or something else will come along; the internet is
> full of smart people who want to get rich and dnssec's going to be
> helpful.

If I understand you right, this gels with something I was thinking of,
though I think my idea is slightly simpler (no SRV record needed)
i.e.
	_http._tcp.www.example.com. IN	CERTHASH	SHA256-[xxx]
Where [xxx] is the fingerprint of a self-signed TLS certificate (and
SHA-256 the hash method used).

The browser simply sees the CA used is not in its internal list, so does
a single DNS(SEC) query to retrieve the key. Of course it could try
DNS(SEC) first whatever.

I don't see the need for an additional SRV record, unless you meant simply
to ensure http:// users automatically use https: without relying on
a redirect that might be intercepted. If so, that's presumably specific
to protocols that don't support TLS on the same port (e.g. not SMTP).

Alex

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Mon, 23 Feb 2009 17:03:36 -0800

Ted and all,

  This is not a new debate as you seem to believe.  I along
with others have had this debate with Paul and others several
times some time 5 years? ago.  Yet there was little resolved than
and taking back up this debate again may yeld better results, the
debating points are not all that different.

Regards,

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Mon, 23 Feb 2009 17:07:05 -0800

Patrik and all,

  Your conclusion is Exactly right!  Unfortunately there are those
that would like to mitigate that conclusion for reason or reasons
that remain unclear and are perhaps of less than ethical intent.

Patrik Fältström wrote:

>   ------------------------------------------------------------------------
>                  Name: PGP.sig
>    PGP.sig       Type: application/pgp-signature
>              Encoding: 7bit
>           Description: This is a digitally signed message part

Regards,

---

From: Ted Lemon <[email-masked]>
Date: Tue, 24 Feb 2009 16:27:07 -0700

On Feb 23, 2009, at 6:03 PM, Jeffrey A. Williams wrote:
> times some time 5 years? ago.

I know, and perhaps I should apologize for bringing it up.   Last time  
I was involved in this debate, I was on the other side.   :'}

---

From: Tony Finch <[email-masked]>
Date: Wed, 25 Feb 2009 17:00:25 +0000

On Tue, 24 Feb 2009, Thierry Moreau wrote:
>
> When DNSSEC will take the lead, you'll see the same lousy operational habits
> of CAs in registrars' operations.

DNS registrars have already been making the news for their bad habits.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.

---

From: Michael StJohns <[email-masked]>
Date: Wed, 25 Feb 2009 13:54:26 -0500

At 01:36 PM 2/24/2009, Paul Vixie wrote:
>not that it "should" but rather that it inevitably "will".

The last time I remember hearing where one thing would inevitably replace another was communism replacing capitalism.  I'm pretty sure that hasn't happened yet and  I'm pretty sure my crystal ball does not agree with yours with respect to the reach of DNSSEC or even the deployment of DNSSEC.

Like it or not, DNS is an ancillary system - it's not absolutely required to actually make traffic move from one system to another.  If I have an IP address for my destination, I can get traffic through.  Failures at the DNS level may be disruptive, but critical traffic can still get through. 

SSL/TLS uses an in-band mechanism for authentication - at time of connection it requires no referral to an external system which means even in the absence of DNS it works.  Adding DNSSEC as an absolute requirement to get a secure connection seems to be adding fragility and complexity where it is not needed.  It also begs the question of whether or not you could do the equivalent of mutual authentication with your approach (e.g. client AND server certificates).  And finally, if I really do want real-time checks on validity, there's OCSP which I can turn on or off at will.

I've got a few systems at home.  I don't run my own DNS zone, but I do run my own CA for SSL.  It works fine and can be managed on the system level. I really have no desire to have to run yet another server just to get traffic through.

With respect to your comments below about MD5 hashs.  CA certs are somewhat equivalent to trust anchors and we mostly haven't figured out how to either deploy or replace trust anchors in DNSSEC,  TARs, RFC5011 and DLV notwithstanding.  Pointing to DNSSEC as the savior of the old CA problem seems to be sophistry absent a real solution on DNSSEC's part.  If your solution is "one root trust anchor to rule them all and in darkness bind them" - the guys with the CAs actually examined the security model for that and found it wanting - hence some 50 or so CA certs in your browser.  

With respect to not checking ID etc - these are operational concerns that aren't going to be magically solved by sprinkling DNSSEC pixie dust over them.  In the CA case, I know which ones operate in a manner which I repose confidence - those are the ones enabled in my browser.  I could wish for a third party Underwriters Lab for CAs and an automated way to update my trust states, but the market probably isn't there.  

> i'm thinking of

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 25 Feb 2009 20:51:53 +0100

Michael,

> The last time I remember hearing where one thing would inevitably replace another was communism replacing capitalism.  I'm pretty sure that hasn't happened yet and  I'm pretty sure my crystal ball…

And inevitably neither communism nor capitalism works when people are
involved :). (But let's not discuss it on-list, please.)

> Like it or not, DNS is an ancillary system - it's not absolutely required to actually make traffic move from one system to another.  If I have an IP address for my destination, I can get traffic th…

I agree.

> SSL/TLS uses an in-band mechanism for authentication - at time of connection it requires no referral to an external system which means even in the absence of DNS it works.  Adding DNSSEC as an abso…

I don't think that DNSSEC should and will be mandatory - but at places
where you need just TLS, but you don't need to know who the cert
belongs to (consider current status with SMTPS), then DNSSEC signed
fingerprint could actually increase security. By putting fingerprint
into DNS you are saying - this server should use key with this
fingerprint - nothing more, nothing less. Look at SSHFP RFC - same
situation.

> I've got a few systems at home.  I don't run my own DNS zone, but I do run my own CA for SSL.  It works fine and can be managed on the system level. I really have no desire to have to run yet anoth…

And nobody should force you. But an option to running own CA could be
just putting the fingerprint into the DNS without all the complexity
involved when running your CA. (Again compare it to SSHFP).

Ondrej

---

From: Paul Vixie <[email-masked]>
Date: Wed, 25 Feb 2009 20:06:03 +0000

> The last time I remember hearing where one thing would inevitably replace
> another was communism replacing capitalism.

well, a lot of us said that commercial unix would be replaced by open
source.  and ballmer is apparently more worried about linux than he is
about apple.  and far more recently than "we will bury you" (khrushchev)
was "tear down this wall" (reagan).  but this all seems so off-topic.

in any case we don't need to argue, i'm not making a proposal but rather
a prognostication.  in a few years we'll see who was right.  i'm patient.

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 25 Feb 2009 15:38:34 -0500

Almost all security protocols / algorithms / etc. provide only tools
which enable security when they are properly used. It is hardly
surprising that there will be some DNS zones with DNSSEC deployed but
poor / null security due to bad operational practices.

Donald

-- 
=============================
 Donald E. Eastlake 3rd   +1-508-634-2066 (home)
 155 Beaver Street
 Milford, MA 01757 USA
 [email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Wed, 25 Feb 2009 21:19:06 +0000

> poor / null security due to bad operational practices.

hardly surprising, like you say.  and self correcting.

---

From: Thierry Moreau <[email-masked]>
Date: Wed, 25 Feb 2009 19:43:01 -0500

> poor / null security due to bad operational practices.

I guess the main characteristic of DNSSEC in this respect is that a 
relying party has little room for tighter validation rules aiming at 
effective end-to-end integrity / authentication that are possible, at 
least in theory, with other public key schemes. (Obviously, tighter PKI 
/ TLS validation rules impede ubiquitous interoperability.)

Namely, the bad operational practice of registrars and server system 
operators are not made non-compliant by specific "MUST"s in DNSSEC RFCs. 
DNSSEC has not been designed as a PKI.

Regards,

-- 

- Thierry Moreau

---

From: Mark Andrews <[email-masked]>
Date: Thu, 26 Feb 2009 12:28:34 +1100

> DNSSEC has not been designed as a PKI.

	DNSSEC really doesn't change the level of care a parent
	zone operator should be taking.  All changes should be being
	held to the highest levels of accountability as it is.  This
	was realised well before DNSSEC was thought about.

	If this not already written into the relevent contracts
	then it should be done.

	Mark
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Thierry Moreau <[email-masked]>
Date: Thu, 26 Feb 2009 04:53:35 -0500

> 	If this not already written into the relevent contracts

That's a sure way of bringing "layer 9" (and above), i.e. inextricable 
liability and organizational issues, into DNSSEC deployment critical path.

So far, ICANN/IANA did a great job at demonstrating operational ability 
and advocating its potential role as the DNS root zone signatory. In the 
discussions around this initiative, I noticed David Conrad consistently 
arguing that DNSSEC provides integrity protection ONLY from the 
authoritative zone file to the validating resolver, as a mere 
technological control mechanism. Maybe this idea has been instrumental 
in allowing ICANN/IANA actions on the DNSSEC front.

- Thierry Moreau