Subject: RE: How do we get the whole world to upgrade to DNSSEC capable resolvers?

From: Jesper G. Høy <[email-masked]>
Date: Sun, 10 Aug 2008 20:02:06 +0200

Danny Mayer wrote:
> > I agree - and I am not arguing against DNSSEC as a whole.
> > As I started out saying - "There may be other good reasons to push
> DNSSEC" - distributing public keys certainly may be one of those.
> > However, this was in regards to the Kaminsky bug, which is all about
> carrying IP addresses (A/AAAA RRSets in response Additional section).
> > So to clarify: DNSSEC doesn't make much difference when the bad guy
> > is on-the-wire - for IP address records.
> That's not true either way. DNSSEC will protect you from the bad guy on
> the wire.

My point was that it doesn't matter that you get the correct IP address
(signed by DNSSEC) if the bad buy is on the wire.
In that scenario he can just spoof that IP address and replace web-sites
etc. with his own data.
Only SSL can protect you here.

> But the A/AAAA records in the additional section is not the
> only part that needs protection. The authority section also needs
> protection since they contain the authorative nameserver names. By
> diverting further queries to their own nameservers they no longer need
> a cachepoisoning attack.

Right - but NS-records point to host names which point to A/AAAA records
which point to IP addresses.
Comes back to the same thing - if the bad guy is on the wire, you are still
in trouble...
DNSSEC or not.

> > Without having thought this through, I think resolvers could probably
> > ignore anything else (non A/AAAA RRSets) in the response Additional
> section - limiting the Kaminsky bug to such records. But that's a
> different thread... 
> And what about the authority section?

Se above.

> > Carrying IP addresses is still by far the biggest use of DNS.
> No it isn't. MX records are almost as big. And then there are SRV
> records.

OK - but MX-records point to host names which point to A/AAAA records which
point to IP addresses...
If the bad guy is on the wire, he can intercept and replace your SMTP
traffic anyway. 
DNSSEC or not.

SRV-records also point to host names which...

> > And I am just not convinced that it is a good idea to apply DNSSEC's
> complexity to this most fundamental part of our Internet.
> > I believe a simpler solution stands a much better chance of actually
> being implemented and used, and therefore is more secure overall.
> > Especially if such a solution does not require any end-user action
> other than patching.
> Go look at Dan Kaminsky's slides for the fuller picture

I see nothing in the slides that suggest that DNSSEC is the only true
solution or that rule out other solutions.
On the contrary it seems to me that Dan Kaminsky himself is suggesting other
solutions in his latest blog entry on the matter...

Sincerely,
Jesper

--
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: Mark Andrews <[email-masked]>
Date: Mon, 11 Aug 2008 11:18:41 +1000

> SRV-records also point to host names which...

	DNS security is required for SMTP security to work.  How
	else fo you securely workout who you are supposed to be
	communicating with.

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

---

From: David Conrad <[email-masked]>
Date: Mon, 11 Aug 2008 13:04:07 -0700

Jesper,

> In that scenario he can just spoof that IP address and replace web- 
> sites etc. with his own data.

Ignoring for the moment the fact that 134 million (or even 4 billion)  
packets isn't that much anymore (and will be less and less over time),  
the DNS lookup 'wire' is logically distinct from the content 'wire'.   
The ability to "intercept spoof" a DNS response can occur anywhere on  
the DNS lookup 'wire', not only on the content producer/consumer's  
local LAN.  By not protecting the packet content, you open yourself up  
to a distinct set of attackers beyond the local wire.

> Only SSL can protect you here.

As Dan Kaminsky points out: "SSL certs themselves are dependent on the  
DNS".

> solution or that rule out other solutions.

Indeed.  DNSSEC may not be the 'only true solution' and there may be  
other solutions.  The vast majority of folks who have burned brain  
cells and stomach lining on DNSSEC could be complete idiots and an  
obvious, complete, lightweight, and architecturally clean solution  
could be staring all of us in the face.  I look forward to reading  
your draft on the topic  (note that I wouldn't consider a solution  
that ignores the risk on the DNS lookup 'wire' complete, but maybe  
that's just me).

I would however note that partly as a result of this latest incident  
of having it pointed out that it is better to protect data content  
than the data channel, the amount of DNS infrastructure out there  
capable of supporting DNSSEC (and the political will to see it  
deployed) has likely taken a very significant jump...

Regards,
-drc

---

From: Michael StJohns <[email-masked]>
Date: Mon, 11 Aug 2008 16:03:27 -0400

At 09:18 PM 8/10/2008, Mark Andrews wrote:

>        DNS security is required for SMTP security to work. 

Absurd claim.

>How

Um.. maybe with SSL?   Check the offered certificate matches some criteria to relate it to the name and that it chains back to someplace you trust.

I'm sure there are all sorts of arguments you could make on how this isn't sufficient - but DNSSEC only at MOST gives me a validatable mapping between a domain name and the ultimate IP address - it doesn't protect against post-resolution attacks of various flavors, so I could argue DNSSEC isn't sufficient.

SSL/TLS has the nice properties that I can deploy it per server (e.g. I can get incremental benefit), that I can do off-tree validations, and that a hell of a lot of servers already implement it.  DNSSEC can't be deployed per server (requires the zone to be signed even if mostly opted out), can't do off-tree validations (DLV is a hack - I might split a hair and call it off-tree, but it really is more of a trust anchor registry than anything else), and few SMTP servers (any?) implement DNSSEC resolution/validation.

---

From: Jesper G. Høy <[email-masked]>
Date: Mon, 11 Aug 2008 23:47:44 +0200

> to a distinct set of attackers beyond the local wire.

Thank you - my point exactly!
4 billion packets may not be enough - we need a longer transaction ID.
We have now come full circle to my initial post which was:

<quote>
The core problem with the Kaminsky bug, and other cache poisoning scenarios,
is the short 16 bit transaction ID.
So why not simply expand this ID to a secure length?
And not just ~16 bits (random ports) or 2+ bits (x020) - but really secure
length like 128 bits.

This seems a lot easier than getting DNSSEC in place, signing the root,
getting EVERYBODY to sign their zones, repeat for rollover, etc., etc.

Some will probably argue that this doesn't help against on-the-wire-attacks.
But if the bad buy is one-the-wire, then he can replace any data at will
anyway. DNSSEC is no help here.
Of course we already have SSL to solve that problem.

So why not keep DNS simple?

Am I oversimplifying matters?
</quote>

> could be staring all of us in the face.

That’s not fair!
I most certainly never suggested anything like that. 
I have the deepest respect for the people behind DNSSEC and all the work
that has gone into this.

But DNSSEC was not invented to fix the Kaminsky bug (the topic of this
thread).
In fact DNSSEC was invented more than 10 years earlier.

I do think it is fair to ask that other possibilities at least be considered
before applying something as complex as DNSSEC to this fairly simple problem
(short transaction ID).

Sincerely,
Jesper

---

From: David Conrad <[email-masked]>
Date: Mon, 11 Aug 2008 15:48:34 -0700

Jesper,

> 4 billion packets may not be enough - we need a longer transaction ID.

Or, we could remove the vulnerability by protecting the data, not the  
transport.

> is the short 16 bit transaction ID.

No.  The core problem with the Kaminsky bug is the fact that DNS data  
is unprotected during transport.  Making the transaction ID bigger  
reduces the chance of an blind insertion spoof attack, but does  
nothing for an interception spoof attack where the attacker is in the  
DNS data path.  Your XTID proposal is one of a class that treats the  
symptoms, not the underlying disease.  DNSSEC is one of a class that  
treats the disease.  In a DNSSEC-enabled world, it wouldn't matter  
where you got the response from or what zombie-laden networks the  
response traversed, you would be able to validate the response hadn't  
been tampered with.

That isn't to say that I don't think XTID et al shouldn't be  
considered and even implemented if they improve the status quo, but it  
solves a subset of the problems DNSSEC solves and as such, one has to  
consider whether it is superfluous, particularly as XTID (appears to)  
require a redeployment of both authoritative and caching servers, just  
like DNSSEC (and if you're going to redeploy, you're probably going to  
be redeploying something that is DNSSEC-capable).

> But DNSSEC was not invented to fix the Kaminsky bug (the topic of this

Actually, it was.  Not the Kaminsky bug specifically of course, but  
the entire class of bugs that revolve around modifying DNS data in  
transit.

> before applying something as complex as DNSSEC to this fairly simple  

First, I am unaware of anyone even suggesting that other possibilities  
not be considered.  On the contrary, I seem to recall pretty much  
everyone clamoring for an alternative that provides the same level of  
protection as DNSSEC albeit with less  
{development,operational,infrastructure} cost.

Second, the problem isn't that the transaction ID is too short.  The  
short transaction ID exacerbates the problem by allowing remote  
insertion spoofing particularly when additional section processing  
comes into play.  The real problem is that the DNS protocol was  
developed during a time when "be liberal in what you accept" was a  
good idea and when nobody would intentionally muck up network data for  
illicit gain.  Times have changed.

Regards,
-drc

---

From: Mark Andrews <[email-masked]>
Date: Tue, 12 Aug 2008 11:04:39 +1000

> In fact DNSSEC was invented more than 10 years earlier.

	Incorrect.  It was invented to protect against several
	classes of attack of which Kaminsky is just one example.

	It was assumed back when DNSSEC was originally being developed
	that someone would work out a good method for injecting
	spoofed responses.  DNSSEC was designed to deal with that
	threat.  We just hoped we would have more deployment before
	the threat became a reality.

	Mark

---

From: Tony Finch <[email-masked]>
Date: Tue, 12 Aug 2008 14:59:53 +0100

On Mon, 11 Aug 2008, Michael StJohns wrote:
>
> SSL/TLS has the nice properties that I can deploy it per server (e.g. I
> can get incremental benefit), that I can do off-tree validations, and
> that a hell of a lot of servers already implement it.

It has the problem that a large proportion of MXs that offer TLS have the
wrong certificate, so you can't easily turn on certificate verification
for your outgoing email. There's essentially no requirement for
certificate verification in the specification, nor is it clear exactly
which domain you are supposed to compare against any certificate.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
NORTH UTSIRE SOUTH UTSIRE: SOUTHEASTERLY 4, BACKING NORTHEASTERLY 5 TO 7 FOR A
TIME. MODERATE OR ROUGH. RAIN OR SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 13 Aug 2008 01:03:55 +1000

> which domain you are supposed to compare against any certificate.

	The certificate should match the host name in the reply to
	the HELO message which should in turn also match EXCHANGE
	in the MX record in the general case.

	Checking the later part was specified in RFC 821 Section
	3.5. OPENING AND CLOSING.

      "At the time the transmission channel is opened there is an
      exchange to ensure that the hosts are communicating with the
      hosts they think they are."

	The former is a logical extension.

	Mark

---

From: Edward Lewis <[email-masked]>
Date: Tue, 12 Aug 2008 09:40:07 -0700

>	DNS security is required for SMTP security to work.

That is why the SIKED (Secure Internet KEy Distribution) BoF failed, 53rd IETF.

If SMTP security works because DNS security works, then a DNS 
security failure means SMTP security fails too.  A house of cards. 
This is what is feared.

(see also http://www.potaroo.net/ietf/idref/draft-lewis-siked-dnsargs/)

Thanks to Geoff Huston for maintaining that repository.  Although I'd 
call it "Pandora's Box" because of all of the bad ideas documented in 
there that never mad it to RFC. ;)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Never confuse activity with progress.  Activity pays more.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 13 Aug 2008 08:43:09 +1000

> security failure means SMTP security fails too.  A house of cards. 

Lots of things really depend on DNS working as intended.  I'm just
sick and tired of all those who think that hop by hop security is
enough for the DNS.  It isn't and it never has been.

It is time to put the little bit of effort into creating DNSKEY's
and signing your zones.  It really isn't a big operational effort
that everyone keeps saying it is without actually attempting to
do it.

---

From: Dean Anderson <[email-masked]>
Date: Tue, 12 Aug 2008 15:45:57 -0400 (EDT)

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

> As Dan Kaminsky points out: "SSL certs themselves are dependent on the  

Kaminsky is wrong. SSL uses DNS to obtain an IP address to connect to a
server, and then expects the server to produce a certificate, which the
client verifies. Spoofing DNS does not enable the attacker to obtain the
private key to the valid certificate.  The DNS domain information placed
in a certificate merely allows the client to determine before
verification if it got the certificate it asked for. However the wrong
or fake certificate won't verify unless there is a fault in the
Certification Authority (this happened with MS some years ago). But a
spoofed DNS name going to a wrong server results in a failure to verify
the certificate. So SSL is NOT "dependent on DNS".

Of course, if spoofed DNS sends the SSL connection to the wrong server,
a DOS attack still results since one didn't get to the correct server. 
In that sense, everything a user does is dependent on DNS. 

But it is not the case that your bank information can be stolen by this
DNS attack, as Kaminsky seems to have told the mainstream press.

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000

---

From: [email-masked]
Date: Wed, 13 Aug 2008 14:54:39 +0100

> DNS attack, as Kaminsky seems to have told the mainstream press.

Unless your bank used a weak cert generated on a Debian system...

Ray

---

From: Joe Abley <[email-masked]>
Date: Wed, 13 Aug 2008 11:52:14 -0400

> Unless your bank used a weak cert generated on a Debian system...

Or unless the authentication performed by the CA is easily subverted,  
leading them to sell a certificate with a to-be-spoofed common name to  
a third party.

(Requests sent on faxed letterheads; e-mail confirmations exchanged  
with the listed domain contacts; etc.)

SSL is only as good as (a) CA signing policies and (b) users  
reliability in not ignoring certificate warnings. In practice (in my  
opinion) this makes SSL protection for services quite weak, in general.

Joe

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 13 Aug 2008 09:17:54 -0700

At Tue, 12 Aug 2008 15:45:57 -0400 (EDT),
> the certificate. So SSL is NOT "dependent on DNS".

Based on my brief skim of Kaminsky's presentation, I think his
argument is that because CAs often use e-mail answerback as a
certificate validation mechanism, a compromise of DNS can be used to
obtain a fake SSL/TLS certificate. Of course, there's nothing stopping
CAs from requesting more validation (in fact, I believe that's what EV
certificates already do), in which case there would not be a DNS-based
threat.

That said, it's not clear to me that the situation is significantly
better with DNSSEC.  Both certificates and signed zone signing keys
are attestations that a given public key corresponds to the owner of a
given domain name/group of names. The non-cryptographic question is
how the signer of the credential determines whether a given candidate
public key is correct. But this question is more or less the same for
DNS servers and CAs, because in both cases there is generally not a
cryptographic credential, but just an authoritative contact point,
which often reduces to an email address.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 13 Aug 2008 09:23:04 -0700

> Unless your bank used a weak cert generated on a Debian system...

... And you haven't installed one of the weak key blacklists.

-Ekr

---

From: [email-masked]
Date: Wed, 13 Aug 2008 16:22:20 +0000

> opinion) this makes SSL protection for services quite weak, in general.

do i have the dance steps right?

	trap a query/response pair

	forge the reply - stuff the additional section w/ self-executing code to
		dump a self-signed cert to a "mimic" bank site into the local 
		browser cache

	stuff the DNS cache with a "mismatched" name -> address pair, where the
		address is to the "mimic" site.

	the browser is none the wiser, SSL is happy.

looks like the  walz of deception to me.

--bill

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 13 Aug 2008 09:39:36 -0700

On Wed, Aug 13, 2008 at 11:52:14AM -0400, Joe Abley wrote:
> leading them to sell a certificate with a to-be-spoofed common name to a 
> third party.

Or even Kaminsky-subverting http://www.bank.com/ to point to a host
which produces a redirect to https://www.bankfoo.com/, which is under
the attacker's full control.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins

---

From: Jim Fenton <[email-masked]>
Date: Wed, 13 Aug 2008 10:07:13 -0700

> ... And you haven't installed one of the weak key blacklists.

The issue here isn't one of us, it's the typical banking customer.  Have 
they installed one of the weak key blacklists?  I think not.

-Jim

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 13 Aug 2008 10:22:24 -0700

> 		dump a self-signed cert to a "mimic" bank site into the local 

This is the step I got lost at. You're assuming that there is some bug in the
browser that will allow a malicious DNS response to inject information
into the browser certificate cache? It's certainly possible that that's
true, but if so, then you've most likely got a generic remote exploit
for the browser, so why bother with any fanciness about trapping queries
and responses, SSL, etc get the user to dereference *your* domain name (remember
that the premise here is that the attacker can get the user to dereference
domain names of his choice) stuff the attack payload in the response
and subvert the user's computer directly?

> looks like the  walz of deception to me.

Again, why other with this stuff? At this point you control the user's computer
and can simply passively tap all his communications.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 13 Aug 2008 10:18:16 -0700

At Wed, 13 Aug 2008 11:52:14 -0400,
> opinion) this makes SSL protection for services quite weak, in general.

As I should have stated earlier, I'm not offering a general defense of
SSL certificates or PKI practices in general. However, exactly these
same issues apply to decisions made about DNS domain transfers/
information modification, key signing, etc.

The problem here is not PKI or DNSSEC but that we have no good
mechanisms in the generic case for determining whether a given
individual is authorized to control a given domain. This makes any
cryptographic authentication of domain name ownership problematic.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 13 Aug 2008 10:31:40 -0700

At Wed, 13 Aug 2008 10:07:13 -0700,
> they installed one of the weak key blacklists?  I think not.

Yes, I agree that it would be nice if the browsers shipped out of the
box with blacklisting. 

Of course, that depends on the users running the latest version of
the browser (see [FDOM08]), but if they're not then presumably
they're open to all sorts of non-TLS remote exploits, so why is this
one special?

-Ekr

[FDOM08] S. Frei, T. Dübendorfer, G. Ollmann, M. May, "Understanding the Web
browser threat: Examination of vulnerable online Web browser populations
and the "insecurity iceberg"", Defcon 2008, August 2008.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Aug 2008 10:19:00 -0700

> DNS attack, as Kaminsky seems to have told the mainstream press.

You are right that SSL would protect the user.   However, the Kaminsky  
vulnerability provides an opportunity for a downgrade attack.   If the  
attacker presents a self-signed cert, some percentage of users will  
accept it, thus accepting the security downgrade.   For those users,  
the fact that SSL would protect them doesn't help.   If we can stop  
the Kaminsky attack, we can prevent this particular downgrade attack.

Security is not just about secure protocols.   You have to take into  
account what the user will do as well.   A thousand-dollar safe is no  
use you don't lock it.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Aug 2008 10:27:14 -0700

Eric, one other thing to bear in mind with banks is that the typical  
user goes to http://www.bank.com and types in their password in the  
login form presented to them.   All I (the attacker) have to do to get  
their password is to arrange for the form with which they are  
presented to submit the password to an http:// URL instead of the  
bank's HTTPS:// URL.   SSL doesn't happen, so the user is not told  
about the invalid cert.   And chances are they've disabled the  
"insecure form" warning, because it pops up too often in cases where  
it doesn't matter.

The attacker can then tunnel the rest of the session, presenting the  
user with the illusion that they have in fact completed a transaction  
with the bank, leaving them no wiser to the fact that their login  
information has been compromised.

This will work even if the bank has a policy of presenting password  
forms only on SSL pages, because the average user won't know this, and  
thus won't be suspicious if they are offered a login on a non-https://  
page.

So the dance that's involved in phishing the user is really a lot  
simpler than you think, and the value of subverting the DNS is thus a  
lot higher.

---

From: Duane at e164 dot org <[email-masked]>
Date: Thu, 14 Aug 2008 03:28:00 +1000

> Unless your bank used a weak cert generated on a Debian system...

US banks are notorious for not using https URIs for the initial form
where customers log in to web banking, someone was doing up a name and
shame list on banks a while back over this.

-- 

Best regards,
 Duane

---

From: Paul Vixie <[email-masked]>
Date: Wed, 13 Aug 2008 17:35:01 +0000

> the attacker's full control.

no real reason to s/bank/bankfoo/ in that example.  once you've got the A RR
for www.bank.com you can just not redirect folks to https:.  (their bookmark
is likely to be for the http: site, as will their search engine exit.)  or if
the attacker wants to get CRAZY they can redirect to https: quite safely since
the majority of endusers will just click "OK" on the resulting X.509 warning,
without reading it or understanding it.

kaminsky's plan to get a key issued by polluting the caching server of a CA so
that one can successfully emulate the desired common-name attribute is harder
work than needs doing, and so, i predict the criminals will take an easier way.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

---

From: David Conrad <[email-masked]>
Date: Wed, 13 Aug 2008 10:57:22 -0700

On Aug 13, 2008, at 9:17 AM, Eric Rescorla wrote:
>> Kaminsky is wrong.
> obtain a fake SSL/TLS certificate.

That is (as I understand) part of it.

> Of course, there's nothing stopping

Right.  And if the CA uses VOIP that does a DNS lookup, or if the  
databases the CA uses are reached via DNS, or if the CA uses software  
that does self-updates after looking up the 'phone home' server via  
DNS, or ....

I believe what Dan was pointing out is the DNS is an underlying  
infrastructure which all sorts of other infrastructure relies upon and  
if you can crack the DNS infrastructure, lots of other stuff becomes  
much more "interesting" (in the Ebola virus sense of 'interesting'),  
sometimes in ways that aren't necessarily obvious.

Regards,
-drc

---

From: Alex Bligh <[email-masked]>
Date: Wed, 13 Aug 2008 19:09:52 +0100

--On 13 August 2008 17:35:01 +0000 Paul Vixie <[email-masked]> wrote:

> no real reason to s/bank/bankfoo/ in that example.  once you've got the A
> RR for www.bank.com you can just not redirect folks to https:.

Perhaps there is no real reason but all 4 of the online banking services
I use do this.

Alex

---

From: Mark Andrews <[email-masked]>
Date: Thu, 14 Aug 2008 10:43:46 +1000

> cryptographic authentication of domain name ownership problematic.

	Most zones are created when they are bought.  The buyer
	specifies the NS, DS and glue records as part of that
	transaction.  The credentials for future transactions are
	established as part of that initial transaction.

	Now when zones are sold there are issues but those issues
	exist independent of whether DNSSEC is in use or not.

	If you are authorised to update the delegation information
	in the parent then you should be authorised to change the
	DS records in the parent as they are just part of the
	delegation.  Changes to NS, A, AAAA and DS records as part
	of the delegation are equally dangerous as each other.

	There is no need to make the parent / child trust relationship
	more complicated with DNSSEC than it is without DNSSEC.

	Mark

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 13 Aug 2008 18:16:25 -0700

At Thu, 14 Aug 2008 10:43:46 +1000,
> 	more complicated with DNSSEC than it is without DNSSEC.

Yes, I agree with that. But in many of these cases, the credentials
are "here's the email address to contact the technical contact with".
This is of course just as problematic as e-mail answerback for 
certificate authorites. 

And to the extent to which the registrars/registries have a
DNS-independent way of validating the domain owners, the CAs 
(who in at least some cases are the same people!) could
presumably leverage that to determine whether to issue
the certs.

-Ekr

---

From: Mark Andrews <[email-masked]>
Date: Thu, 14 Aug 2008 14:29:33 +1000

> This is of course just as problematic as e-mail answerback for 

	And how does this change with DNSSEC?  DNSSEC doesn't
	magically make this any more or less important / difficult.

	This is NOT a DNSSEC issue.  It is a delegation management
	issue and DNSSEC does NOT change the level of care required
	when managing a delegation.  All DNSSEC changes is whether
	a DS record is recorded at the delegation or not.

	Labeling this a DNSSEC deployment issue is doing DNSSEC a
	dis-service.

	What would help would be for ICANN to list which registrars
	support DS and/or AAAA records as part of normal operations
	and which ones don't.  By normal operations I mean that you
	don't have to send special email to get the records added.

	At the moment it's hard to find a registrar which supports
	AAAA and/or DS records.

---

From: Duane at e164 dot org <[email-masked]>
Date: Thu, 14 Aug 2008 15:35:50 +1000

> 	support DS and/or AAAA records as part of normal operations

Can't help you with DS records, but as for AAAA records:

http://www.sixxs.net/faq/dns/?faq=ipv6glue

-- 

Best regards,
 Duane

---

From: Brian Dickson <[email-masked]>
Date: Thu, 14 Aug 2008 17:01:20 -0400

Dean Anderson wrote:
> The assertion of personal attacks is a lie and a deception of the 
> working group.
>
>
>   

[ Personal attack on Andrew Sullivan elided for brevity.  Any future 
claim by Mr. Anderson in the regard, should be taken as patently false. ]

I can personally attest to both the integrity of Andrew Sullivan, and to 
the fact that everything said about him was false.

I can't recall - is it libel or slander, when someone maligns someone 
else in writing in a malicious manner?

> This abuse has to stop.

Yes, you are right on this point.

Please stop abusing people on IETF mailing lists.

Brian

P.S. NO ONE ELSE FEED THE TROLL, PLEASE.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 14 Aug 2008 23:56:36 -0400

Dear colleagues,

Dean Anderson has brought an error to my attention:

On Thu, Aug 14, 2008 at 04:31:52PM -0400, Dean Anderson wrote:
> The moderators note is false, and deceives the Working Group. I am a
> subscriber, and the post was not over 20K.

I wish to apologise to the members of the Working Group, and to Mr
Anderson, for my error.  Mr Anderson, as many of you may be aware, had
his posting privileges revoked [1].  Because of that, Mr Anderson's
post was caught in the same trap as non-subscribers' mail.  When I
approved it, I used an incorrect mechanism.  That mechanism added the
"Moderator's note" text you see quoted by Mr Anderson.

The inserted text is therefore my fault, and I wish to correct the
error.  Mr Anderson's post was not moderated because of being posted
by a non-subscriber, or because of its size.  It was moderated
because, while Mr Anderson is a subscriber to the mailing list, he is
not automatically allowed to post.  I should have used a different
mechanism to approve his post (one that would not have added only that
text).

I regret the error.  Olafur and I are currently reviewing mailing list
administration, but this particular mistake is entirely mine.

Best regards,

Andrew

[1] http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg00149.html

-- 
Andrew Sullivan
[email-masked]
+1 503 667 4564 x104
http://www.commandprompt.com/

---

From: Dean Anderson <[email-masked]>
Date: Fri, 15 Aug 2008 00:01:42 -0400 (EDT)

[ Note: Post was moderated. ] 

> the fact that everything said about him was false.

What personal knowledge do you have of the facts?  If you have no
personal knowledge of the facts, you can't make any true statement as to
the facts.  If you have direct personal knowledge and were involved
personally, please let me know.

> else in writing in a malicious manner?

Its libel.  False reports of misconduct are libel.

What I said was true, and what Andrew said about me was false.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Thu, 14 Aug 2008 16:31:52 -0400 (EDT)

The Chairs have chosen to censor messages which are relevant to WG
business, but that are not exclusively technical.  The type of messages
they have said they will censor includes messages about RFC3979
compliance, messages about financial considerations for drafts, and
messages concerning the integrity of the IETF process as described by
RFC2026 section 6.5.1. In practice, they have blocked messages that
merely oppose the unsubstantiated assertions of the BIND Cartel (ISC,
Nomimum, UltraDNS, and Centergate Research)

See http://www.av8.net/IETF-watch/DNSEXT/Management.html

In 2000, messages from Dr. Bernstein regarding DNS cache poisoning 
attacks was also censored.  WG Chair Gudmundsson was involved in the 
censorship of those messages.

WG Chair Olafur Gudmundsson has demanded that I "agree not to engage in
personal attacks". Since I (Anderson) have never engaged in personal
attacks, this demand is based on an implied fiction. It is known as a
'loaded question' fallacy.  His demand is the same as the fallacious
question 'have you stopped beating your wife?" As in the wife-beating
fallacy, if I answer "no", then it seems as if I intend to continue
making personal attacks, implying misconduct. If I answer "yes", it
seems as if I concede to some past misconduct, also implying misconduct.  
WG Chair Gudmundsson was previously involved in the controversial
AXFR-clarify draft promoted by the BIND Cartel and was involved in the
deception of the DNSEXT WG over 1999-2002 through (at least) the
censorship of Dr. Dan Bernstein, who opposed the draft.

WG Chair Sullivan has specifically asserted that only technical messages
can be posted to DNSEXT, denying that RFC3979 compliance, financial
considerations, or discussion of the integrity of the process were
appropriate subject matter. Recently appointed, WG Chair Andrew Sullivan
has no relevant DNS experience, nor any long IETF experience. Sullivan
has been a system administrator at Affilias for a few years, and was a
protoge of Joe Abley, former ISC architech of DNS Anycast.  Sullivan had
also recently taken over the dubious IN-ADDR Required draft on DNSOP,
renamed "Considerations for the use of DNS Reverse Mapping", but
containing the same discredited claims as the IN-ADDR Required draft.

This abuse has to stop.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Fri, 15 Aug 2008 10:45:18 -0400 (EDT)

Your apology on the moderation note is accepted.

		--Dean