In article <[EMAIL PROTECTED]> you write:
>Hi, folks. The IESG has received a last call comment recommending
>that the new rc4 cipher for ssh be published as informational rather
>than as a proposed standard because of weaknesses in rc4. It would be
>inappropriate to make a decision based on one
In article <[EMAIL PROTECTED]> you write:
>On Wed, 1 Jun 2005, Keith Moore wrote:
>>> The argument in favor of publishing this document at proposed is that
>>> the existing arcfour cipher is part of a standard and that many other
>>> IETF protocols use rc4 in standards track documents.
>>
>> previo
In article <[EMAIL PROTECTED]> you write:
>On Wed, 2005-06-01 at 15:48, Sam Hartman wrote:
>
>> That's what I thought too. However that seems to be false. The one
>> reference currently in the security considerations section is for an
>> attack to distinguish an RC4 stream from a random stream.
this is a next step in removing support for 6 years of legacy
code in endsystems. given that some folks will not upgrade
without incentive, this document provides RIRs and others
with justification for terminating service for this legacy code.
i would much prefer carrots instead of sticks to mot
At 9:30 -0700 6/3/05, Bill Manning wrote:
this is a next step in removing support for 6 years of legacy
code in endsystems. given that some folks will not upgrade
without incentive, this document provides RIRs and others
with justification for terminating service for this legacy code.
i would m
The implementation report seems rather old and seems focused on the
existing document not on the draft actually being advanced. Can we
get people submitting entries for the implementation report to confirm
that they have been following the draft and believe their
implementations still comply wit
First, in section 5, please do not list cram-md5 as a secure
authentication technology. Today I think we'd require a security
layer from a SASL mechanism to consider it secure. Also cram-md5
suffers from other defects.
Also, I'm a bit concerned about the following requirement:
o Mail co
Sam,
> First, in section 5, please do not list cram-md5 as a secure
> authentication technology. Today I think we'd require a security
> layer from a SASL mechanism to consider it secure. Also cram-md5
> suffers from other defects.
1. You mean that MD5 is not a common, current practise tha
Dave Crocker wrote:
> 1. You mean that MD5 is not a common, current practise that
>provides a useful degree of security?
The SASL-registry says "limited" for CRAM-MD5 and "common" for
DIGEST-MD5, whatever that means. I know an MSA offering...
AUTH PLAIN LOGIN CRAM-MD5
...s/CRAM-MD5/OTP/ or
