[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Cfrg] Re: [saag] Algorithm upgrades
Phillip and all,
Hallam-Baker, Phillip wrote:
> > From: Jeff Williams [mailto:jwkckid1 at ix.netcom.com]
>
> > 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.
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...
>
>
> > 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: cfrg-bounces at ietf.org
> > [mailto:cfrg-bounces at ietf.org] On Behalf
> > > > Of D. J. Bernstein
> > > > Sent: Sunday, November 07, 2004 3:12 PM
> > > > To: saag at mit.edu; cfrg at ietf.org
> > > > 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
> > > > Cfrg at ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/cfrg
> > > >
> > > _______________________________________________
> > > saag mailing list
> > > saag at mit.edu
> > > 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
> > jwkckid1 at ix.netcom.com Registered Email addr with the USPS
> > Contact Number: 214-244-4827
> >
> >
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 jwkckid1 at ix.netcom.com
Registered Email addr with the USPS
Contact Number: 214-244-4827
_______________________________________________
Cfrg mailing list
Cfrg at ietf.org
https://www1.ietf.org/mailman/listinfo/cfrg