Subject: RE: dns-0x20.txt

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Sun, 2 Mar 2008 14:00:22 -0500

Hi Wouter, 

> -----Original Message-----
> From: Wouter Wijngaards [mailto:[email-masked]] 
> Sent: Thursday, February 28, 2008 4:09 AM
> To: Eastlake III Donald-LDE008
> Cc: Michael Graff; [email-masked]
> Subject: Re: dns-0x20.txt
> 
> Eastlake III Donald-LDE008 wrote:
> | Hi,
> |
> | On using an EDNS0 option, please see my draft at
> | 
>
http://www.ietf.org/internet-drafts/draft-eastlake-dnsext-cookies-03.txt
> | .
> | For simplicity is proposes a fixed size but it would be 
> trivial to make
> | it variable.
> 
> I like the idea of using an EDNS0 option to contain random data.
> Perhaps without a complicated hashing scheme (as you have), 
> but simpler
> (once you know the server speaks that option; you are guarded by the
> server copying the option back to you; of course the 
> occasional timeout
> or reboot presents small windows of downgrade attack. State could be
> stored on disk though.). Anyway, your proposal is nice.

Thanks.

Actually, it depends on what attacks you are considering. As hashing
schemes go, what I suggest is pretty trivial and if the computation load
were too heavy, you could go to some even simpler and weaker hash
function, like maybe MD4. (It recommends HMAC-SHA1 because I think
anything weaker as the default recommendation would run into a lot of
flak from people in the Security Area. But I don't really think, for
this application, it needs to be that strong.)

Anyway, as I say, a brief window where you can sneak by the protection
isn't a downgrade attack. A downgrade attack is an attack which, if it
succeeds, puts the participants in a sustained degraded mode of
operation, such as an attack which persuades them to use a weaker key or
weaker algorithm such that the protection is weakened permanently, or at
least until the next reset.

> Also the dns-0x20 draft breaks binary labels. Badly.
> Binary data is garbled by the process. If this is deployed, binary
> labels are no longer an option later on (as some upstream 
> full resolver
> may break the uppercase bit in the binary data).
> 
> DNSSEC, as it gets deployed, makes spoof protection 
> mechanisms obsolete.
> And DNSSEC is already deployed on some TLDs. Configuring keys 
> is a much
> more reliable way to prevent spoofing for them.

TSIG is a complete and superior replacement for DNS Cookies but I assume
your are talking about the data origin authentication (and maybe
authenticated denial of existence) aspects of DNSSEC.

Those aspects of DNSSEC don't help denial of service attacks on servers.
In fact, DNSSEC makes those attacks worse, at least for a recursive
server, because of the computational load of the cryptographic
operations it may have to perform in trying to produce an answer.

And those aspects of DNSSEC don't help amplification attacks. In fact,
DNSSEC makes those attacks via DNS servers worse because the signatures
over the RRs in the result make the answer bigger.

I think you would want DNS Cookies even if you had 100% deployment of
DNSSEC. In fact, I think universal deployment of DNSSEC would make DNS
Cookies more desirable, not less.

> Best regards,
> ~   Wouter

Thanks,
Donald

--
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: Edward Lewis <[email-masked]>
Date: Fri, 7 Mar 2008 13:59:31 -0500

At 17:57 +0000 2/29/08, Paul Vixie wrote:

>i agree.  however, we have in the past insisted that all authority servers for
>a zone support the same level of dnssec.  could we not also insist that all
>members of anycast clusters support the same level of edns?

I don't think that any protocol defining document can credibly 
"insist" any operational practice, nor define a protocol based on the 
assumption that the operators comply with the "insisted" behavior.

It would be ideal if all servers answering to a single IP address 
were 100% compatible.  But there are times in operations when it 
isn't (/may not be) practical to stick to that recommendation.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Mail archives, backups.  Sometimes I think the true beneficiaries of
standards work are the suppliers of disk drives.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 11 Mar 2008 23:12:44 -0400

An off-hand comment, this doesn't do a whole lot for the reverse map. 
(Unless I am missing something.)  It doesn't hurt though.  Probably a 
mention in the security section on that topic.

At 17:43 +0000 2/26/08, Paul Vixie wrote:
>i think i've missed the cutoff for new -00 drafts, but, this is topical and
>i'd like to discuss it anyway, even if it can't be on the philly agenda.
>
>                                     Abstract
>
>       The small (16-bit) size of the DNS transaction ID has made it a
>       frequent target for forgery, with the unhappy result of many cache
>       pollution events throughout Internet history.  Even with perfectly
>       and unpredictably random transaction ID's, random and birthday
>       attacks are still theoretically feasible.  This document describes a
>       method by which an initiator can improve transaction identity using
>       the 0x20 bit in DNS labels.  The method described here has already
>       been implemented, and is running in production.
>
>for more, go to <http://sa.vix.com/~vixie/dns-0x20.txt>.
>
>
>--

Never confuse activity with progress.  Activity pays more.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 12 Mar 2008 00:04:01 -0400

You get 7 (ip6.arpa) or 10 (in-addr.arpa) bits
which is more than irs.gov (6) gets :-)

         Olafur

At 23:12 11/03/2008, Edward Lewis wrote:
>An off-hand comment, this doesn't do a whole lot for the reverse 
>map. (Unless I am missing something.)  It doesn't hurt 
>though.  Probably a mention in the security section on that topic.
>
>

---

From: "Blacka, David" <[email-masked]>
Date: Wed, 12 Mar 2008 07:15:00 -0400

> which is more than irs.gov (6) gets :-)

I count 6 bits in ip6.arpa, unless you've figured out how to  
capitalize '6' ;-)

>> map. (Unless I am missing something.)  It doesn't hurt though.   
>> Probably a mention in the security section on that topic.
>>

--
David Blacka                          <[email-masked]>
Sr. Engineer    VeriSign Infrastructure Product Engineering

---

From: Mark Andrews <[email-masked]>
Date: Wed, 12 Mar 2008 22:45:57 +1100

> mention in the security section on that topic.

	Which reverse map?  It helps in ip6.arpa.  Just another reason
	to go to IPv6.  :-)
 
	Mark
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Wed, 12 Mar 2008 23:03:57 +1100

> 
> --Apple-Mail-2--619965873
> Content-Type: text/plain;
> 	charset=US-ASCII;
> 	format=flowed;
> 	delsp=yes
> Content-Transfer-Encoding: 7bit
> 
> 

	But you will almost certainly get some extra bits in the
	nibbles.
 
	2001:df8:0:112:216:6fff:fe46:b75d

	6+9 for my address here.

	Assuming a uniform distribution you would get 6+19 bits.

	Mark

> --Apple-Mail-2--619965873
> Content-Disposition: attachment;
> 	filename=smime.p7s
> Content-Type: application/pkcs7-signature;
> 	name=smime.p7s
> Content-Transfer-Encoding: base64
> 
> MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILiDCCA6Yw
> ggMPoAMCAQICEHWNgosXAgaqes2nmr0jsCgwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYTAlVT
> MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMiBQdWJsaWMgUHJpbWFy
> eSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykgMTk5OCBWZXJpU2ln
> biwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz
> dCBOZXR3b3JrMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyNDIzNTk1OVowga0xFzAVBgNVBAoTDlZl
> cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BV
> c2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWty
> IChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTCBnzANBgkqhkiG
> 9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z56fy5WXixVcBTWLHPbxY7
> wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiKQNKaiRMpqbbV26d+4ec3
> JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCBrTARBglghkgBhvhCAQEE
> BAMCAQYwDwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgBhvhF
> AQcXAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDQGA1UdHwQt
> MCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzIuY3JsMA0GCSqGSIb3DQEB
> BQUAA4GBAFJetpXbb3ymfgX2VIU72RqKRVlffMJl7vlA3lRux5ASgCQ8QKNj7IUf9R4bico9juNL
> Lt+cG+6O51S5VpP+29HERPjLnECdkqzFzgTxEUbsiLyYyIwhfTeczGu9NKWTjL2cOR3qp5wazfVH
> bSxzE2NqIS5afYd9vEy+8scDwoy2MIIDwDCCAymgAwIBAgIQSsgAA2Nh1BUDFvGGNpu3zTANBgkq
> hkiG9w0BAQUFADCBrTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu
> IFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0dHBz
> Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJjAkBgNVBAMTHVZlcmlTaWduIENsYXNz
> IDIgUGVyc29ubmVsIENBMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyMzIzNTk1OVowgawxFzAVBgNV
> BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYD
> VQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v
> cnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBMIGfMA0G
> CSqGSIb3DQEBAQUAA4GNADCBiQKBgQDAitGHYaLqMANVawg28Jf6GlQ1JB/ofZ3Iw3PT2Eb1kS3Z
> OO2U17Amcyrel1BN/yIcvXAAmAxYKrGkco+lufctfGDjtd/pfU4hIWHV/DtUyaQJnLsi+aK6cGFP
> hkai/QVk7Ao/plh2V7sWc0R88KUNl8BspvFjCCWxBBeVoI3+fwIDAQABo4HfMIHcMCkGA1UdEQQi
> MCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTExODARBglghkgBhvhCAQEEBAMCAQYwDwYD
> VR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAjAqMCgG
> CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDgGA1UdHwQxMC8wLaAroCmG
> J2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNybDANBgkqhkiG9w0BAQUFAAOB
> gQA2GP0zYNYX0wS12FRfUhrlkggo9KJA2sNbjBqGl++uohX+bMTOL8gByjO+8nlYM5eXkkVwWk4o
> Hd33wYhOG4dXAj2TJdl+TnI1iUkXs7l3L20O+aSIJcHOdnNlaQWTd+f9k5YYOE1YbHqd6NKb6NDb
> if1JwnUEA5el1JaB2CNB8DCCBBYwggN/oAMCAQICECsUEtKYtH+GOnwD9TrUy/0wDQYJKoZIhvcN
> AQEEBQAwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz
> dCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3
> dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVt
> cGxveWVlIENBMB4XDTA3MDMyODAwMDAwMFoXDTA4MDMyNzIzNTk1OVowajERMA8GA1UEChMIVkVS
> SVNJR04xEDAOBgNVBAsTB1ZBLUVBU1QxEzARBgNVBAMTClJlY2lwaWVudHMxLjAsBgNVBAMTJWRh
> dmlkYiAoQmxhY2thIERhdmlkLCBWZXJpU2lnbiwgSW5jLikwgZ8wDQYJKoZIhvcNAQEBBQADgY0A
> MIGJAoGBAOdIMJv8eXZfXcOe4nL+d6kvaSZdXCYyXn+0dp8O+C7w6/WlLoR4I2jd8Qa2C9+G8wjf
> LV3BX8HqZ/TQP8TQHP16HxOc46930G+izuJJ+K80R7ANcGC3ccU4sM4KNWGAM9vzdnnkRGrOJdt+
> X4JNmoTLw0lCh7SKUtHJjO/a2C6VAgMBAAGjggF4MIIBdDAJBgNVHRMEAjAAMFkGA1UdHwRSMFAw
> TqBMoEqGSGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL1ZlcmlTaWduSW5jRXhjaGFuZ2VF
> bXBsb3llZXMvTGF0ZXN0Q1JMLmNybDALBgNVHQ8EBAMCBaAwHgYDVR0RBBcwFYETZGF2aWRiQHZl
> cmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYc
> aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJ
> bmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4g
> KGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr
> BgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQBxY9XyK49IilNbH/gnV5wVylpyf5iqU+snpdgvGq1S
> C/ORihQmXlcTppYJbCxgS/Q6utrKkWIFK45pwbWKzIFLt59KqdODnoJYYBFkpVi86ai43AAsJ2GQ
> 7Snqs0DmvzMiFEkXJXNdGV7t69LuI6xCoNTXGJQAE6hq135KCB/JxDGCA3UwggNxAgEBMIHBMIGs
> MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
> azFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNp
> Z24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBD
> QQIQKxQS0pi0f4Y6fAP1OtTL/TAJBgUrDgMCGgUAoIICCTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN
> AQcBMBwGCSqGSIb3DQEJBTEPFw0wODAzMTIxMTE1MDFaMCMGCSqGSIb3DQEJBDEWBBT4XoS0bJh9
> +tV4/LQ1oJjIPl3RmjCB0gYJKwYBBAGCNxAEMYHEMIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwg
> SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1
> YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEl
> MCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQQIQKxQS0pi0f4Y6fAP1OtTL/TCB
> 1AYLKoZIhvcNAQkQAgsxgcSggcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
> ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJt
> cyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJp
> U2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhArFBLSmLR/hjp8A/U61Mv9MA0GCSqGSIb3DQEBAQUA
> BIGALGgeKzet4QhvWcqqYimCBZw1hUzvv/OWPQdBfLw8jD1rsExWbGCftC1ucjcOTvYrYuSIF0O5
> +sjkULbWHmie6ZQyxL9GljljqP/SPASFy8YBWu0MqQE9ygwk6C4b3DMkHtAqKWXT+g4axMKHcIar
> 1Rhe+76Jxz75bEbw9fafcb0AAAAAAAA=
> 
> --Apple-Mail-2--619965873--
> 
> --

---

From: Edward Lewis <[email-masked]>
Date: Wed, 12 Mar 2008 10:38:53 -0400

>	2001:df8:0:112:216:6fff:fe46:b75d

IPv6 reverse map?  I was thinking more about the parts of the reverse 
map that matter, like IPv4 and ENUM.

;)

---

From: David Dagon <[email-masked]>
Date: Wed, 12 Mar 2008 11:11:26 -0400

[ 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. ]

>  mention in the security section on that topic.

Thanks for this note.  My original thinking focused on plain vanilla
IN A poisoning, but attacking the reverse of course has uses for
.rhosts mischief and gaming anti-spam rule engines.  I've been
measuring the average distribution of [A-Za-z] in A, NS, MX, etc., to
see how much entropy DNS-0x20 gains, more or less.  To this, I'll add
the fixed values for reverse.  Thanks for the suggestion.

You're correct, the benefits can be modest--just a few bits in the
worst case.  However, the upside of course is that each [A-Za-z]
character in a label increases the search space for poisoning based on
random guessing.  [Insert here the usual disclaimer about
attackers-doing-better-than-guessing and weak sources of random
numbers, etc.]  If one uses both the ID field and port field, < 2^{32}
(if reserved ports are excluded), each additional 0x20 bit doubles the
search space for the attacker.  (Again, this assumes an equally strong
random source is used for all three sources of entropy.)

The question "When is there enough entropy to be safe?" always has a
subjective answer, and I think we'd all like something much larger
than 2^{40ish}.  Exponential growth is punishing above a threshold and
DNS-0x20, while not the cure, does get one closer.

We do have the incongruous result where "important" domains (or
however we describe them) are "weaker" (or however we characterize it)
than less important domains.  But for every "Entropy(licensing.disney.com) 
>> Entropy(irs.gov)" example, you'll find several .museum domains that 
are better off than .tv domains because of DNS-0x20.  And so maybe 
there's some justice after all.  :)

Re: the lack of harm: I'm not aware of any applications monitoring
recursive-to-authority traffic that would be negatively affected by
0x20 flipping.  (And if such IDS or mark protection equipment
triggered on anomalous variations in upper/lower case, I think we can
say they made bad assumptions.)  I am interested in hearing otherwise,
if anyone comes across an example.

-- 
David Dagon              /"\                          "When cryptography
[email-masked]      \ /  ASCII RIBBON CAMPAIGN    is outlawed, bayl
Ph.D. Student             X     AGAINST HTML MAIL      bhgynjf jvyy unir
Georgia Inst. of Tech.   / \                           cevinpl."

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 12 Mar 2008 13:19:30 -0400

On Tue, Mar 11, 2008 at 11:12:44PM -0400,
 Edward Lewis <[email-masked]> wrote 
 a message of 39 lines which said:

> this doesn't do a whole lot for the reverse map. 

It is much worse for all-digital domains (they are allowed in
".fr"). Should ICANN delegate numeric TLD, 1.666.42 would not be
protected by 0x20 :-)

---

From: David Conrad <[email-masked]>
Date: Wed, 12 Mar 2008 11:56:29 -0700

> ".fr"). Should ICANN delegate numeric TLD, 1.666.42 would not be

I believe ICANN has come out saying that all-numeric TLDs would be bad.

Regards,
-drc

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 12 Mar 2008 15:07:30 -0400

On Wed, Mar 12, 2008 at 11:56:29AM -0700,
 David Conrad <[email-masked]> wrote 

> I believe ICANN has come out saying that all-numeric TLDs would be

http://www.icann.org/topics/dns-stability-draft-paper-06feb08.pdf

> In order to prevent confusion with IPv4 addresses which are
> expressed as numeric labels separated by dots (e.g. 192.168.1.1)
> ICANN expects to disallow proposed TLDs containing only numeric
> characters. Such a prohibition will avoid a TLD typed into a browser
> from being resolved as an IP address.

Which proves that ICANN, in its wisdom, foresaw the 0X20 trick :-)

---

From: [email-masked]
Date: Wed, 12 Mar 2008 19:49:05 +0000

> I believe ICANN has come out saying that all-numeric TLDs would be bad.

	and do you think that ICANN might have the same advice,
	regardless of encoding?

--bill

---

From: David Conrad <[email-masked]>
Date: Wed, 12 Mar 2008 13:31:11 -0700

> 	and do you think that ICANN might have the same advice,

Not sure exactly what you mean, but I'd say numeric TLDs are just a  
bad idea.

Regards,
-drc

---

From: Paul Vixie <[email-masked]>
Date: Wed, 12 Mar 2008 20:48:48 +0000

> ..., but I'd say numeric TLDs are just a bad idea.

in the grand scheme of things i fear .EXE more than i fear .123, though.
(which is just more proof, as if we needed any, that DNS's presentation
layer is weakly defined and poorly implemented.)

---

From: David Conrad <[email-masked]>
Date: Wed, 12 Mar 2008 15:02:01 -0700

> in the grand scheme of things i fear .EXE more than i fear .123,  

So you must be terrified of .COM (and .PL and .SH and .INFO and ...).

A fully numeric hostname is fundamentally ambiguous if top-level  
domains are allowed to be all-numeric -- it would make a parser  
writer's life much more complicated (not to mention breaking pretty  
much all existing software that does hostname lookups).  I'm not sure  
I see why a domain name that happens to correspond to a file extension  
is that scary.  Clicking on http://youranidiot.exe is far less scary  
to me that clicking on http://<anything that actually resolves>/ 
youranidiot.exe.

What am I missing?

Regards,
-drc

---

From: Paul Vixie <[email-masked]>
Date: Wed, 12 Mar 2008 22:18:24 +0000

> So you must be terrified of .COM (and .PL and .SH and .INFO and ...).

no

> ...

the most unreliable and insecure element in any computing system, and
especially distributed computing systems, is the human.  humans won't
nec'ily click on something with .INFO on the end but they will, without
hesitation, click on something with .EXE on the end of its name.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 13 Mar 2008 09:29:46 +1100

> to me that clicking on http://<anything that actually resolves>/ 

	It's also banned by RFC 1123.

---

From: David Conrad <[email-masked]>
Date: Wed, 12 Mar 2008 16:42:25 -0700

>> So you must be terrified of .COM (and .PL and .SH and .INFO and ...).

But with the exception of .INFO, all of those extensions are  
executable on one system or another.  Where do you (or rather, ICANN)  
draw the line?

> especially distributed computing systems, is the human.

Of course.

> humans won't

Sorry, still confused.

Users today click on "click here to have your machine compromised".   
I'm confused how the allocation of a host in a top-level domain that  
corresponds to an executable file extension increases the risk,  
particularly since browser hostname namespace and file name namespace  
are completely disjoint (even in IE).

This isn't rhetorical: people have blasted ICANN because they have not  
disallowed EXE as a possible top-level domain.  I don't understand the  
threat model that is exposed by the allocation of that TLD (if were to  
come to pass which I doubt).  Namedroppers is probably not the best  
forum to be discussing this, so if anyone can clue me in as to why  
this would doom the Internet (so to speak), please tell me privately.

Thanks,
-drc

---

From: Joe Abley <[email-masked]>
Date: Wed, 12 Mar 2008 20:08:28 -0400

On 12-Mar-2008, at 18:02, David Conrad wrote:

> much all existing software that does hostname lookups).

s/complicated/intractable/, at least in extreme cases.

   $ORIGIN 4.
   199.212.90 A 199.212.90.6

When faced with the string of characters "199.212.90.4", should the  
result be the IP address 199.212.90.4, or the A record corresponding  
to the DNS name "199.212.90.4", i.e. 199.212.90.6?

I suppose it's fair to say that anybody who configured such a thing  
and ran into trouble probably already has feet full of holes.

The reverse tree would look fun, though ;-)

   $ORIGIN 90.212.199.in-addr.arpa.
   ;4 unassigned, kind of, maybe
   6 PTR 199.212.90.4.

Joe

---

From: Robert Elz <[email-masked]>
Date: Thu, 13 Mar 2008 09:53:00 +0700

Date:        Wed, 12 Mar 2008 20:08:28 -0400
    From:        Joe Abley <[email-masked]>
    Message-ID:  <[email-masked]>

  | s/complicated/intractable/, at least in extreme cases.

Only if you assume no tool redesign.   But that's already required
for v6, where addresses can look more like names (especially when
used in contexts where ':' is legal syntax, eg: URL's).

All you're saying is that if all numeric TLDs existed (which isn't
very likely at all) then applications would need a UI method to
allow the user to specify "this is an address" as distinct from
"this is a name", and would need to avoid the "see what it smells
like" test they currently do (often without thought, hidden in the
name->address translation routine).

The 1123 ban on all numeric TLDs isn't because they're evil or
impossible or anything like that, it was just a nod to the
practical realities of the implementations of the day (and still.)
It could be altered with sufficient (ie: decades) of advance
notice, if there was ever a good enough reason to do so.  Its
the latter hurdle that seems like the bigger issue.

kre

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 12 Mar 2008 22:46:32 -0400

On Thu, Mar 13, 2008 at 09:29:46AM +1100,
 Mark Andrews <[email-masked]> wrote 

> 	It's also banned by RFC 1123.

Chapter and verse, please. There is just a difficult-to-parse sentence
in section 2.1.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 13 Mar 2008 09:29:46 +1100

---

From: Florian Weimer <[email-masked]>
Date: Thu, 13 Mar 2008 11:53:28 +0100

> DNS-0x20, while not the cure, does get one closer.

One interesting thing about those 0x20 bits is that you don't have to
worry about uniqueness, so you can use a real PRNG to generate them,
instead of the likely-vulnerable LCG cruft that is found in most
resolvers.

> 0x20 flipping.

I imagine that there are in-line devices that perform case
normalization because the 0x20 bits can be seen as a covert channel.

I hope to do some tests next week (or probably the week after that, to
avoid influencing otther measurements) to see if such devices are in
front of any authoritative servers.

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

---

From: Thomas Narten <[email-masked]>
Date: Sat, 15 Mar 2008 11:53:15 -0700

> > in the grand scheme of things i fear .EXE more than i fear .123,  

Then you might want to read:

     "DNS Stability: The Effect of New Generic Top Level Domains on
     the Internet Domain Name System"

and provide input (see
http://www.icann.org/public_comment/#newgtlds-dns-stability).

I quote here the relevant text:

> File Extensions
> 
> ICANN has also considered the possible impact of allowing
> commonly-used file extensions as TLDs in the root, examining whether
> this might result in users or applications confusing URLs with
> filenames, or create other vulnerabilities for the user. Examples of
> such strings include:
> 
>                                ·   .EXE                         ·    .PDF
>                                ·   .HTML                        ·    .TXT
>                                ·   .DOC                         ·    .MP3
>                                ·   .JPG                         ·    .GIF
>                                ·   .CSV                         ·    .XLS
>                                ·   .PPT                         ·    .RTF
>                                ·   .ZIP
> 
> Staff explored this issue by consulting the Security and Stability
> Advisory Committee (see http://www.icann.org/committees/security/), as
> well as conducting some preliminary outreach to browser and operating
> system developers on the question of whether TLDs identical to file
> extensions could cause technical problems when attempting to be
> resolved in their particular programs. Responses to these inquiries
> have indicated that if there were problems resulting from the addition
> of TLD labels coinciding with common file extensions, they would be
> problems of user confusion rather than breakage in the DNS. It should
> also be noted that strings that are also file extensions exist as TLDs
> in the DNS today without adverse effects.
> 
> The DNS will perform look-ups of a TLD string without consideration to
> its perceived meaning in another context. If a user types
> "mydocument.pdf" into a browser, the auto completion rules of most
> commonly-used browsers will add the "http://" notation to the front of
> that string and perform a DNS lookup. Only by expressly indicating
> that the user is looking for a file with file://mydocument.pdf will
> the browser assume that a path to a file is indicated rather than a
> domain name. These are functions of the application, however, not the
> DNS. Based on this analysis, there does not appear to be a technical
> need to restrict common file extensions from also being TLDs.
> 
> The question remaining to be answered is whether there should be any
> application-oriented limitations on TLD strings. If ICANN wished to
> prevent potentially significant problems in the application layer or
> avoid user confusion issues resulting from a string like .EXE, it
> would need to do so based on a defined list of extensions that were
> disallowed, a list maintained outside of ICANN and internationally
> recognized as the authoritative source for "commonly used file
> extensions." Additionally, a mechanism for maintaining and updating
> such a list would need to be in place, because new file extensions
> could become prevalent at any time. To date, staff has not been able
> to locate a list of common file extensions that is generally
> acknowledged to be authoritative.
> 
> Given  preliminary feedback  that there  is  not a  technical need  to
> prevent  file  extensions  as  TLDs,   as  well  as  the  lack  of  an
> authoritative  source of common  file extensions  to draw  from, staff
> determined that it  is not workable to prevent  common file extensions
> from being  used as TLDs.  To  summarize, it is  the recommendation of
> the ICANN technical  staff to allow applications for  TLD strings that
> may also be commonly used for file extensions.

Thomas