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

Colm MacCárthaigh <colm@allcosts.net> Wed, 02 April 2014 00:07 UTC

Return-Path: <colm@allcosts.net>
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 5B4121A0031 for <dnsop@ietfa.amsl.com>; Tue, 1 Apr 2014 17:07:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.677
X-Spam-Level:
X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 CD356ibPojkW for <dnsop@ietfa.amsl.com>; Tue, 1 Apr 2014 17:07:51 -0700 (PDT)
Received: from mail-ob0-f170.google.com (mail-ob0-f170.google.com [209.85.214.170]) by ietfa.amsl.com (Postfix) with ESMTP id 3351D1A002A for <dnsop@ietf.org>; Tue, 1 Apr 2014 17:07:51 -0700 (PDT)
Received: by mail-ob0-f170.google.com with SMTP id uz6so12103068obc.29 for <dnsop@ietf.org>; Tue, 01 Apr 2014 17:07:47 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=hkiYEhHaK+oy03CFQWy5eKLgCdYTTYBWlaUoaaI/djI=; b=PTqu4OCrCLlnGjH2/+E8HoB61emjAV/L/fiQ2o6E4ZgXBDaF6nJtCWSdhyYBOtLEt2 PkUYqyOalfMZIbd6j90iiHbFDFRjvTErPBgx8Eh5j4yQyhMusVMGf215c20xF4tanKOY c66gPcqoumeeZfvk5n7+LrrdVs8IHDyo1EZr5pX3Rg7Mcf5Pwv3LYRVPbZzUNb8Twy4t /BahGf0qUUA6Xgt5gyMXr5eoMPusKod1afZ7HTC0a2S+4adQMJcwQvIR+7VCv6dT6BX3 HtdSyUMPskP5pss2OCitwTA15agzWmw+qMRHycIHGCtJSlr68V4Cm4osxy/kYY7yLEYz PyZA==
X-Gm-Message-State: ALoCoQlz5uAq9u5kyweASaeqkKIA3DwuB1r5AYWZc5bN8dN7Qp1ZN70mU/55+cmIr792MEi7bDfO
MIME-Version: 1.0
X-Received: by 10.60.173.233 with SMTP id bn9mr31767027oec.9.1396397266893; Tue, 01 Apr 2014 17:07:46 -0700 (PDT)
Received: by 10.76.20.164 with HTTP; Tue, 1 Apr 2014 17:07:46 -0700 (PDT)
In-Reply-To: <20140401223943.528B71226903@rock.dv.isc.org>
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> <20140401223943.528B71226903@rock.dv.isc.org>
Date: Tue, 1 Apr 2014 17:07:46 -0700
Message-ID: <CAAF6GDe=39bmVDOtox+9coaH7R06erm-JUK19ZwPEUVkxepKTg@mail.gmail.com>
From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= <colm@allcosts.net>
To: Mark Andrews <marka@isc.org>
Content-Type: multipart/alternative; boundary=089e011825440f264b04f604135f
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/fTlxUi3bVw6a1KOpIjg_9BLuR2E
Cc: Nicholas Weaver <nweaver@icsi.berkeley.edu>, "dnsop@ietf.org" <dnsop@ietf.org>, Phillip Hallam-Baker <hallam@gmail.com>, =?ISO-8859-1?Q?Matth=E4us_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: Wed, 02 Apr 2014 00:07:52 -0000

On Tue, Apr 1, 2014 at 3:39 PM, Mark Andrews <marka@isc.org> wrote:
>
> As I have said many times.  There is a myth that recursive servers
> do not need to validate answers.  Recursive servers will always
> need to validate answers.  Stub resolvers can't recover from recursive
> servers that pass through bogus answers.


This too is going too far; of course they can, they can ask another
recursive resolver.

Always set CD=1 is also bad advice.  Stub resolvers need to send
> both CD=1 and CD=0 queries and should default to CD=0.  CD=1 should
> be left to the case where they get a SERVFAIL result to the CD=0
> to handle the case where the recursive server's clock is broken or
> it has a bad trust anchor.
>

Defaulting to CD=0 renders DNSSEC, essentially, pointless. Resolvers, and
the path between resolvers and stubs, are the easiest components in the
lookup chain to subvert.

> So they resisted the idea of an authenticated Stub-client <-> Resolver
> > protocol and they dumb down the crypto so their model will work.
>
> DNSSEC is quite capable to protecting that path.  Why do you need
> a second protocol.
>

That statement is not consistent with setting CD=0 on that path.

-- 
Colm