headers
David A. McGrew | 1 Jun 2005 23:41
Picon
Favicon

Fwd: [saag] [Sam Hartman] draft-harris-ssh-arcfour-fixes-02: informational or proposed?

FYI.

Begin forwarded message:

> From: Sam Hartman <hartmans-ietf <at> mit.edu>
> Date: June 1, 2005 12:04:07 PM PDT
> To: ietf-ssh <at> netbsd.org, saag <at> mit.edu
> Subject: [saag] [Sam Hartman] draft-harris-ssh-arcfour-fixes-02: 
> informational or proposed?
> Reply-To: ietf <at> ietf.org
>
>
>
> Hi.  I believe the following request is of interest to secsh and saag.
>
>
> From: Sam Hartman <hartmans-ietf <at> mmit.edu.cnri.reston.va.us>
> Date: June 1, 2005 11:35:07 AM PDT
> To: ietf <at> ietf.org
> Cc: iesg <at> ietf.org
> Subject: draft-harris-ssh-arcfour-fixes-02: informational or proposed?
>
>
>
>
> 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 comment so I am
> soliciting comments on this point.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Greg Rose | 1 Jun 2005 23:49

Re: Fwd: [saag] [Sam Hartman] draft-harris-ssh-arcfour-fixes-02: informational or proposed?

I am strongly of the opinion that RC4 should be deprecated, therefore that 
this RFC shouldn't be published *at all*. Certainly not as a proposed standard.

Greg.

At 14:41 2005-06-01 -0700, David A. McGrew wrote:
>FYI.
>
>Begin forwarded message:
>
>>From: Sam Hartman <hartmans-ietf <at> mit.edu>
>>Date: June 1, 2005 12:04:07 PM PDT
>>To: ietf-ssh <at> netbsd.org, saag <at> mit.edu
>>Subject: [saag] [Sam Hartman] draft-harris-ssh-arcfour-fixes-02: 
>>informational or proposed?
>>Reply-To: ietf <at> ietf.org
>>
>>
>>
>>Hi.  I believe the following request is of interest to secsh and saag.
>>
>>
>>From: Sam Hartman <hartmans-ietf <at> mmit.edu.cnri.reston.va.us>
>>Date: June 1, 2005 11:35:07 AM PDT
>>To: ietf <at> ietf.org
>>Cc: iesg <at> ietf.org
>>Subject: draft-harris-ssh-arcfour-fixes-02: informational or proposed?
>>
>>
>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Blumenthal, Uri | 1 Jun 2005 23:56
Picon
Favicon

RE: Fwd: [saag] [Sam Hartman]draft-harris-ssh-arcfour-fixes-02: informational or proposed?

I support Greg's position. 

-----Original Message-----
From: cfrg-bounces <at> ietf.org [mailto:cfrg-bounces <at> ietf.org] On Behalf Of
Greg Rose
Sent: Wednesday, June 01, 2005 5:49 PM
To: David A. McGrew
Cc: 'cfrg <at> ietf.org'
Subject: Re: [Cfrg] Fwd: [saag] [Sam
Hartman]draft-harris-ssh-arcfour-fixes-02: informational or proposed?

I am strongly of the opinion that RC4 should be deprecated, therefore
that 
this RFC shouldn't be published *at all*. Certainly not as a proposed
standard.

Greg.

At 14:41 2005-06-01 -0700, David A. McGrew wrote:
>FYI.
>
>Begin forwarded message:
>
>>From: Sam Hartman <hartmans-ietf <at> mit.edu>
>>Date: June 1, 2005 12:04:07 PM PDT
>>To: ietf-ssh <at> netbsd.org, saag <at> mit.edu
>>Subject: [saag] [Sam Hartman] draft-harris-ssh-arcfour-fixes-02: 
>>informational or proposed?
>>Reply-To: ietf <at> ietf.org
>>
(Continue reading)

Permalink | Reply | 501 comments |
headers
Peter Gutmann | 2 Jun 2005 09:47
Picon
Picon
Picon
Favicon

RE: Fwd: [saag] [Sam Hartman]draft-harris-ssh-arcfour-fixes-02: informational or proposed?

"Blumenthal, Uri" <uri.blumenthal <at> intel.com> writes:

>I support Greg's position.

<AOL>Me too</AOL>.  Or at best it should be published with a strong disclaimer
that it's only for legacy purposes and shouldn't be used in any new apps.  I
realise it's used in various IETF standards, but only for legacy reasons, the
weaknesses should really be addressed by dropping it, not with turd-polishing.

Peter.
Permalink | Reply | 501 comments |
headers
Russ Housley | 2 Jun 2005 23:20

Hash BoF

This is a brief note to let the members of the CFRG know about the Hash BoF 
that will take place in Paris at IETF 63.  We have a mailing list, and we 
respectfully ask for people to join that lsit for any discussion.

Thanks,
   Russ Housley
   IETF Security Area Director

= = = = = = = = = =

One-way Hash Function BoF (hash)

Security Area Director:
      Sam Hartman <hartmans-ietf <at> mit.edu>
      Russ Housley <housley <at> vigilsec.com>

Security Area Advisor:
      Russ Housley <housley <at> vigilsec.com>

Mailing Lists:
      General Discussion: hash <at> ietf.org
      To Subscribe:       https://www1.ietf.org/mailman/listinfo/hash
      Archive:            http://www.ietf.org/mail-archive/web/hash/index.html

Description of Proposed Working Group:

Recently, a team of researchers reported that the SHA-1 one-way hash
function offers significantly less collision resistance than could be
expected from a cryptographic hash function with an output of 160 bits.
This result has inspired significant research activities in government
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Wilkinson | 3 Jun 2005 01:51
Picon

Re: new i-d: randomized hashing

Hugo, thank you for the link, I read your draft with great interest.  
My only contribution, minor though it is, is to point out that in  
section 3.1, you refer to an "integrated hash function a-la-Merkle- 
Damgard", when I believe you meant an "iterated hash function".

Regards,
John

On May 30, 2005, at 12:00 AM, Hugo Krawczyk wrote:

> Shai Halevi and I wrote an internet draft on the subject of randomized
> hashing and its use for strengthening current and future hash  
> functions in
> the context of digital signatures.
>
> The draft can be downloaded from
> http://www.ietf.org/internet-drafts/draft-irtf-cfrg-rhash-00.txt
>
> Our proposal is to define a "mode-of-operation" for hash functions
> by which any hash function (existing or yet-to-be-designed) is  
> converted
> into a randomized hash that, when used appropriately with digital
> signatures, is plaussible to make the life of a forger much harder.
> In particular, simple deterministic collisions (as recent  
> cryptanalysis
> helps finding) are not enough to attack a signature scheme using a
> randomized hashing algorithm. This application of randomized  
> hashing is
> well-known in the literature (where such families of hash functions  
> are
(Continue reading)

Permalink | Reply | 1 comment |
headers
Hugo Krawczyk | 3 Jun 2005 21:31
Picon

Re: new i-d: randomized hashing

You are certainly right about the typo, thanks.

In light of Russ posting about a hashing BoF at the Paris meeting,
it would be helpful to have opinions of people about the
randomized hashing approach and its use in digital signature
applications  as discussed in the draft. In particular, whether
this group feels that a standardization effort in this direction
is worth pursuing (deciding on the exact mechanisms seems
less important at this point).

Hugo

On Thu, 2 Jun 2005, John Wilkinson wrote:

> Hugo, thank you for the link, I read your draft with great interest.
> My only contribution, minor though it is, is to point out that in
> section 3.1, you refer to an "integrated hash function a-la-Merkle-
> Damgard", when I believe you meant an "iterated hash function".
>
> Regards,
> John
>
Permalink | Reply | 0 comments |
headers
David Wagner | 6 Jun 2005 08:40
Picon

Re: new i-d: randomized hashing

Hugo Krawczyk  wrote:
>Shai Halevi and I wrote an internet draft on the subject of randomized
>hashing and its use for strengthening current and future hash functions in
>the context of digital signatures.

I think this is great stuff, and very much worth pursuing further.
Providing advice on which TCR constructions to use and how to use them
seems like a good service to the IETF, and I think the draft you and Shai
have put together is an excellent starting point.

Maybe one topic that might be worth discussing is which constructions
are most worthy of consideration, perhaps on grounds of both security and
performance.
Permalink | Reply | 0 comments |
headers
David A. McGrew | 6 Jun 2005 14:49
Picon
Favicon

Fwd: [saag] Hash BoF

> From: Russ Housley <housley <at> vigilsec.com>
> Date: June 3, 2005 1:33:51 PM PDT
> To: saag <at> mit.edu
> Subject: [saag] Hash BoF
>
> This is a brief note to let the members of the SAAG mail list know 
> about the Hash BoF that will take place in Paris at IETF 63.  We have 
> a mailing list, and we respectfully ask for people to join that list 
> for any discussion.
>
> I have attached the proposed charter for the Hash WG.
>
> Thanks,
>   Russ Housley
>   IETF Security Area Director
>
> = = = = = = = = = =
>
> One-way Hash Function BoF (hash)
>
> Security Area Director:
>      Sam Hartman <hartmans-ietf <at> mit.edu>
>      Russ Housley <housley <at> vigilsec.com>
>
> Security Area Advisor:
>      Russ Housley <housley <at> vigilsec.com>
>
> Mailing Lists:
>      General Discussion: hash <at> ietf.org
>      To Subscribe:       https://www1.ietf.org/mailman/listinfo/hash
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ben Laurie | 7 Jun 2005 15:53
Picon

Re: new i-d: randomized hashing

Hugo Krawczyk wrote:
> Shai Halevi and I wrote an internet draft on the subject of randomized
> hashing and its use for strengthening current and future hash functions in
> the context of digital signatures.
> 
> The draft can be downloaded from
> http://www.ietf.org/internet-drafts/draft-irtf-cfrg-rhash-00.txt

It seems to me that life would be generally easier if you defined a 
modified hash function H_r(m) and then constructed H'(m)=(r,H_r(m)). 
This way transport of r happens automatically, but the hash gets wider. 
This means that protocols will normally only need to be modified (if at 
all) to cope with the wider hash.

What's unfortunate is that it isn't going to be generally possible to 
make software changes that are equally simple, since the usual mode for 
verifying a hash is to do the hash again and compare the result.

Cheers,

Ben.

--

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Permalink | Reply | 8 comments |

Gmane