IETF Logo Mail Archive

Re: [DNSOP] on staleness of code points and code (mentions MD5 commentary from IETF98)

Jan Včelák <jv@fcelda.cz> Tue, 28 March 2017 11:47 UTC

Return-Path: <jv@fcelda.cz>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC991299C4 for <dnsop@ietfa.amsl.com>; Tue, 28 Mar 2017 04:47:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fcelda.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmRMJQeGc9h2 for <dnsop@ietfa.amsl.com>; Tue, 28 Mar 2017 04:47:00 -0700 (PDT)
Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 329DD1299AF for <dnsop@ietf.org>; Tue, 28 Mar 2017 04:46:58 -0700 (PDT)
Received: by mail-vk0-x236.google.com with SMTP id s68so84515863vke.3 for <dnsop@ietf.org>; Tue, 28 Mar 2017 04:46:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fcelda.cz; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=v7UU4Kbp0dk5ORuPKOvqXrGVL6CPlcX6yvqkZsLp70g=; b=N+D0fvpe4vJWS7f8W3MnElOaolOptpCvVkGw5yb0hTOsibSsa1PEoNoLSuldjZCjQu mbLqPqkxVI5My1KDhwfuRXDfDEfgtDukXbRjtbwjNzX/QNPfmzrct0/9rw8+4rT5LdnA d5q4apMyFlFwpLUzg1Gc2ynqajKqyFx2o/m7Y=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=v7UU4Kbp0dk5ORuPKOvqXrGVL6CPlcX6yvqkZsLp70g=; b=eo6QOHgTdxqF8nTrGZW/hG0bna4n8FiqEA7Zo/8HmHz5j7xdRXknyZE6kOICJmY2Gs owtFUXClpwe68lIOC4kuYQydFlBLzSNbjxdpKdNDON43VdXgah/KtqStA86Lh6iUwwIR 0yPDZQOuESEcBkdbW5SfblHKfXR3cGr3eA4r06SlsnCpaJfv66INypSEaKrnBHFAXmqD gTdP9BBhPxC4myN2apr24qZO/S3oPjJzhqj0Zag5v3ca/jG7euGTR68qAH/qvJx405zq s48JqATKWHg9/1MwnqxssRVeXvtFL7YOeK7jC0jPbTqEcEf1cty20jZlB+NTeYxghdPY mCcw==
X-Gm-Message-State: AFeK/H12r7yoayZ8mqvG7RU2AOI/m+9W803jDTjl7Qfsq8enK33Mmo/XIvz9SGd2JmkatxgP7FRItdoqSdrGnw==
X-Received: by 10.31.120.8 with SMTP id t8mr12063854vkc.150.1490701617078; Tue, 28 Mar 2017 04:46:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.29.65 with HTTP; Tue, 28 Mar 2017 04:46:36 -0700 (PDT)
X-Originating-IP: [5.56.197.188]
In-Reply-To: <20170328024127.GC96991@isc.org>
References: <58D96BC0.9040701@redbarn.org> <20170328024127.GC96991@isc.org>
From: Jan Včelák <jv@fcelda.cz>
Date: Tue, 28 Mar 2017 13:46:36 +0200
Message-ID: <CAM1xaJ-gCKqm63BuNszLxyt0_HevXSwB5H0+wg4ugatZSFJNPA@mail.gmail.com>
To: Evan Hunt <each@isc.org>
Cc: Paul Vixie <paul@redbarn.org>, "dnsop@ietf.org" <dnsop@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/EZfVS44DXwz8fdddF8tmyGixVXM>
Subject: Re: [DNSOP] on staleness of code points and code (mentions MD5 commentary from IETF98)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Mar 2017 11:47:02 -0000

On Tue, Mar 28, 2017 at 4:41 AM, Evan Hunt wrote:
> We can and should kill MD5 key generation and signing (and I'll add this to
> the ticket about updating defaults in BIND) but I'm uncomfortable killing
> MD5 validation until I'm sure there aren't any legacy keys floating around.

Short history of MD5 in DNSSEC:

1999: RFC 2535 makes MD5 recommended for DNSSEC
2001: RFC 3110 makes MD5 not recommended for DNSSEC
2004: RFC 3755 disallows MD5 for zone signing
2005: RFC 4034 reassures that MD5 is not recommended and must not be
used for zone signing

DNS software that supports MD5 for zone signing in 2017 belongs to
museum. It's too late for arguments about keeping it for legacy
reasons. I agree that modern validators should treat MD5 as unknown
algorithm.

Jan

v2.23.0 | Report a Bug | By Email