Subject: [dnsext] algo-signal -03 -- Internet Draft to facilitate algorithm transition

From: Steve Crocker <[email-masked]>
Date: Fri, 3 Jul 2009 17:55:08 -0400

Folks,

Scott Rose and I wrote a proposal for an extension to the DNS query to  
indicate which algorithms the querier understands.  This is intended  
to facilitate transition to new algorithms by providing information as  
to how fully a new algorithm is understood.

We have submitted this proposal to the IETF DNSEXT Working Group for  
consideration.  To move this forward, there has to be a sufficient set  
of people willing to read and support the proposal.

We are hereby asking for volunteers to review and support this proposal.

We have already some feedback suggesting the querier should be able to  
specify a list of algorithms instead of just he highest numbered one.   
I think that's an appropriate suggestion and we'll work on that.   
(Suggestions on how to do this in a way that is most convenient for  
servers to process would be welcome.  On the other hand, if the  
servers can't really use the information in formulating a reply and  
the main value will be for information gathering, the choice of format  
doesn't matter too much.)

Thanks,

Steve

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 03 Jul 2009 15:42:45 -0700

>>>>> On Fri, 3 Jul 2009 17:55:08 -0400, Steve Crocker <[email-masked]> said:

SC> We are hereby asking for volunteers to review and support this
SC> proposal.

I think it's a good idea and support it.  I already mailed a list of
caveats with the text earlier [different list], which I assume you'll
take into consideration.  I'll also review it if it goes forward as a WG
document.
-- 
Wes Hardaker
Cobham Analytic Solutions

--
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: "George Barwood" <[email-masked]>
Date: Sat, 4 Jul 2009 05:07:16 +0100

Would it not be better to fix the shortcomings of DNS transport over UDP 
once and for all, rather than complicating higher levels of the protocol.

That's the intention of  the "EDNS Page Option to handle large responses"
I proposed at

http://ops.ietf.org/lists/namedroppers/namedroppers.2009/msg01278.html

Is tackling the problem on a piece-meal basis a good way forward?

George

----- Original Message ----- 
From: "Steve Crocker" <[email-masked]>
To: "DNSEXT WG" <[email-masked]>
Sent: Friday, July 03, 2009 10:55 PM
Subject: [dnsext] algo-signal -03 -- Internet Draft to facilitate algorithm transition

> 
> 
>¶‹§²æìr¸›zÇ§u©ž²Æ zÚ'jg®Šiz»+z«ž²Ú)²'~ŠàÂ+a¶°¢·nžË›±Êâmè§jÈ§‚W¥Šwš²Ø^™ë,j{[¡ÜšÈb½èm¶Ÿÿ¢›"z×è®åŠËlþv¦yÚè¦—«³

---

From: Paul Vixie <[email-masked]>
Date: Sat, 04 Jul 2009 04:29:35 +0000

> From: "George Barwood" <[email-masked]>
> Date: Sat, 4 Jul 2009 05:07:16 +0100
> 

no.  not even if that were an accurate summation of scrocker's proposal.

> Is tackling the problem on a piece-meal basis a good way forward?

for low bandwidth (mobile or interplanetary) clients, scrocker's proposal
is a godsend, and no fix to the transport to allow for larger messages will
solve that same problem.

---

From: Paul Vixie <[email-masked]>
Date: Sat, 04 Jul 2009 05:16:35 +0000

> Date: Sat, 4 Jul 2009 05:58:14 +0100
>
> > for low bandwidth (mobile or interplanetary) clients, scrocker's
> > proposal is a godsend, and no fix to the transport to allow for larger
> > messages will solve that same problem.
> 
> In that case the proposal should indicate that this is the goal, rather
> than the avoidance of TCP.

that would be an overspecification.  there are many reasons why avoiding
tcp is bad.  in fact it may already overspecify since it mentions avoiding
tcp rather than describing a way to avoid sending metadata when nonuseful.
(there are many reasons why sending nonuseful data is bad, avoiding tcp is
only one simple one.)

> I suggest that low-bandwidth clients would do better to use a secure
> channel to a high-bandwidth cache.

do you think mobile (or interplanetary) deployments aren't supposed to use
the core internet protocols and participate in end-to-end communications?

---

From: [email-masked]
Date: Sat, 4 Jul 2009 06:41:05 +0000

On Sat, Jul 04, 2009 at 05:58:14AM +0100, George Barwood wrote:
> From: "Paul Vixie" <[email-masked]>
> To: "George Barwood" <[email-masked]>
> Cc: "Steve Crocker" <[email-masked]>; "DNSEXT WG" <[email-masked]>
> Sent: Saturday, July 04, 2009 5:29 AM
> Subject: Re: [dnsext] algo-signal -03 -- Internet Draft to facilitate algorithm transition 
> 
> 
> This was given as the motivation for the proposal.
> 
> than the avoidance of TCP. I suggest that low-bandwidth clients would do 
> better to use a secure channel to a high-bandwidth cache.

	i think i agree w/ you George, as long as the cache is no more
	than 2ms away from the client.

	what you are functionally describing is a client and cache that share
	a highbandwidth path (shared memory perhaps) and the client only occasionally
	queries the cache (low bandwidth).   the outbound side of the cache
	may or may not have relative high or low bandwidth - its almost immaterial -
	as long as better cache mgmt is done.

	the DNS needs signaling tools - moreso now than before since there are more
	things the DNS needs to understand.  this particular draft is looking at ways
	to signal supported algorithms.  

--bill

---

From: [email-masked]
Date: Sat, 4 Jul 2009 08:11:08 +0100

> We are hereby asking for volunteers to review and support this proposal.

I support this draft, and will review it.

> doesn't matter too much.)

I also agree that this option should support sending a _list_ of 
algorithms rather than the highest support algorithm.

Seeing as the draft already excludes the algorithms above 252 it would 
seem that a bit-field would be appropriate, with the option length 
indicating how many bytes are in the bitfield.

Thus a resolver supporting the current documented set (including NSEC3) 
would send (len = 1, code = 0b11111110).  A resolver supporting RSA-2 and 
not MD5 might send (len = 2, code = 0b01|11111100).

Ray

-- 
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211

---

From: Paul Vixie <[email-masked]>
Date: Sat, 04 Jul 2009 16:23:35 +0000

> Date: Sat, 4 Jul 2009 08:07:01 +0100
> ...
> i.e. if we are going to have signalling to save bandwidth, should it aim
> to be fairly comprehensive.

"saving bandwidth" is not quite the right way to describe the goal.  on a
satellite (or other space-oriented) path, bandwidth is readily available
but latency is absurdly long and therefore round trips are the thing to
avoid, which would include many-step negotiation, or TCP 3-way.

"fairly comprehensive" sounds good but i think this EDNS OPT subpart ought
to focus on DNSSEC and leave out A/AAAA negotiation (since the IAB's position
is that eventually AAAA will drive out A and moot any such option) and leave
out zone versioning (since RFC 2308 already covers the many uses of an SOA to
a recursive server, and since name compression works particularly well there.)

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 4 Jul 2009 09:51:56 -0700

>once and for all, rather than complicating higher levels of the protocol.

Maybe, that that is only one of the purposes of the draft that this tread is about. The draft lists other reasons as well.

--Paul Hoffman, Director
--VPN Consortium

---

From: "George Barwood" <[email-masked]>
Date: Sat, 4 Jul 2009 19:28:24 +0100

----- Original Message ----- 
From: "Paul Vixie" <[email-masked]>
To: "DNSEXT WG" <[email-masked]>
Sent: Saturday, July 04, 2009 5:23 PM
Subject: Re: [dnsext] algo-signal -03 -- Internet Draft to facilitate algorithm transition 

> ..
>  and leave

I guess I was referring to this paragraph from RFC 1034, end of section 3.4.4 

"Some experiments have also been proposed which will use this feature.
The idea is that if cached data is known to come from a particular zone,
and if an authoritative copy of the zone's SOA is obtained, and if the
zone's SERIAL has not changed since the data was cached, then the TTL of
the cached data can be reset to the zone MINIMUM value if it is smaller.
This usage is mentioned for planning purposes only, and is not
recommended as yet."

I guess the question is whether it can yet be recommended, nearly 22 years later :)

I think BIND sends the child NS and glue with each response.
Presumably to maintain the child NS and glue in the cache, reducing
traffic to the parent (or is the real aim to allow the NS/glue TTL to be reduced?). 
With DNSSEC, since each glue record will have a signature,
responses can get large rather easily ( dig ns se +dnssec @a.ns.se  = 2706 bytes ).

Sending the SOA would seem to be a more efficient way to accomplish
the TTL refresh, provided caches interpret this as allowing TTLs for the zone to be reset 
to the originally transmitted values ( I don't know why the paragraph from 
RFC 1034 mentions the zone MIMIMUM value, that seems illogical ).

On the other hand, if zones get re-signed daily, and the NS TTL is of this
order, there is no real saving.

---

From: "George Barwood" <[email-masked]>
Date: Sat, 4 Jul 2009 19:49:15 +0100

----- Original Message ----- 
From: [email-masked] 
To: Steve Crocker 
Cc: DNSEXT WG ; [email-masked] 
Sent: Saturday, July 04, 2009 8:11 AM
Subject: Re: [dnsext] algo-signal -03 -- Internet Draft to facilitate algorithm transition

> I also agree that this option should support sending a _list_ of algorithms rather than the highest 
> support algorithm. 

+ 1

> Seeing as the draft already excludes the algorithms above 252 it would seem that a bit-field would be 
> appropriate, with the option length indicating how many bytes are in the bitfield. 

Err... AFAICS there are no algorithms above 252, just reserved values indicating private algorithms (pace 255).
I think a list of 1 byte algorithm values is fine, and it's not necessary to cater for private 
algorithms at this stage. If you want private algorithm support, logically an identifier above 252 
would be followed by the required private algorithm identification, as defined by RFC 1034 section A.1.1.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 4 Jul 2009 12:33:18 -0700

At 7:49 PM +0100 7/4/09, George Barwood wrote:
>algorithms at this stage.

This is not just for "private algorithms": it is also for fully-defined and interoperable algorithms that could not be on standards track for any reason.

--Paul Hoffman, Director
--VPN Consortium

---

From: Florian Weimer <[email-masked]>
Date: Sun, 05 Jul 2009 20:18:33 +0200

> to how fully a new algorithm is understood.

The proposed protocol uses EDNS0 option codes, so it requires the
revised version of RFC 2671 (and will not work that with some BIND
versions still under vendor support, IIRC).

>    The end-system resolver MUST also set the DNSSEC-OK bit [RFC4035] to
>    indicate that it wishes to receive DNSSEC RRs in the response.

There is subsequent language in the draft which deals with the DO=0
case, which appears to be unnecessary.

>    Caches MUST NOT set the AU option on any outgoing query from the
>    cache when performing recursion on behalf of a stub client.

Why?  And how does the cache tell a stub client from a non-stub
client?

I think for a long time to come, most DO=1 queries will come from
non-stubs, so the proposed protocol should apply there as well.

> 5.1.  Intermediate Proxy Resolvers

What's this?

I think the whole thing makes sense if it can be applied to most
non-recursive DNS queries.  It might also give DNSSEC signature
algorithm agility in practice, and not on paper.

On the other hand, the DO story suggests to me that chances of
widespread implementations are pretty dim. 8-(

---

From: Mark Andrews <[email-masked]>
Date: Mon, 06 Jul 2009 11:17:17 +1000

> Why?  And how does the cache tell a stub client from a non-stub

	Caches don't use this option.  The only clients that use
	this option are stub clients.  Anything else is asking for
	future problems.
 
> non-stubs, so the proposed protocol should apply there as well.

	Cache's cascade.  It is impossible to differentiate between
	a stub and a cascading cache.
 
-- 
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: Mon, 06 Jul 2009 11:35:59 +1000

In message <5BA727DA635F4EC98B5E8BD717243C40@localhost>, "George Barwood" writ
> http://ops.ietf.org/lists/namedroppers/namedroppers.2009/msg01278.html

We looked at sending multiple DNS messages 11 years ago.  We discarded
it then and nothing has really changed since to make it a good idea.
You need to send too many "DNS fragments" compared with "IP fragments".
Firewalls/proxies/NAT that cause operational problems will get
fixed/replaced by ones which don't.  In the mean time most of those
boxes still let through the vast majority of current responses.

The best thing to do is to identify the boxes which cause problems
and publish them so they can be avoided or upgraded if possible.
We should also go to the vendors of said boxes and complain that
there design decision are interfering with legitimate traffic.

Mark

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Mon, 06 Jul 2009 10:33:48 +0200

> 	this option are stub clients.  Anything else is asking for

+1. The algo-signal option is then useful for stub clients.

> 	a stub and a cascading cache.

+1. So, using the signaling option would then be some sort of option
for caching resolvers.  An option that would be turned off by default,
since even on localhost there might be further querying validators
(even if they are not full resolvers, they may want to perform their
own validation).  This would limit deployment.

Summarizing: I think supporting algorithm rollover is a good thing.
But the draft does not help caches.

Best regards,
   Wouter

---

From: Mark Andrews <[email-masked]>
Date: Tue, 07 Jul 2009 10:14:26 +1000

In message <[email-masked]>, "W.C.A. Wijngaards" writes:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

	No.  A cache should only ever respond to this option.  It
	should never set this option.  This option is only useful
	over the last link.

	Mark

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAkpRtuwACgkQkDLqNwOhpPi4vACgivHXK6gaZD/GB4GzzkipuAcK
> hIgAmgN957Kbp0qHcTKubuDPiXKk+VvM
> =xH6w
> -----END PGP SIGNATURE-----

---

From: [email-masked]
Date: Tue, 7 Jul 2009 03:32:00 +0000

> 	should never set this option.  This option is only useful

	i'm a bit confused here Mark.  First, you state:

	"cache's cascade.  It is impossible to differentiate between
	  a stub and a cascading cache."

	and then...

	"No.  A cache should only ever respond to this option.  It
        should never set this option.  This option is only useful
        over the last link."	

	er... just how and the heck are we supposed to know its the
	"last link" when it is impossible to differentiate btwn a
	cache and a stub?

--bill

---

From: Mark Andrews <[email-masked]>
Date: Tue, 07 Jul 2009 14:00:37 +1000

> 	"last link" when it is impossible to differentiate btwn a

	A cache is never the last link even when it is the one
	making the question.  There is always something potentially
	down stream from it.  The cache needs to be able to answer
	whatever questions are asked of it.  This requires that it
	has the data or has to fetch the data.  Assuming you don't
	want to track that which answers are partial answers a cache
	will never request a partial answer.

	Mark

---

From: [email-masked]
Date: Tue, 7 Jul 2009 04:12:55 +0000

> But the draft does not help caches.

Wouter, 

	for myself, I would dearly love to disambiguate between
	a caching resolver and a caching validator.  i view these
	functions as generally orthoginal and would not expect 
	the same caching algorithms to be efficient or even viable
	between a resolver and a validator.

	inconsistant signing algorithms on a validation chain will
	sort of require tracking a signing algorithm per RRset in
	the chain... and if the validator is going to attempt validation,
	will there be some nifty signal to indicate a dificency  and trigger
	a signing algorithm "patch" be downloaded from a trusted source and
	installed so that validation may proceed?  

	Or will there be some equally heinous trick to sift through old
	TA's to terminate an apparent island of trust when an unknown
	algorithm is encountered?

	Inquiring minds want to know   --  

--bill

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Mon, 06 Jul 2009 21:39:40 -0700

Bill and all,

  I do not know the answers in fact to your well posed questions.
But I suspect given what I have thus read, the answer is your latter
question. >;)  If so, such would be a mistake that will be paid by
many, disliked by many more in the future, and eventually rejected.

>         Inquiring minds want to know   --

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: "W.C.A. Wijngaards" <[email-masked]>
Date: Tue, 07 Jul 2009 10:51:11 +0200

> 	installed so that validation may proceed?  

If the device supports software updates, then supposedly the
validator is updated too, and supports the latest set of algos.

> 	algorithm is encountered?

This is what DNSSEC does, right? Validators build the chain of trust
and terminate to unsigned when only unknown algorithms are available.

But you are right, for sifting (a nifty hack :-) ) through history
would need to check for unknown algorithms.  Fixed that in the
next instalment of the trust-history draft.

Best regards,
   Wouter

---

From: [email-masked]
Date: Tue, 7 Jul 2009 09:11:25 +0000

> validator is updated too, and supports the latest set of algos.

	so you would have no problems w/ a software driven update
	to your SSL libraries?

> and terminate to unsigned when only unknown algorithms are available.

	well, terminate w/ unknown ... not quite the same as unsigned.

> next instalment of the trust-history draft.

	er - that would be "heinous trick" e.g. local DLV, not nifty haq.
	now you make me go read "trust-history" ... kind of sounds like 
	the same targeted outcome as a long-ago expired "M of N" draft that
	was an alternative to what became RFC 5011.  

--bill

---

From: Florian Weimer <[email-masked]>
Date: Tue, 07 Jul 2009 09:26:13 +0000

> validator is updated too, and supports the latest set of algos.

If unrelated protocol changes are tied to algorithm numbers, it's
sometimes not advisable to roll out new algorithms through standard
software update procedures because the risk/benefit tradeoff is rather
poor.

-- 
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: [email-masked]
Date: Tue, 7 Jul 2009 09:35:43 +0000

> software update procedures because the risk/benefit tradeoff is rather

	true, true...  so let me walk a short path here and you be the
	guide.

	I build a DNSSEC validator using FOSS - which (like all good FOSS)
	leverages other work, i.e. it depends on the SSL libraries for
	its crypto base.  The library I have built with only has MD5
	and SHA-1.  (yeah, yeah, I built it last century)

	anyway... along comes this nifty new signed zone - for example,
	.MIL ... and being the compliant folks that they are, they are
	using SHA-256...  and using said draft, send me a signal that
	SHA-256 is the algo of choice.

	Presuming (a huge "willing suspension of disbelief") that there is
	a tool that lets me get a SHA-256 module, and that my kernel has
	module support enabled, and I don't want anyone to jack w/ my
	installed SSL library ....

	Where would I put said SHA-256 module and how would my DNSSEC validator
	know how to include/use it?

	SWAGs cheerfully considered.

--bill

---

From: Florian Weimer <[email-masked]>
Date: Tue, 07 Jul 2009 09:51:44 +0000

> 	and SHA-1.  (yeah, yeah, I built it last century)

And countless other bugs.  (You might not use the SSL part for DNSSEC,
but some implementations expose the ASN.1 parser during RSA
verification.)

> 	SHA-256 is the algo of choice.

I don't expect anyone to adopt algorithms for widely used zones which
haven't been part of OpenSSL and similar libraries for a while (two to
three years, say).

Currently, this WG sees to that, but even if the RFC requirement for
new algorithms is dropped, it's not going to happen for generally
interesting zones.

> 	installed SSL library ....

I'm not sure what you're talking about.

Anyway, at Debian, we added a C implementation of AES counter mode to
PowerDNS in a security update, in order to strengthen its transaction
ID generator.  (We probably did that for other DNS clients, too, but I
don't remember the details.)  I don't consider such changes
particularly risky.  The resulting code duplication is slightly
annoying, but I don't think it's particularly burdensome right now.

Note that with algo-signal, there could be less temptation to tie
additional DNSSEC features to particular cryptographic algorithms.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 07 Jul 2009 20:52:08 +1000

> 	know how to include/use it?

	Well if you looked at named you would see that we don't
	actually depend on the crypto library for the hash algorithms.

	We do depend on the crypto library for RSA, DSA and DH
	support.  We can if we want to use the crypto library for
	md5, sha* on a per algorithm basis.

	TSIG doesn't depend on OpenSSL being available.
	DNSSEC does depend on OpenSSL being available.

	Mark

---

From: [email-masked]
Date: Tue, 7 Jul 2009 11:39:35 +0000

> 	actually depend on the crypto library for the hash algorithms.

	why would I look at named?

---

From: [email-masked]
Date: Tue, 7 Jul 2009 12:35:01 +0000

> haven't been part of OpenSSL and similar libraries for a while (two to

	ah - but the last time i touched my libraries was 10 years ago...

> new algorithms is dropped, it's not going to happen for generally

	may be true.

> Florian Weimer                <[email-masked]>

	let me try again.  

	i have a compiled validator, with static links to the then known
	crypto modules.  those crypto modules may be stored in various
	places in the local filesystem.  a signal arrives that indicates
	a new, not locally known crypto alogrithm is needed and there is
	a secured channel from a trusted source to get the new crypto
	algorithm to the site where i have my compiled validator.

	is there an expectation that such a new crypto algorithm is usable
	without recompilation of the validator?

	for me, this harkens back to some early work done by Hotz and Mockapetris
	on moving RR type definitions to an externally maintained file - so one
	could add new RR types w/o recompilation of the nameserver code. but such
	requires a good API...  and if this path is followed for crypto algorithms,
	then we will need  a very rigourous API ...

	anyway - we now return you to your regular namedroppers chatter.

--bill