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

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

> From: Jeff Williams [mailto:[email-masked]] 

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

People can play what games they like in their personal playpen. But the real
world has ceased listening to them. I will be in DC next week, but not at
the IETF.

It has been obvious to me for eight years that the inability to upgrade
deployed protocols is the critical flaw of the IETF stack. The generally
agreed way to correct that problem from an architectural standpoint is
through a policy layer.

The only response I have ever got back is passive aggressive dismissals, oh
that's hard, needs lots of thought, too hard, problems you would not
understand, etc.

Then we have the, yes that's great, just stick my personal project into your
critical path types.

> Hallam-Baker, Phillip wrote:
> 
> > 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
> > >
> > _______________________________________________
> > 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
> 
> 

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

---

From: Jeff Williams <[email-masked]>
Date: Mon, 08 Nov 2004 02:09:15 -0800

Phillip and all,

> Then we have the, yes that's great, just stick my personal project into your

 Yes, I have gotten allot of the same kind of responses over the past
4-5 years or worse myself from many old timers in the IETF myself.
To me this shows a near total lack of consideration and willingness
to belly up to the bar as it were..  I believe that this has become a
systemic problem now and as Richard Clark had once indicated
some very radical and specific changes are needed in order to
adequately address this broad problem...

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