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

[Paul Hoffman / IMC <phoffman at imc.org>]

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

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