[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Last ditch proposal for crypto suites
> Indeed. I've got nothing against cipher suites but I'd like
> to see something in the document describing the procedure
> for registering new cipher suites. Not having such a procedure
> has been a substantial point of contention with TLS.
I think it was I who brought up the example of TLS at one of the IETFs. I
don't normally attend TLS meetings, but I happened to go that one time
(London?) when almost the entire session was devoted to ciphersuites.
Someone was trying to add the Camilla cipher (apparently it is essential for
penetration into the Japanese market), and at the same time there was a
proposal for adding the PFS variants and RSA I think as well. Each of these
entailed a full permutation of options.
I can't deny that there now appears to be widespread support for
ciphersuites, although perhaps for the wrong reasons(*). But I fear that we
are still riding that initial wave of exuberance that comes with agreeing to
agree, while the dirty work of actually agreeing lingers in the background.
Phill somewhat naively suggested that we could get away with 3 suites:
> >1: RSA/3DES-CBC/SHA-1
> >2: RSA/AES-CTR-128/SHA-2
> >3: RSA/AES-CTR-256/SHA-2
These choices display one particular view on the progression of suites, but
the problem is that you could ask this question to 10 people and get 10
different replies. Most of this WG seems to be anti-SHA-2, and some of the
64-bit people are anti-SHA-1. Then there are those who think Rijndael is
insecure and we should use 3DES (or one of the other finalists), and a lot
of people who don't think AES-256 is necessary. Those of us who do remote
access would argue that IPCOMP is necessary for all permutations. These
examples also conspicuously omit pre-shared keys, NULL-encryption, AH, PFS,
PRFs, MACs and DH in general.
(*) Almost all of the arguments presented for suites dealt with the
conceptual issue of suites vs. ala carte. In fact, no one ever denied that
suites are a good idea. The issue was whether to do GUI suites or suites at
the protocol layer. Very few of the comments on this list dealt with the
issue of whether the cost of comparing a list of attributes was worth the
benefit.
Since DH is now negotiated via abort & retry, it is actually not absolutely
necessary to specify the DH group in the wire protocol specification of the
suite, but since the suite is actually two things (a GUI concept and an
on-the-wire format), for the sake of interoperability it is desirable to
specify the DH group within the suite. This is likely to be a huge bone of
contention, especially considering the ECC vs. MODP issue.
My argument for GUI suites rather than suites at a protocol level is
entirely political and has nothing to do with technical merit. I find it
doubtful that we will be able to agree on a small set of suites that
everyone agrees on. The IANA considerations for adding new suites will no
doubt require a standards track RFC. I have some reservations about this
process, mainly motivated by the fact that it takes around 3 years for a
draft to reach RFC status in this WG. That's why I was advocating a
hierarchical textual namespace rather than an IANA assigned numberspace.
Andrew
-------------------------------------------
There are no rules, only regulations. Luckily,
history has shown that with time, hard work,
and lots of love, anyone can be a technocrat.
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Eric Rescorla
> Sent: Friday, August 30, 2002 1:29 PM
> To: The Purple Streak, Hilarie Orman
> Cc: ipsec@lists.tislabs.com
> Subject: Re: Last ditch proposal for crypto suites
>
>
> "The Purple Streak, Hilarie Orman" <ho@alum.mit.edu> writes:
>
> > I think the original argument against suites came from observing how
> > many SSL had.
>
> Indeed. I've got nothing against cipher suites but I'd like
> to see something in the document describing the procedure
> for registering new cipher suites. Not having such a procedure
> has been a substantial point of contention with TLS.
>
> -Ekr
>
>
> --
> [Eric Rescorla ekr@rtfm.com]
> http://www.rtfm.com/
>