IETF Logo Mail Archive

Re: [dns-privacy] [SPAM] Re: New draft on encrypting the stub-to-resolver link: draft-hoffman-dns-tls-stub-00.txt

Jacob Appelbaum <jacob@appelbaum.net> Wed, 20 August 2014 17:11 UTC

Return-Path: <jacob@appelbaum.net>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 886661A047C for <dns-privacy@ietfa.amsl.com>; Wed, 20 Aug 2014 10:11:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 uRLNNb4E7WEe for <dns-privacy@ietfa.amsl.com>; Wed, 20 Aug 2014 10:11:35 -0700 (PDT)
Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 727351A0432 for <dns-privacy@ietf.org>; Wed, 20 Aug 2014 10:11:35 -0700 (PDT)
Received: by mail-qg0-f48.google.com with SMTP id i50so7492107qgf.7 for <dns-privacy@ietf.org>; Wed, 20 Aug 2014 10:11:32 -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=H1KW8ihrgE3y5SdmmTJ2NW3KjTIOP9CnSC19UIxye1k=; b=mEJSJuSp3qqxyO/h8I+5XhNwVIR0CNsIXsNyY2c75Lmq43WbA2d/E0ZO/lohV0Vvfw djHGMgoHUYrp4nUD2UImis4DTENYc9POG/U84LplTeur/Dr1fTGUnJVD7XDe3WLNNE1w t7rugHnz+/mM4rNG7pk7JMK5d2mJfrvDa8qZ8MRiL0wXjnayjOg1TV+Z2jCjCQgMDbHK UEuZzpo+2qQsT0QAuKTuo2DKj3wcoyjyg/bnle1Xfv7x5qLk93zhsC2mURoXmJmXGsxH NPqQVWreTBBAaDjDUH/1riQ1Arbmi86Hz9XrrA3sw1xvE8XHkGMgH9rMmlMEGEqVcJ1x SJYw==
X-Gm-Message-State: ALoCoQlsIBt++T+UhPqLUvC6Fa6WRKbJ0glKFz1ivOuTcnFplisZNggdGAqQpgQJn2DTCiPD/NcH
MIME-Version: 1.0
X-Received: by 10.140.84.21 with SMTP id k21mr74668069qgd.70.1408554692068; Wed, 20 Aug 2014 10:11:32 -0700 (PDT)
Received: by 10.140.91.50 with HTTP; Wed, 20 Aug 2014 10:11:31 -0700 (PDT)
X-Originating-IP: [72.52.91.30]
In-Reply-To: <alpine.LFD.2.10.1408201229350.26631@bofh.nohats.ca>
References: <00ba01cfbbf9$d561f010$8025d030$@rozanak.com> <20140820143453.GD1065@mx1.yitter.info> <814D0BFB77D95844A01CA29B44CBF8A7A28554@lhreml513-mbb.china.huawei.com> <20140820152343.GH1065@mx1.yitter.info> <814D0BFB77D95844A01CA29B44CBF8A7A285FA@lhreml513-mbb.china.huawei.com> <CAFggDF3wej+gFU7-_iTu8N=J+K9uKwOnNhz8oavp3G9rA9XYug@mail.gmail.com> <alpine.LFD.2.10.1408201229350.26631@bofh.nohats.ca>
Date: Wed, 20 Aug 2014 17:11:31 +0000
Message-ID: <CAFggDF0JQRiZ6tuTRH-PSit427pkLAqH+eiqyK3M8yVjrnyXRA@mail.gmail.com>
From: Jacob Appelbaum <jacob@appelbaum.net>
To: Paul Wouters <paul@nohats.ca>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/gGZZK3J4_tYQzBrhc_OQ4xBlNSg
Cc: "dns-privacy@ietf.org" <dns-privacy@ietf.org>
Subject: Re: [dns-privacy] [SPAM] Re: New draft on encrypting the stub-to-resolver link: draft-hoffman-dns-tls-stub-00.txt
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Aug 2014 17:11:37 -0000

On 8/20/14, Paul Wouters <paul@nohats.ca> wrote:
> On Wed, 20 Aug 2014, Jacob Appelbaum wrote:
>
>> Paul - perhaps this suggests that all stub and recursive resolvers
>> should log keying information, even if it isn't used for
>> validation/authentication/etc?
>
> That is one "out of band" authentication mechanism called TOFU (trust on
> first use) or LOF (Leap of Faith)

I'm suggesting that regardless of authentication, we should ensure
that we have some information for a user to report their experience.

>
> While possible, it will see a lot of false positives, like when going to
> a different starbucks using the same wifi ESSID.
>

There is no false positive - only an actually observed certificate. :)

> It could be done if one also logs mac address and/or lat/long info.
>
> But these are all local policy and local implementations issues.

I agree. I suggest that resolvers SHOULD log resolver certificate information.

All the best,
Jacob

v2.23.0 | Report a Bug | By Email