Subject: RE: [Cfrg] Re: [saag] Algorithm upgrades

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sun, 7 Nov 2004 14:25:22 -0800

I agree on the sentiment, disagree on the method.

There are three viable ways to signal the change:

1) Use a new port
2) Define a DNS RR to describe the configuration of the protocol
3) Use a prefixed DNS TXT record to describe the configuration

(1) and (2) suffer from the limited ports problem, only 1024 well known
ports, 65K TOTAL, same for RRs. The use of new RRs also has the severe
disadvantage of not working for about 50% of the deployed infrastructure
(and don't believe the fariy stories that claim otherwise, it ain't true
unless your definition of 'working' does not require production strength
code).

_telnet._security.example.com TXT "encrypt=AES,DES; auth=RSA288382811k=="

Deployable, viable, simple, workable.

The Internet needs a policy layer, the people who say that is too hard
should be told to go home, shut up and not bother the grownups who do know
how to make it work.

	Phill

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of D. J. Bernstein
> Sent: Sunday, November 07, 2004 3:12 PM
> To: [email-masked]; [email-masked]
> Subject: Re: [Cfrg] Re: [saag] Algorithm upgrades
> 
> 
> Bill Sommerfeld writes:
> > there are only 16 bits of well-known port, and you 
> generally need much 
> > more than one bit to encode sufficiently rich combinations of 
> > algorithm parameters
> 
> Sufficient for what, exactly?
> 
> A moment ago we were talking about the upgrade from DES to 
> AES. That's a one-bit switch, and obviously an important one. 
> AES is faster and more secure; DES is on the way out, and AES 
> is on the way in.
> 
> Now you seem to have in mind a much more complicated set of 
> options, and an unstated reason that it's important to have 
> all those options (but no others!). What's the reason? How do 
> you get from that reason to the exact list of options that 
> you have in mind?
> 
> Where can I find the archived analysis of how the exact list 
> of options was created? Are you sure that the options weren't 
> simply accreted by the typical ``Let's support every 
> conceivable option we can document'' committee-think, without 
> regard for actual costs and benefits?
> 
> ---D. J. Bernstein, Associate Professor, Department of 
> Mathematics, Statistics, and Computer Science, University of 
> Illinois at Chicago
> 
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/cfrg
> 

_______________________________________________
Cfrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/cfrg

---

From: Jeff Williams <[email-masked]>
Date: Sun, 07 Nov 2004 21:10:03 -0800

Phillip and all,

  I agree with you fully here.  Especially your last sentence below.
However as you likely already know that are still many within the
IETF that are not likely to agree with you here.  Some of which
are more adept at gamesmanship and who's knowledge base is
dated, that will fight your nicely and simply stated approach/method
of choice here..

Hallam-Baker, Phillip wrote:

> saag mailing list
> [email-masked]
> https://jis.mit.edu/mailman/listinfo/saag

Regards,
--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"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.
E-Mail [email-masked]
 Registered Email addr with the USPS
Contact Number: 214-244-4827

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Mon, 08 Nov 2004 08:05:13 -0500

In message <[email-masked].

>should be told to go home, shut up and not bother the grownups who do know

Phil -- please read RFC 3184.  You're welcome to propose technical 
idea, no matter how different than the norm (and no matter how much 
many people disagree with them).  You're not welcome to indulge in 
childish name-calling on IETF mailing lists.

		--Steve Bellovin
		Security AD

---

From: "Gary E. Miller" <[email-masked]>
Date: Mon, 8 Nov 2004 14:31:25 -0800 (PST)

Yo Phillip!

> Deployable, viable, simple, workable.

If you have access to the DNS sure.  What about all those zillions
of folks running on cable modems, DLS, etc. ??   What is you are behind
a NAT?  What if you do not want to tell the world what services you are
runing?

RGDS
GARY
- ---------------------------------------------------------------------------
Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701
	[email-masked]  Tel:+1(541)382-8588 Fax: +1(541)382-8676