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

Colm MacCárthaigh <colm@allcosts.net> Wed, 02 April 2014 03:02 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 A2B061A00C2 for <dnsop@ietfa.amsl.com>; Tue, 1 Apr 2014 20:02:59 -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 8djxrO15eNtt for <dnsop@ietfa.amsl.com>; Tue, 1 Apr 2014 20:02:58 -0700 (PDT)
Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) by ietfa.amsl.com (Postfix) with ESMTP id D491A1A00AA for <dnsop@ietf.org>; Tue, 1 Apr 2014 20:02:57 -0700 (PDT)
Received: by mail-oa0-f41.google.com with SMTP id j17so12432231oag.28 for <dnsop@ietf.org>; Tue, 01 Apr 2014 20:02:54 -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=oJRE0+zliQ0Hw0pzwBLvH/WdCx6nldk4rRsgEZNrr/4=; b=Egr+7Lpyol4wXIXIL+f1WV+LgeX83KVFJfZbl9bcsDoJ3N4r14d57o5MZlKfjt8wDB CcCMzPHywafAz1dcdvDjVXyn8IMeGelbnjDoIAuvp62NO9G40rHYhWatXAqvTinQ5aLD pib7IHk/R9ynZeATmc3VULm4HuhnWtOGg/TIE/BmjH69lESB1iGBiWaAI73jxGonhPur vsRT4AxffAcDlWAknMdKtPJZzHtaWb249OvROPSFJQDTbj7TXo/OqxG/Y5SKdIZGz8oX EeKv2xckngERbuS6VuQaTi66iG3mio1KlxaU+USTCR8xzL4dWU+iY8rFqyjj4I5gWH1C VolA==
X-Gm-Message-State: ALoCoQnBRpNsUIkEIxgeekY8r2LgS44NDJ2NW95PmBw7e4KY9enOc9lWtMxZLLn1d/Vp3EvYFs1y
MIME-Version: 1.0
X-Received: by 10.182.165.3 with SMTP id yu3mr31367527obb.14.1396407774124; Tue, 01 Apr 2014 20:02:54 -0700 (PDT)
Received: by 10.76.20.164 with HTTP; Tue, 1 Apr 2014 20:02:54 -0700 (PDT)
In-Reply-To: <C88DDFA1-6585-4666-870D-91762129C725@ogud.com>
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> <CAAF6GDfGiB_GEVQ=igi4BeQsYBtQrqQ=uKZvAoJuSTLYL6PRyA@mail.gmail.com> <C88DDFA1-6585-4666-870D-91762129C725@ogud.com>
Date: Tue, 1 Apr 2014 20:02:54 -0700
Message-ID: <CAAF6GDeNdvLRSC3Zj1M7n9jwX8j8UBJcBXDj69jG34ACNRMLUA@mail.gmail.com>
From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= <colm@allcosts.net>
To: Olafur Gudmundsson <ogud@ogud.com>
Content-Type: multipart/alternative; boundary=001a11c2fcba57202a04f60685cc
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/OPbtJTv0UOyFcvtyjKa8GT3PS0E
Cc: "dnsop@ietf.org" <dnsop@ietf.org>, =?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 03:02:59 -0000

On Tuesday, April 1, 2014, Olafur Gudmundsson <ogud@ogud.com> wrote:
>
> you are assuming one validation per question ?
> what if the resolver needs to to 10? that is 1.8ms,
>

I'm not :) as I wrote - if the resolver validates after it has recursed,
only the final end of the line validation increases the overall latency.
Responses can be assumed to be valid, recursed and then that recursion can
be cancelled and backtracked if the response is found to be invalid.

In all system design we need to take into account where the system can be
> subverted, right now the
> registration part of DNS system is the weakest link, thus most cost
> effective way to gain hold of a domain is to
> divert the registration.
>

 There are several weak links, and it makes sense to work on them all.

> [1] There's no need to wait for a response to be validated before
> recursing, a validating resolver can first recurse and later backtrack if
> the parent signature doesn't verify.
>
>
> In the scope of things verification times are small compared to network
> delays but can add up if done as batch operation.
>

Optimistic concurrency doesn't imply batching. Each response can be
validated, while the next question is awaiting a response - one at a time.



-- 
Colm