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

["Hallam-Baker, Phillip" <pbaker at verisign.com>]

I agree with Paul's analysis of the problem, if not the solution.

IPSEC is a miserable, miserable protocol to use. It only works in many cases
because of ad hoc infrastructure allowances that are outside the
specification.

It is certainly no occasion for a victory dance. If I was going to design a
VPN from scratch I would simply tunnel over SSL and completely ignore the
IPSEC stack. IPSEC is useless to me unless it works in the hotel I am
staying in. SSL works through NAT reliably. IPSEC does not.

People need to decide whether the purpose of the protocol design is to meet
the real needs of users or to amuse ourselves. 




> -----Original Message-----
> From: saag-bounces at mit.edu [mailto:saag-bounces at mit.edu] On 
> Behalf Of Paul Hoffman / IMC
> Sent: Saturday, November 06, 2004 10:48 AM
> To: D. J. Bernstein; saag at mit.edu; cfrg at ietf.org
> Subject: Re: [Cfrg] Re: [saag] Algorithm upgrades
> 
> 
> At 8:55 AM +0000 11/6/04, D. J. Bernstein wrote:
> >Was it impossible to encode a DES-vs.-AES
> >bit for IPSec into one of those numbers?
> 
> No, it was not. And we arguably should have done so. At the risk of 
> causing my brain to explode, I will agree with Dan and disagree with 
> Bill and Ran here.
> 
> Statements like "not really noticeable" and "work well operationally" 
> are absurdly out of touch with typical IPsec VPN users. Even the best 
> UIs for gateways force low-ability admins and lower-ability end users 
> to make multiple selections of things that they don't (and shouldn't 
> need to!) understand.
> 
> The IPsec WG has recently agreed to two "UI suites" for sets of 
> algorithms that we think make sense for the vast majority of users. 
> These UI suites don't prevent fine-grained negotiation of crypto 
> details, but they allow vendors to have one or two buttons, plus an 
> optional third that says "advanced users: get lots more choices here".
> 
> If we knew we would come this this point when IKEv1 was developed, it 
> would make imminent sense to allocate three port numbers to it: one 
> for button A, one for button B, and one for fine-grained 
> negotiations. It is arguable that we should have done that for IKEv2; 
> no one suggested it, but in hindsight it seems quite reasonable.
> 
> Pre-defined suites *are* TCP port-level choices. A responding system 
> that can only do Suite A can announce that simply by listening on 
> that port, and the initiator knows their capability. Systems that 
> also want negotiation can.
> 
> The scarcity of port numbers is over-rated relative to having simpler 
> and more robust security protocols.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium 
> _______________________________________________
> saag mailing list
> saag at mit.edu
> https://jis.mit.edu/mailman/listinfo/saag
> 

_______________________________________________
Cfrg mailing list
Cfrg at ietf.org
https://www1.ietf.org/mailman/listinfo/cfrg