IETF Logo Mail Archive

Re: [DNSOP] If DNSSEC signatures do not validate ...

Ben Schwartz <bemasc@google.com> Thu, 30 April 2020 01:56 UTC

Return-Path: <bemasc@google.com>
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 E11BA3A0CEC for <dnsop@ietfa.amsl.com>; Wed, 29 Apr 2020 18:56:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 r7beBeuJNlmi for <dnsop@ietfa.amsl.com>; Wed, 29 Apr 2020 18:56:29 -0700 (PDT)
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 006B23A0CEB for <dnsop@ietf.org>; Wed, 29 Apr 2020 18:56:28 -0700 (PDT)
Received: by mail-wm1-x32b.google.com with SMTP id u127so112142wmg.1 for <dnsop@ietf.org>; Wed, 29 Apr 2020 18:56:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=woVVoQ+TWtMkU2h2laElx51URxJ2ejAXdFzqoHDPE5Q=; b=W1MbjitFHVxotpOheg+sWwplWjE3dz8zSInokHsCcHGhMGOO78UnMp+xm2t0aiqnzj M1oG6liGtQP5ssnQcDFG8iiufeb9OSKyIJsojs0rep84om3Y5QvTWk9/UKeCrHX6fuAe FxcjEw7PwhE/gg4tPnp2TMuPrC2B3+/ARgiZkBmU7OlcK6Y5bpNt9QsaXfIoxANMMRHb AShOKuVo//Oq29W8tOoxMSG0nNTyGYt0FEXrdcokUcD1REtah5qp5a9WPR/5RaaVs7JJ wxP6zukj0z9d6ceAZ8Hvyz2C9HZllgpf5aYTHqUyMnJoEhtU+WI7tuu3bqo3VwvGbPfV KjZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=woVVoQ+TWtMkU2h2laElx51URxJ2ejAXdFzqoHDPE5Q=; b=rKtph5a5JSEG9KEAY+qiRKru3Yf9nWfh+B+A5QuRcxzKd0XHEncM4X0YSx4LxKczKP M2lR611t2fUZJc1LAGQGd9jiRnG4JZ8Tb8pmGl7Ix1f6mxPiMxfkLjAiDfFgGt61W2nS TZG7qyofWbvgGN2ZSn3nU0vT8HqQzdfU9PmzIGDNtFY4qn8ze28gUS99xLYhP3DGCUPE 0qBrpOxlWwai3GsGP6I8oX3lSL38liBIq4oj7tuIp7V/VhexHylD358RmaJZ/imITX+y 12iMGDxHRZ/LTTubxp9EACtHlBZT7ZRcSJWUbo0HXefkeOFnfrQybCS1zf4nbQoK61fV bJ+Q==
X-Gm-Message-State: AGi0PuYtQ9i0Mi7be1+Rx95h23kNbtQxCTrG+Pe447WC20EelqwJHv/E uUUx1Ujo5+upDSpIwwQ7GWUKcHYO0/ccYI6EbQ4YiA==
X-Google-Smtp-Source: APiQypL/zMOowbYkvQkhtlBTteXbCnSDzpgoDH6KaF475QC0vYTt07nW+k4CelAGo3KxwygQil437TxdlBy6+FcUdic=
X-Received: by 2002:a7b:ce8b:: with SMTP id q11mr209898wmj.101.1588211785739; Wed, 29 Apr 2020 18:56:25 -0700 (PDT)
MIME-Version: 1.0
References: <CAAObRXL-hFZ1jFo8dW-+M+2SR8gJ7vypKLMaJNuQJBvCsdJ0Gg@mail.gmail.com> <alpine.LRH.2.21.2004280931470.18623@bofh.nohats.ca> <CAAObRXJKf67Hv8i+fTUWcQMqpk-8hL6PPQ=iXtWnZ8yzk-wNWQ@mail.gmail.com> <CAHPuVdWpqEs+OfVT6Udviyigwegh6416sG5MeaBY_3mf5mpJPw@mail.gmail.com> <CAAObRXK36VVFTXd=_SNje4z3muBvUL3SZa0PmONgu50-V1r7ug@mail.gmail.com> <alpine.LRH.2.21.2004281120160.18623@bofh.nohats.ca> <CAHPuVdWieJoTAtEjvdZKCNR7Y8mtb=oi4C4+g1Dw33rNOY2_9A@mail.gmail.com> <CAAObRXJf-=woUKvAWD8YwX16-P5tT9FrekWBeYE6ROR39TMtnQ@mail.gmail.com>
In-Reply-To: <CAAObRXJf-=woUKvAWD8YwX16-P5tT9FrekWBeYE6ROR39TMtnQ@mail.gmail.com>
From: Ben Schwartz <bemasc@google.com>
Date: Wed, 29 Apr 2020 21:56:14 -0400
Message-ID: <CAHbrMsBMu9wQop7Evdg6KhktZo7hhCxqD+neWqCJXFMYbV_ZRw@mail.gmail.com>
To: Davey Song <songlinjian@gmail.com>
Cc: Shumon Huque <shuque@gmail.com>, dnsop <dnsop@ietf.org>, Paul Wouters <paul@nohats.ca>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="0000000000006d3a2005a4785fa1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/rpvKfbiZrHzqx9SiGpljSW55R5Y>
Subject: Re: [DNSOP] If DNSSEC signatures do not validate ...
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 30 Apr 2020 01:56:32 -0000

I think this would be a reasonable behavior for a "hybrid stub/recursive".
I would think about it as a performance optimization, allowing a recursive
resolver to avoid recursion if it can get the answer from another recursive
instead.

There are many other possible hybrid behaviors too, such as racing the stub
and recursive resolution processes.

Instead of describing this particular behavior, it might be more helpful to
attempt a general description of requirements on hybrid resolvers, i.e. a
set of requirements that apply to stubs, recursives, and everything in
between.

On Tue, Apr 28, 2020 at 11:54 AM Davey Song <songlinjian@gmail.com> wrote:

>
>> Davey - if there is a pervasive/omnipresent man-in-the-middle attacker,
>> then no security protocol (DNSSEC, TLS, HTTPS or any other) can
>> _prevent_ the attack. All they can do is to _detect_ that an attack is
>> taking
>> place (and probably abort).
>>
>> Shumon.
>>
>
> Fair enough.
>
> Davey
>
>> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>

v2.23.0 | Report a Bug | By Email