Re: [DNSOP] Whiskey Tango Foxtrot on key lengths...

Jelte Jansen <jelte.jansen@sidn.nl> Tue, 01 April 2014 13:53 UTC

Return-Path: <Jelte.Jansen@sidn.nl>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB601A06BE for <dnsop@ietfa.amsl.com>; Tue, 1 Apr 2014 06:53:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.084
X-Spam-Level:
X-Spam-Status: No, score=0.084 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 PIDkBQEVryt5 for <dnsop@ietfa.amsl.com>; Tue, 1 Apr 2014 06:53:03 -0700 (PDT)
Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) by ietfa.amsl.com (Postfix) with ESMTP id 552AD1A06FF for <dnsop@ietf.org>; Tue, 1 Apr 2014 06:53:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn_nl; c=relaxed/relaxed; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding:x-originating-ip; bh=pjqMgbsF3mZ1Cjzd6Yx62s2uaEsZxiXrH7OsBhcqIOI=; b=JsMAzOXrqlUvAJrU5jfhPS7YQPo2HZELtbJIjIviy2y0IB1FdtcNVR4cJQFoMsxXg9N+R5It75Eyk+G8zbQT/s8dgRWZjzocXaU4LciIRfkhv1ONk7X9pUv0DLszSA23YoX+g96CXBRYccDmmk61Rzhj85cEEbQxSWu976cJ5is=
Received: from kahubcasn01.SIDN.local ([192.168.2.73]) by arn2-kamx.sidn.nl with ESMTP id s31Dqqfu023073-s31Dqqfw023073 (version=TLSv1.0 cipher=AES128-SHA bits=128 verify=CAFAIL); Tue, 1 Apr 2014 15:52:52 +0200
Received: from [94.198.152.218] (94.198.152.218) by kahubcasn01.SIDN.local (192.168.2.77) with Microsoft SMTP Server (TLS) id 14.3.174.1; Tue, 1 Apr 2014 15:52:49 +0200
Message-ID: <533AC49C.6040705@sidn.nl>
Date: Tue, 01 Apr 2014 15:52:28 +0200
From: Jelte Jansen <jelte.jansen@sidn.nl>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.3.0
MIME-Version: 1.0
To: Phillip Hallam-Baker <hallam@gmail.com>, Nicholas Weaver <nweaver@icsi.berkeley.edu>
References: <0EA28BE8-E872-46BA-85FD-7333A1E13172@icsi.berkeley.edu> <53345C77.8040603@uni-due.de> <B7893984-2FAD-472D-9A4E-766A5C212132@pch.net> <102C13BE-E45E-437A-A592-FA373FF5C8F0@ogud.com> <474B0834-C16B-4843-AA0A-FC2A2085FEFB@icsi.berkeley.edu> <CAMm+Lwh-G7D5Cjx4NWMOhTjBZd=VVRHiPdK7L1zm-P0QRP8P2Q@mail.gmail.com>
In-Reply-To: <CAMm+Lwh-G7D5Cjx4NWMOhTjBZd=VVRHiPdK7L1zm-P0QRP8P2Q@mail.gmail.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [94.198.152.218]
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/yJtAwcjVE15qfLEvdW94tvx31kI
Cc: "dnsop@ietf.org" <dnsop@ietf.org>, Matthäus Wander <matthaeus.wander@uni-due.de>, Bill Woodcock <woody@pch.net>
Subject: Re: [DNSOP] Whiskey Tango Foxtrot on key lengths...
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 01 Apr 2014 13:53:05 -0000

On 04/01/2014 03:39 PM, Phillip Hallam-Baker wrote:
> 
> Yes, I agree, but you are proposing a different DNSSEC model to the one
> they believe in.
> 
> The DNS world has put all their eggs into the DNSSEC from Authoritative
> to Stub client model. They only view the Authoritative to Resolver as a
> temporary deployment hack.
> 
> So they resisted the idea of an authenticated Stub-client <-> Resolver
> protocol and they dumb down the crypto so their model will work. 
> 
> 
> Weakening the crypto algorithms to make the architecture work is always
> a sign that the wrong architecture is being applied.
> 

Oh come on.

If anything, one would expect that doing the validation on the end
machines is *easier* despite needing more cycles to do so, since there
is much less work to do and generally much more cycles to spare. So I
don't see your reasoning about 'them' follow up into this conclusion here.

The way I read it, Olafur is asking for people to consider other sizes,
and operational issues, rather than simply saying "double 'em up,
yeeha". One may disagree (I do too, as it happens, for different
reasons), or one can consider it and still come to the conclusion that
2048/4096 are the only right sizes (for now, we'll need better algos
soonish I guess).

Jelte