Subject: [dnsext] comments on draft-crocker-dnssec-algo-signal-03

From: Michael Graff <[email-masked]>
Date: Wed, 29 Jul 2009 05:56:33 -0500

Let me state some reasons I'm opposed to this draft's purpose, even 
though I think some part of it would be very interesting to pursue.

(1)  This becomes a meta-type in practice.  It might prevent some 
lookups initially, but should a client ask for items that were not in 
the cache, the server would have to remember which algorithms it saw in 
the DNSKEY response to know which it could usefully retrieve with 
follow-on queries.  For example, a particular stub might support more 
algorithms than the cache it asks, so additional queries (including 
additional queries for the DNSKEY to obtain its signatures) would have 
to be generated.

(2)  This solves a problem I do not fully believe is a problem, that of 
TCP fallback.  I've said it before, but chat servers, web servers, and 
other types of TCP-based servers handle many, many connections/sec and 
many, many sustained clients today.  I don't understand why DNS is 
different here, excepting perhaps that we have not encountered this 
situation until now.

(3)  It solves a problem that I do not fully believe is a problem, that 
of fragmented packets.  There is no solid solution in this proposal that 
it WILL get packets through, only that it might have a better chance to 
do so.  Key rollover will still cause large packets and/or TCP fallback, 
which means only during rollover events will badness occur.  I'd rather 
it occur all the time rather than only in some situations.

(4)  I believe the knowledge it would allow to be gathered -- that of 
which algorithms, hashes, etc. were in common use -- is very valuable. 
Perhaps a draft on "voluntary reporting of server capabilities" would be 
useful, where the data would be anonymous, infrequently (order days at 
least) reported, and collected into reports.  Knowing that RSA/SHA1 is 
not used any longer is very good information to know in terms of 
deprecating protocols, but using that as a filter seems unwise to me.

--Michael

--
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: bert hubert <[email-masked]>
Date: Wed, 29 Jul 2009 23:35:02 +0200

On Wed, Jul 29, 2009 at 12:56 PM, Michael Graff<[email-masked]> wrote:
> Let me state some reasons I'm opposed to this draft's purpose, even though I
> think some part of it would be very interesting to pursue.

To add my reason why I'm opposed to this draft (versus its purpose):
The complexity of DNSSEC is already of such stunning magnitude that
almost anything that makes it even more complex, better have an earth
shatteringly good reason going for it.

And in this case, I'm not convinced selecting algorithms is the only
way to go - it may in fact be better to simply pick algorithms well,
and not choose too many.

It may be that my state of mind is influenced by trying to implement
NSEC3 processing - but when that is done, I don't think my opinion of
DNSSEC complexity, and it being too complex already, is going to
change.

     Bert

---

From: Paul Wouters <[email-masked]>
Date: Wed, 29 Jul 2009 18:34:45 -0400 (EDT)

> DNSSEC complexity, and it being too complex already, is going to

It grows on you. Having dinner with Roy helps too.

Paul

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Wed, 29 Jul 2009 19:26:30 -0700

Micahel and all,

  I agree fully here...

> deprecating protocols, but using that as a filter seems unwise to me.

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: [email-masked]
Date: Thu, 30 Jul 2009 10:36:08 +0000

> It grows on you. Having dinner with Roy helps too.

	Roy doesn't scale.  :)

--bill

---

From: Joe Abley <[email-masked]>
Date: Thu, 30 Jul 2009 13:55:37 +0200

On 29-Jul-2009, at 23:35, bert hubert wrote:

>> though I

I think we either need to be prepared to roll algorithms in the  
future, or we don't.

If we do, then I think it's reasonable to think that in some cases an  
algorithm roll will be mandated because of a perceived weakness in one  
algorithm, and that the replacement algorithm may not be as widely  
deployed as the weak algorithm.

If we accept these points, then I think there's an operational need to  
be able to measure deployment of the new algorithm. This was Steve's  
point in his presentation yesterday, I think.

I don't think the fall from grace of an algorithm will shatter the  
earth, but it seems like something we should be prepared to do well.

Joe

---

From: Michael Graff <[email-masked]>
Date: Thu, 30 Jul 2009 14:25:46 +0200

As long as it is statistical that's good. If it is used to filter  
rrsigs I feel that is bad. That is all.

A protocol to announce to some group once a month or something basic  
capabilities would be nice. Measured deployments of new and old  
protocols would really help decision making.

--Michael

On Jul 30, 2009, at 13:55, Joe Abley <[email-masked]> wrote:

> If we do, then I think it's reasonable to think that in some cases  
> an algorithm roll will be mandated because of a perceived weakness  
> in one algorithm, and that the replacement algorithm may not be as  
> widely deployed as the weak algorithm.
>
> If we accept these points, then I think there's an operational need  
> to be able to measure deployment of the new algorithm. This was  
> Steve's point in his presentation yesterday, I think.
>

---

From: Eric Osterweil <[email-masked]>
Date: Thu, 30 Jul 2009 14:29:28 +0200

On Jul 29, 2009, at 12:56 PM, Michael Graff wrote:

> lookups initially, but should a client ask for items that were not  
> in the cache, the server would have to remember which algorithms it  
> saw in the DNSKEY response to know which it could usefully retrieve  
> with follow-on queries.  For example, a particular stub might  
> support more algorithms than the cache it asks, so additional  
> queries (including additional queries for the DNSKEY to obtain its  
> signatures) would have to be generated.
>
> (2)  This solves a problem I do not fully believe is a problem, that  
> of TCP fallback.  I've said it before, but chat servers, web  
> servers, and other types of TCP-based servers handle many, many  
> connections/sec and many, many sustained clients today.  I don't  
> understand why DNS is different here, excepting perhaps that we have  
> not encountered this situation until now.
>
> (3)  It solves a problem that I do not fully believe is a problem,  
> that of fragmented packets.  There is no solid solution in this  
> proposal that it WILL get packets through, only that it might have a  
> better chance to do so.  Key rollover will still cause large packets  
> and/or TCP fallback, which means only during rollover events will  
> badness occur.  I'd rather it occur all the time rather than only in  
> some situations.

So, I don't completely understand this.  The PMTU problem is actually  
observable, so why are you saying it doesn't exist?  There are  
numerous zones for which this can be seen.  Also, I think it is  
important to note that a TC bit is commonly interpreted to mean, "do  
TCP now."  However, this does not need to be the case, and RFC 2671  
does not advocate that approach either.

Maybe before this descends too quickly, would you mind clarifying why  
you don't believe it is a problem?

>
>
> (4)  I believe the knowledge it would allow to be gathered -- that  
> of which algorithms, hashes, etc. were in common use -- is very  
> valuable. Perhaps a draft on "voluntary reporting of server  
> capabilities" would be useful, where the data would be anonymous,  
> infrequently (order days at least) reported, and collected into  
> reports.  Knowing that RSA/SHA1 is not used any longer is very good  
> information to know in terms of deprecating protocols, but using  
> that as a filter seems unwise to me.

fwiw, this is available on the front page of:
	http://secspider.cs.ucla.edu/
under "Distribution of key algorithms in use."  Is that not a  
sufficient summary?

Eric

---

From: Michael Graff <[email-masked]>
Date: Thu, 30 Jul 2009 14:57:48 +0200

I remain unconvinced that tcp is evil.

Re secspider yes it is not as useful. It measures probed algorithms  
not reported ability to use algorithms.

--Michael

On Jul 30, 2009, at 14:29, Eric Osterweil <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>> (2)  This solves a problem I do not fully believe is a problem,  
>> that of TCP fallback.  I've said it before, but chat servers, web  
>> understand why DNS is different here, excepting perhaps that we  
>> have not encountered this situation until now.
>>
>> proposal that it WILL get packets through, only that it might have  
>> a better chance to do so.  Key rollover will still cause large  
>> packets and/or TCP fallback, which means only during rollover  
>> events will badness occur.  I'd rather it occur all the time rather  
>> than only in some situations.
>
> So, I don't completely understand this.  The PMTU problem is  
> actually observable, so why are you saying it doesn't exist?  There  
> are numerous zones for which this can be seen.  Also, I think it is  
> Maybe before this descends too quickly, would you mind clarifying  
> why you don't believe it is a problem?
>
>>
>>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (Darwin)
>
> iEYEARECAAYFAkpxkisACgkQK/tq6CJjZQKB/ACeN6aqvjcsBEFOKaPaf2m3ioXO
> dIMAoIOR7rwumf5N6oE/TSmSb4IoA+qt
> =r7Ia
> -----END PGP SIGNATURE-----

---

From: Eric Osterweil <[email-masked]>
Date: Thu, 30 Jul 2009 15:08:37 +0200

> I remain unconvinced that tcp is evil.

Maybe the.org folk can speak more directly to how the over-zealous use  
of TCP affects their operations... Actually, does anyone here feel  
that over use of TCP is detrimental?  It seems wasteful to add load to  
servers and latency to queries when it can be avoided, and I think  
there is plenty of data to show that it can often be avoided.

TCP may not be evil (indeed), but it is being overused here and that  
can be avoided.

Perhaps a better question, what would convince you?

> not reported ability to use algorithms.

You asked for a list "which algorithms, hashes, etc. were in common  
use..." This is exactly the answer to that question from the  
authoritative name server side.  Also, what does "prob[ing]" have to  
do with anything?  If you're strictly speaking about resolver  
capabilities, then I think you should _also_ consider that the algos  
served by name servers are important too.

>>> Let me state some reasons I'm opposed to this draft's purpose,  
>>> even though I think some part of it would be very interesting to  
>>> pursue.
>>>
>>> in the cache, the server would have to remember which algorithms  
>>> it saw in the DNSKEY response to know which it could usefully  
>>> retrieve with follow-on queries.  For example, a particular stub  
>>> might support more algorithms than the cache it asks, so  
>>> additional queries (including additional queries for the DNSKEY to  
>>> obtain its signatures) would have to be generated.
>>>
>>> events will badness occur.  I'd rather it occur all the time  
>>> rather than only in some situations.
>>
>> important to note that a TC bit is commonly interpreted to mean,  
>> "do TCP now."  However, this does not need to be the case, and RFC  
>> 2671 does not advocate that approach either.
>>
>>> reports.  Knowing that RSA/SHA1 is not used any longer is very  
>>> good information to know in terms of deprecating protocols, but  
>>> using that as a filter seems unwise to me.
>>

---

From: [email-masked]
Date: Thu, 30 Jul 2009 13:28:54 +0000

"Transport considerations for DNS

DNS queries and responses are available over a variety of transports
(UDP/TCP) and may be ported to use other transports in the future. Current
use profiles show that most user generated DNS traffic prefers one
transport over another.  This historical usage pattern has or may lead
to the presumption that any DNS traffic, regardless of transport, should
be considered on equal footing.

However, not all choices for transport share an equal cost to the DNS
operator.  This note is intended to inform and educate - that while
all transport options MUST/(need to) be supported, because of the different
cost and risk profiles of some transports, an operator may chose to
apply different processing criteria to different transports, prefering
some transport options over others."

--bill

On Thu, Jul 30, 2009 at 03:08:37PM +0200, Eric Osterweil wrote:
> iEYEARECAAYFAkpxm1UACgkQK/tq6CJjZQKCdACeJ7YlgwASZW5EeRGWKUyjk4g8
> C+MAn2GXN2KrHzqp05OKuGku4eMSly0c
> =bnZb

---

From: bert hubert <[email-masked]>
Date: Thu, 30 Jul 2009 15:12:14 +0200

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

> I remain unconvinced that tcp is evil.

As an implementor, I'd tend to agree. Operators however may not be
happy with their (forced) change of mission from '99.9% UDP' to 'far
larger UDP packets plus heaps of TCP sessions'.

Even if we do our job really well as implementors, it has to be
admitted that blasting out UDP is a lot easier than doing millions of
TCP/IP sessions.

This might be offset by the fact that TCP tends to be highly optimised
whereas UDP is sort of neglected in many kernels.

But it is probably reasonable to say that a server that maxes out at n
kpqs UDP will not attain that same query rate over TCP, no matter how
hard we try.

      Bert

---

From: Paul Vixie <[email-masked]>
Date: Fri, 31 Jul 2009 02:29:35 +0000

> From: Michael Graff <[email-masked]>
> Date: Thu, 30 Jul 2009 14:57:48 +0200
> 

what would it take to convince you?

---

From: [email-masked]
Date: Fri, 31 Jul 2009 02:57:02 +0000

> what would it take to convince you?

	verifiable evidence of malevolent intent.
	and since some fo the TCP authors are still with
	us, we could ask them if TCP was designed to be evil.

	otherwise, i think I'm w/ Michael on this.  the transport,
	in and of itself is not evil.

--bill

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Thu, 30 Jul 2009 22:32:57 -0700

Bill and all,

  Of course TCP is not evil.  And of course TCP can and is too
often used in an evil manner or abused in many ways as to appear
to be evil.  Ergo those that abuse same or use same in an abusive
manner may be viewed as evil or otherwise ill advised.

Regards,

---

From: Eric Osterweil <[email-masked]>
Date: Fri, 31 Jul 2009 09:12:26 +0200

No one, here, has maintained that TCP is evil.  I know that I have not  
said so.

The assertion was merely that it is being used more often than  
necessary, and it should be used more judiciously.

Eric

---

From: Mark Andrews <[email-masked]>
Date: Fri, 31 Jul 2009 17:42:26 +1000

In message <[email-masked]>, bert 
> larger UDP packets plus heaps of TCP sessions'.

	The data doesn't back that up.

	6000 UDP q/s results in 60 TCP q/s 

	This is not heaps of TCP.  HTTP servers start falling over
	at 10K TCP connections per second.

	You need to be responding to a million UDP queries/s on a single
	box to get 10K tcp connections/s on a single box.

	TCP fallback is still at noise levels.

	Mark

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

---

From: Niall O'Reilly <[email-masked]>
Date: Fri, 31 Jul 2009 11:05:31 +0100

> box to get 10K tcp connections/s on a single box.

	Mark,

	You seem to be leaping from "[today's] data doesn't back
	that up" to discovering a fixed ratio relating the use of one
	type of transport to that of the other.  I'ld be surprised to
	learn that there's data to back _that_ up.

	OTOH, this is not to say that

 > TCP fallback is still at noise levels.

	isn't true.

	Best regards,
	Niall O'Reilly

---

From: bert hubert <[email-masked]>
Date: Fri, 31 Jul 2009 13:15:52 +0200

>        6000 UDP q/s results in 60 TCP q/s

I was talking about the brave new world that has such wonderfully
large DNSKEY and RRSIG RRSETs in it.

     Bert

---

From: Michael Graff <[email-masked]>
Date: Fri, 31 Jul 2009 13:24:38 -0500

> what would it take to convince you?

I would like to see someonefind out two things.

One, if the bottleneck and fear of something that gas been around for  
many years (DNS over tcp) is on the equipment, os, or DNS server code.

Two, how is this not a ddos vector waiting to happen today?

That is, provisioning against stress and planning on ddos, how would  
an admin react differently in server and network capacity planning?

In short, why is the increase if tcp in real queries a real problem  
when in a properly chosen algorithm and with reasonable ttl values, it  
can be minimized?

--Michael

---

From: Michael Graff <[email-masked]>
Date: Fri, 31 Jul 2009 13:49:24 -0500

Appologies to all for not catching that my iPhone is choosing words  
badly.

--Michael