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

From: "Hughes, James P" <[email-masked]>
Date: Fri, 5 Nov 2004 15:30:58 -0700

I agree. My company loves these "policy knobs". Without this kind of
negotiation in the standard, vendors will do it themselves in an
incompatible proprietary way making the standard less valuable. 

-----Original Message-----
From: [email-masked] <[email-masked]>
To: D. J. Bernstein <[email-masked]>
CC: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Sent: Fri Nov 05 14:54:20 2004
Subject: Re: [Cfrg] Re: [saag] Algorithm upgrades

On Fri, 2004-11-05 at 15:18, D. J. Bernstein wrote:
> > Can you explain how we would have handled the conversion from
> > DES to AES for IPSec in an alternate universe where all the protocols
> > worked as you desire?
> 
> May I ask how the conversion worked in your universe, and exactly what
> conversion costs were avoided by the negotiation mechanism?

In our universe, we configured IPsec security gateways to accept both
AES and 3DES, then incrementally changed the preferred algorithm of the
clients. 

The conversion cost avoided was the need for a "flag day" during which
all clients needed to be changed simultaneously.

						- Bill

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

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

---

From: "D. J. Bernstein" <[email-masked]>
Date: 6 Nov 2004 08:55:56 -0000

> AES and 3DES, then incrementally changed the preferred algorithm of the

I was able to incrementally switch clients from telnet to ssh, where the
server supported both telnet and ssh. The client indicated its protocol
selection through its choice of TCP port number.

We already have many levels of protocol selection: IP protocol numbers,
TCP port numbers, and more. Was it impossible to encode a DES-vs.-AES
bit for IPSec into one of those numbers?

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

---

From: RJ Atkinson <[email-masked]>
Date: Sat, 6 Nov 2004 06:46:12 -0500

> bit for IPSec into one of those numbers?

	It would be remarkably bad protocol design to burn an additional
port number just to indicate an algorithm difference.  And, as others
have been kind enough to describe here, better ways to incrementally
upgrade IPsec clients are already supported and work well operationally.

	I really prefer the universe described by Bill Sommerfeld.

Cheers,

Ran Atkinson
[email-masked]

---

From: "D. J. Bernstein" <[email-masked]>
Date: 6 Nov 2004 19:12:54 -0000

RJ Atkinson writes:
> port number just to indicate an algorithm difference.

Why?

An obvious advantage of putting ssh on a separate port from telnet is
that---since UNIX makes it easy to have separate programs for separate
ports---sshd was easier to write, and telnetd was easier to turn off.
If they had been on the same port, with the ssh encryption as a telnet
option, then implementors would have had fewer options.

Similarly, it has been helpful to put mail submission on a separate port
from SMTP, and it has been helpful to put HTTP on a separate port from
FTP, and it would have been extremely helpful to put DNS caches on a
separate port from DNS servers. What's the disadvantage?

I don't claim that UNIX has the same modularity for handling separate
IPSecDES and IPSecAES protocols, but I still don't see what you think
the disadvantage is. Do you think we're running out of IP protocol
numbers? Were you also saying that the use of both 50 and 51 for IPSec
(and UDP port 500) was ``remarkably bad protocol design''?

---

From: Jari Arkko <[email-masked]>
Date: Sun, 07 Nov 2004 16:52:42 +0200

Eric Rescorla wrote:

>>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.
> 
> Maybe so, but why blame algorithm negotiation for this? Both SSH 
> and TLS have algorithm negotiation and in practice noone even
> notices. 

I agree that the algorithm negotiation is not the reason.
If you look at the difference between the SSL and IPsec
models, I think the difficulties come from two areas:

o  Separation of the application and the security layer. In
    SSL, applications are in direct control of the security
    layer and the configuration of the security layer also
    goes through the application's user interface. Given
    that the application knows its security requirements
    and its traffic flows, it knows what traffic needs to
    be protected and how. So you can skip, for instance,
    port number and address pattern specifications. Personally,
    I like entering IPv6 addresses in hex to configuration
    files, but I'm not quite sure most people on the planet
    agree with me.

o  Harder requirements. For instance, IPsec applications
    typically require all parties to be provisioned with
    keys and configuration, whereas in SSL some applications
    work with just server-side keys.

--Jari

---

From: "D. J. Bernstein" <[email-masked]>
Date: 7 Nov 2004 20:11:58 -0000

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?

---

From: Bill Sommerfeld <[email-masked]>
Date: Sat, 06 Nov 2004 07:39:05 -0500

> selection through its choice of TCP port number.

and then, perhaps unknown to you, ssh and sshd negotiated about a half
dozen algorithm parameters, each of which would require a bit or two to
encode even using the most compact encoding...

> bit for IPSec into one of those numbers?

in a word, yes, because 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.

					- Bill

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sat, 6 Nov 2004 10:48:06 -0500

At 8:55 AM +0000 11/6/04, D. J. Bernstein wrote:
>Was it impossible to encode a DES-vs.-AES

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.

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