IETF Logo Mail Archive

Re: [dane] Behavior in the face of no answer?

Eric Rescorla <ekr@rtfm.com> Fri, 04 May 2012 15:57 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 380DC21F86D0 for <dane@ietfa.amsl.com>; Fri, 4 May 2012 08:57:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.573
X-Spam-Level:
X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=-0.196, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MhJce-gNd9Tu for <dane@ietfa.amsl.com>; Fri, 4 May 2012 08:57:20 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB0621F8680 for <dane@ietf.org>; Fri, 4 May 2012 08:57:20 -0700 (PDT)
Received: by vcbfo1 with SMTP id fo1so2563902vcb.31 for <dane@ietf.org>; Fri, 04 May 2012 08:57:20 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=cX/HpHkF6QkuwrbNPhgHoD1O3zUvvj9WLSvNsZD9wbw=; b=TFfhF9dAsgv1zNRBZ6eNKa75ILgzKJjmAJ/T6RjKdYsyhkwjkF0AhoJwCcQX2xYj1r eMFa7hUkVmmL17b7ub6DEzPrG4a1WzRU8DS4FGeF4/2am2lSpe5kbCxW+jyoBj4IAGoU Qa/gQVAxFn9ThtTtD0qtxYH7Rw+gY8Jd4p9vQSwyK5OS0r3jL9FIscsM81vnU/lozDd9 2jrW+Qybhzhvrje6W2FLPLFPfRjf6mGUtSGGAs8ztZk17h7vI4N4+C4Ez3b0F/3XdnG5 Cl5lIu2oZEDqOfP0VdaxvJfibDcI8VYrF4S0Fnvq8CzTTvJOpNiTAeXHSMP0dM/iR++I XZwA==
Received: by 10.52.22.148 with SMTP id d20mr2437997vdf.102.1336147039953; Fri, 04 May 2012 08:57:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.19.233 with HTTP; Fri, 4 May 2012 08:56:39 -0700 (PDT)
X-Originating-IP: [74.95.2.173]
In-Reply-To: <CA+cU71n8qGBc_tJ4pxFeC3268Mtyj1ZV+v7kkwOA5dy-iAyZ1w@mail.gmail.com>
References: <CABcZeBMY26xrfvAx=UsYN2XnuONZ2vPy9tNwHQALudd=yQDvgA@mail.gmail.com> <0526D60A-3F1B-4C55-9796-256BC2556AAB@vpnc.org> <20120503223745.GC1804@mail.yitter.info> <CABcZeBMFV8oiZJfAY1fZ_0bBQWa=q6aBL65AS+W5gBuKmPnwOg@mail.gmail.com> <20120504021044.GB4560@mail.yitter.info> <B25C977F-6B4E-458C-879D-A36EDB94DA75@icsi.berkeley.edu> <20120504023602.GA4683@mail.yitter.info> <CABcZeBO93n_C5detefBcOjAoswe2inGKDj65gQPDQmREyGnhAw@mail.gmail.com> <20120504112922.GB4929@mail.yitter.info> <2DDB5448-6A34-4D68-9421-4505CCC71A1A@icsi.berkeley.edu> <D7743FA1-34E0-4030-B17B-33300143A520@ICSI.Berkeley.EDU> <CA+cU71n8qGBc_tJ4pxFeC3268Mtyj1ZV+v7kkwOA5dy-iAyZ1w@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 4 May 2012 08:56:39 -0700
Message-ID: <CABcZeBMNbmJciAw-3rpiHNp4HZdApFs-LHrk0691feKbZbeuRQ@mail.gmail.com>
To: Tom Ritter <tom@ritter.vg>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQmFlw6BqVR+xedT14BRaIxxnhwyz+p1OgO49Z6s3NWT31gDOQJ+bjeXkGANEp5BIMSyc3Ap
Cc: Adam Langley <agl@imperialviolet.org>, dane@ietf.org
Subject: Re: [dane] Behavior in the face of no answer?
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 May 2012 15:57:21 -0000

On Fri, May 4, 2012 at 8:37 AM, Tom Ritter <tom@ritter.vg> wrote:
> On 4 May 2012 10:42, Nicholas Weaver <nweaver@icsi.berkeley.edu> wrote:
>> So here's my proposal: Actually check the network for b0rkenness!
>>
>> The browser, on startup, or when the local IP address changes, conducts the following test:
>>
>> It checks, using three known sites with TLSA records (provided by the browser vendor, with deliberate redundancy to prevent a TLD outage from being a problem), to see if it can receive and validate a TLSA record using DNSSEC for at least one of the three sites.
>
> I don't think will actually help anything.  The attacker will just
> block ALL TLSA records, not just for the target site he intends to
> MITM.
>
>
>
> Fail-close vs Fail-open when you can't get the TLSA record is OCSP
> hard-fail vs soft-fail all over again.  I'd like Hard fail, but no
> matter what we say, no browser will implement it.  If mandating
> hard-fail in the spec causes clients to NOT implement DANE (as opposed
> to just ignoring the recommendation) - I don't think we should do it.
>

But then what is the security value of the restrictive DANE usages?

>
> HOWEVER!  WE HAVE A SOLUTION!  Actually, Chrome has a solution, and it
> already works. http://www.imperialviolet.org/2011/06/16/dnssecchrome.html
> DNSSEC Stapled Certificates
>
> Put the DNSSEC chain *in the TLS certificate*.  This won't be blocked
> by a MITM, and if you receive a self-signed certificate with a valid
> TLSA chain in it, it's valid.  The TLSA chain is signed, so it doesn't
> matter _how_ you receive it, as long as the signatures all match up.

This is only useful for usages 2 and 3 (the additive ones). In the case
of usages 0 and 1, the attacker is delivering his own certificate and
just won't send any TLSA records.

-Ekr

v2.8.7 | Report a Bug | By Email