I wrote:
>> As I recall, however, the TLSv.1 Internet-Draft mischeviously cited
>> -- as its cannonical RC4 reference -- one of the several Apparently RC4
>> (ARC-4) clones.
Rich Salz <[EMAIL PROTECTED]> noted:
>I believe they did this with the advice/suggestion/concerrence of Rivest.
Didn't know that, but it doesn't surprise me. He's a cool guy who
keeps his work and himself in perspective. Doesn't act at all like a
National Treasure on the hoof, which is what he would be considered anywhere
else;-)
Where I wrote:
>> Despite the demand for RC4's relative efficiency, however, I think
>> the IETF's TLS WG was uncomfortable with the idea of pairing a free
>> key-agreement/signature mechanism with a proprietary (copyright, if not
>> trade secret) RC4 cipher. I think they fudged it by referencing the
>> non-Rivest ARC-4 source, but still labelling the new TLS ciphersuites as
>> including "RC4."
Eric Rescorla <[EMAIL PROTECTED]> noted:
Ekr> I don't believe this was the case. The original SSLv3 drafts
Ekr> did not have DH/DSS/RC4 support. TLSv1 continued this.
Ekr> The evidence that this was simply a glitch is that
Ekr> DH_anon _was_ defined with RC4.
I had in mind the debate you had with Dave Wagner, David Neuman,
and Adam Black, among others, about including RC4 in an expanded TLSv.1
list of 56-bit "export" ciphersuites, after John Barnes from Microsoft told
the TLS working group that MS was going to extend the Win2K/IE ciphersuites
with RSA_1024 combinations that used RC2-56, RC4-56, and DES -- but
DH_DSS_1024 only with DES.
I had the distinct impression that some people felt strongly that
proprietary (or somewhat-proprietary) symmetric cryptosystems should not be
used where they were not absolutely required for backwards compatability
with SSLv.3, but that others -- you notably -- pushed both the WG and
Microsoft to include RC4 and a full array of DH_DSS combinations.
Hmmm. I just pulled up the archives of the TLS WG discussions in
February <http://www.imc.org/ietf-tls/mail-archive/threads.html#01705>, and
I see that it was you -- while expressing skepticism about whether Rivest or
RSA still had any IP in RC4 -- who noted the availability of the ARC4 clones
as a way of sidestepping the issue;-)
I note also that John Barnes, speaking for MS, clearly had no
intention, and no apparent interest, in adding DH_DSS_RC4 to the Win2k/IE
ciphersuites until you guys convinced him it was important. You challenged
Barnes:
/>Is there some rationale for NOT including DHE/RC4 cipher suites?
/>
/>If DSS/DHE is the preferred key management technique (as making
/>it mandatory strongly suggests) then shouldn't it support the
/>widest possible range of ciphers?
You presented the case for DH_DSS_RC4 so forcefully that, by the end
of the discussion, John was changing the MS spec to add DH_DSS_1024 with
DES, RC4-56, and *RC4-128* (as well as RSA_1024 with DES and RC4-56.)
(I don't know what happened in the WG or IESG afterwards -- but as I
read that thread in the TLS archives, it seems to settle on a WG consensus
that the TLSv.1 spec would be expanded to match the new ciphersuites that MS
intends to bring to market in IE and Win2K.)
I wrote:
>>> It might also be fairly said that an "RC7" cryptosystem from
>>>someone other than Ron Rivest would confuse and mislead the consumers
>>>and OEMs who have come to expect the elegant simplicity, ingenious
>>>complexity, and durable security we've seen in Prof. Rivest's RC2, RC4,
>>>RC5, and RC6. (And that, I think, about sums up the business case which
>>> justifies a commercial trademark in any country in the world.)
Greg Broiles <[EMAIL PROTECTED]> corrected my earlier misleading
reference to a RC copyright -- as opposed to than an RC trademark -- but
noted that my little epiphany about the RC cryptosystems:
GB> [...] seems to muddy the waters regarding the trademark status of
GB> the "RC" prefix. Trademarks identify to consumers a unique source of
GB> goods or services. To the extent that "RC<number>" identifies Ron Rivest
GB> as the source of an algorithm or a scrap of code, it's not an RSAS
GB> trademark, it's a Ron Rivest trademark.
I'm too much of an fan of your posts on crypto and the Law to argue,
but I'm not sure it makes much difference in this case.
I'm also conscious that validating an algorithm's design and
exploring its mathematical depths is often much more of a team effort than I
had expected it to be (while writing a crypto library is usually much more
of a one or two-man job than I had expected) -- and that, over the years,
Ron Rivest has often worked closely with some very impressive colleagues at
RSA Labs.
GB> I agree with your conclusions above from a moral perspective - anyone
GB> else who used the "RC" prefix for a crypto algorithm would look like a jerk,
GB> as would someone who appropriated, say, the "eay" suffix without the
GB> cooperation or permission of Eric Young. But I'm not sure that, in a
GB> stricter legal sense, either term has been closely correlated enough with a
GB> unique source of goods or services to serve as a protectible mark.
If you doubt it, I dunno myself -- although I had thought there was.
Guess we'll have to wait and see what happens if Ron or RSAS feel they have
to defend the "RC" mark against some jerk with the gall to misappropriate it;-)
Thanks, everyone, for the comments and corrections.
Suerte,
_Vin
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
