IETF Logo Mail Archive

Re: [dnsext] Clarifying the mandatory algorithm rules

Jelte Jansen <jelte@isc.org> Fri, 19 November 2010 07:39 UTC

Return-Path: <jelte@isc.org>
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71C623A68B8 for <dnsext@core3.amsl.com>; Thu, 18 Nov 2010 23:39:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.734
X-Spam-Level:
X-Spam-Status: No, score=-99.734 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HELO_IS_SMALL6=0.556, HELO_MISMATCH_NL=1.448, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4Pv0BvWVPUi for <dnsext@core3.amsl.com>; Thu, 18 Nov 2010 23:39:47 -0800 (PST)
Received: from tjeb.nl (vps6121.xlshosting.net [178.18.82.80]) by core3.amsl.com (Postfix) with ESMTP id 6E0063A688C for <dnsext@ietf.org>; Thu, 18 Nov 2010 23:39:47 -0800 (PST)
Received: from [192.168.1.34] (host42-184-static.39-79-b.business.telecomitalia.it [79.39.184.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tjeb.nl (Postfix) with ESMTPSA id 8396124178; Fri, 19 Nov 2010 08:40:34 +0100 (CET)
Message-ID: <4CE629F1.2090907@isc.org>
Date: Fri, 19 Nov 2010 08:40:33 +0100
From: Jelte Jansen <jelte@isc.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Mark Andrews <marka@isc.org>
References: <alpine.BSF.2.00.1011180553250.83352@fledge.watson.org> <4CE53927.9090203@isc.org> <4CE58E90.6030607@nic.cz> <AANLkTin2H7UkP7FVfz3GN74CKtqn2OKo7MmcKMGOkvNY@mail.gmail.com> <4CE59B3D.5020109@nic.cz> <20101119004134.993F26EB749@drugs.dv.isc.org><AANLkTi=Hp6s4xwLQGyWv3BNtvUf5-SDtgUzHbNKtfCV1@mail.gmail.com> <20101119060416.024456F87CD@drugs.dv.isc.org>
In-Reply-To: <20101119060416.024456F87CD@drugs.dv.isc.org>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: dnsext@ietf.org
Subject: Re: [dnsext] Clarifying the mandatory algorithm rules
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Nov 2010 07:39:48 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/19/2010 07:04 AM, Mark Andrews wrote:
>>
>> Downgrade protection for algorithms is every bit as important as
>> downgrade to insecure.
>> Precisely because a broken algorithm *is* insecure, in fact.
> 
> If a algorithm is insecure then you should remove it from the list
> of acceptable algorithms in you validator.  That way you get insecure
> not trusted out of the validator.
> 

If you do that, and the zone(s) do 'normal' pre-publish rollover from
that broken algorithm to a not-yet-broken one, you'd get bogus, not
insecure, during the roll

Jelte

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzmKfAACgkQ4nZCKsdOncW3VgCbBru38ORTR8kIHICLy8wCW85i
mmMAoIL+pTNMD/z4loxAtK+bCmvvHcyo
=+8eb
-----END PGP SIGNATURE-----

v2.23.0 | Report a Bug | By Email