Re: [ietf-dkim] draft-ietf-dkim-threats-02 nit//Permitted and preferred algorithms.

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 06 April 2006 19:30 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRaBy-0003D3-2I for ietf-dkim-archive@lists.ietf.org; Thu, 06 Apr 2006 15:30:54 -0400
Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRaBx-0004Sp-M9 for ietf-dkim-archive@lists.ietf.org; Thu, 06 Apr 2006 15:30:54 -0400
Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k36JEZYE028790; Thu, 6 Apr 2006 12:14:36 -0700
Received: from relay.imagine.ie (dns2.dns.imagine.ie [87.232.1.41]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k36JEPkF028719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-dkim@mipassoc.org>; Thu, 6 Apr 2006 12:14:26 -0700
Received: from mail2.int.imagine.ie (mail2 [87.232.1.153]) by relay.imagine.ie (Postfix) with ESMTP id B9D974068; Thu, 6 Apr 2006 20:13:48 +0100 (IST)
Received: from [127.0.0.1] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by mail2.int.imagine.ie (8.13.4/8.13.4/Debian-3) with ESMTP id k36JDieO007349; Thu, 6 Apr 2006 20:13:46 +0100
Message-ID: <44356870.8080808@cs.tcd.ie>
Date: Thu, 06 Apr 2006 20:13:52 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Douglas Otis <dotis@mail-abuse.org>
Subject: Re: [ietf-dkim] draft-ietf-dkim-threats-02 nit//Permitted and preferred algorithms.
References: <57DB790B-C4AF-4A30-846F-36BA3A07A356@mail-abuse.org>
In-Reply-To: <57DB790B-C4AF-4A30-846F-36BA3A07A356@mail-abuse.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Bayes-Prob: 0.0001 (Score 0)
X-Spam-Score: 0.00 () [Hold at 8.00]
X-Canit-Stats-ID: 780349 - e5858eb66ceb (trained as not-spam)
X-CanItPRO-Stream: outgoing
X-Scanned-By: CanIt (www . roaringpenguin . com) on 87.232.1.53
X-Songbird: Clean, Clean
Cc: IETF-DKIM <ietf-dkim@mipassoc.org>
X-BeenThere: ietf-dkim@mipassoc.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF DKIM Discussion List <ietf-dkim.mipassoc.org>
List-Unsubscribe: <http://mipassoc.org/mailman/listinfo/ietf-dkim>, <mailto:ietf-dkim-request@mipassoc.org?subject=unsubscribe>
List-Archive: <http://mipassoc.org/pipermail/ietf-dkim>
List-Post: <mailto:ietf-dkim@mipassoc.org>
List-Help: <mailto:ietf-dkim-request@mipassoc.org?subject=help>
List-Subscribe: <http://mipassoc.org/mailman/listinfo/ietf-dkim>, <mailto:ietf-dkim-request@mipassoc.org?subject=subscribe>
Sender: ietf-dkim-bounces@mipassoc.org
Errors-To: ietf-dkim-bounces@mipassoc.org
X-SongbirdInformation: support@songbird.com for more information
X-Songbird-From: ietf-dkim-bounces@mipassoc.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3

Doug,

We're done with that document. We had the WG last call.
Its finished. Unless something REALLY BIG turns up, but
that's always true.

*If* the document editor wants to make innocuous changes
during AUTH-48, that'd be ok. I'll leave it to Jim to
figure if this is one such or not. These are not IMO
REALLY BIG issues.

For the rest of us - let's get on to discussing the base
draft (unless someone wants to be left behind haggling
over threats wordsmithing:-)

Regards,
Stephen.

PS: Same response to the mails sent to ietf-discuss!

Douglas Otis wrote:
> 
> ,---
> | 4.1.14.  Cryptographic Weaknesses in Signature Generation
> |
> | The message signature system must be designed to support multiple
> | signature and hash algorithms, and the signing domain must be able to
> | specify which algorithms it uses to sign messages.  The choice of
> | algorithms must be published in key records, rather than in the
> | signature itself, to ensure that an attacker is not able to create
> | signatures using algorithms weaker than the domain wishes to permit.
> '___
> 
> This leaves out the "bid-down" concern.
> 
> Change to:
> 
> : The message signature system must be designed to support multiple
> : signature and hash algorithms, and the signing domain must be able to
> : specify which algorithms it uses to sign messages.  The choice of
> : algorithms as well as the preferred algorithm offered when multiple
> : signatures are added to a message must be published in key records,
> : rather than in the just the signature itself, to ensure that an
> : attacker is not able to create signatures using algorithms weaker than
> : the domain prefers or wishes to permit.
> 
> -Doug
> _______________________________________________
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html
> 

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html