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

Eric Rescorla <ekr@rtfm.com> Wed, 16 May 2012 16: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 92A5421F847E for <dane@ietfa.amsl.com>; Wed, 16 May 2012 09:57:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.886
X-Spam-Level:
X-Spam-Status: No, score=-102.886 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 B582XJBNMReS for <dane@ietfa.amsl.com>; Wed, 16 May 2012 09:57:39 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5948921F847F for <dane@ietf.org>; Wed, 16 May 2012 09:57:39 -0700 (PDT)
Received: by vbbez10 with SMTP id ez10so1073967vbb.31 for <dane@ietf.org>; Wed, 16 May 2012 09:57:38 -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=9h7jmNedIEly798TZf3cvjAG8LrG2xb6hKN3seQHPS8=; b=P3rKiwRR56oiLYG3HMT8vp+rYsHubaOw6yrot9Ql7cuyhGWw89QYLGTuPhGCnR5Jmx OkdqYCVP/sNsb+Le6kAx4aUDZr1tP/WB98FYZMKYVEFHhPQRWt92ETWqbnwGWewvsZmp 19UMLI3uiUfl8Fv7WaREim6FAIFY555Ak/CVbxC0K9UTB1/orcjS4nvId+ngKyqw8vcc XOMjhnYwlGRRRa2hlCN0lxCVMihgjggqJ0m937XmQrw2Qa2mkaSHwBU5uN41c3YPnxNg ORwB9Al3jsphJ5F3ryxObcm5VY2Scp9QYito7gZn1TH5ff8wQGjP0Okc9OiDqm+5ASXL QQzA==
Received: by 10.52.177.41 with SMTP id cn9mr2434528vdc.53.1337187458861; Wed, 16 May 2012 09:57:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.35.209 with HTTP; Wed, 16 May 2012 09:56:58 -0700 (PDT)
X-Originating-IP: [74.95.2.173]
In-Reply-To: <201205160124.q4G1OIcF015532@new.toad.com>
References: <CABcZeBMY26xrfvAx=UsYN2XnuONZ2vPy9tNwHQALudd=yQDvgA@mail.gmail.com> <643D87CD-D01E-47B8-82E5-D3F57D50C80B@vpnc.org> <201205160116.q4G1GTcF015332@new.toad.com> <201205160124.q4G1OIcF015532@new.toad.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 16 May 2012 09:56:58 -0700
Message-ID: <CABcZeBNOpdvP5nsHzQeThtGWbxx4KhiZKf1zHS7Ka0eZgGEMSg@mail.gmail.com>
To: John Gilmore <gnu@toad.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQkXOnKTbTD6tYXPnQNiNIsvqTyDf1sezt0XtHmdCOnXuwKyEOQpN5q8dvpNTD7X+cAOYG3P
Cc: Paul Hoffman <paul.hoffman@vpnc.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: Wed, 16 May 2012 16:57:40 -0000

On Tue, May 15, 2012 at 6:24 PM, John Gilmore <gnu@toad.com> wrote:
>> responses being sent to the user.  Thus, in order to achieve any
>> security benefit from certificate usage 0 or 1, the protocol requires
>> that when DNS responses have not arrived or are not valid, the TLS
>> connection must not succeed.
>
> It's easy for a Man in the Middle to subvert cert usage 3 this way
> too.  They just issue themselves a cert signed by some subverted
> public CA, block your TLSA DNS responses, and then if you proceed with
> TLS, you'll accept the key signed by the subverted public CA, since
> you never saw the record that says "This server is secured by THIS
> PUBLIC KEY RIGHT HERE, and not anything else."
>
> This attack also works against cert usage 2.  Thus I'm not sure why
> this proposed graf even mentions cert usages 0 and 1, except perhaps
> to remind the PKIX fans among us that proceeding in the face of DNS
> blockage causes even their favorite forms of TLSA to be vulnerable.

It's there because I hadn't had time to really think about 2 and 3
but I was sure about 0 and 1.

With that said, it's not true that 2 and 3 are the same as 0 and 1. Imagine
a client which asks for TLSA records and pays attention to 2 and 3 but
ignores 0 and 1. That client could (assuming people actually serve
TLSA records) avoid showing the red screen of death for some
self-signed sites. Surely that is indeed of security value, although
it does not offer any defense against CA compromise.

-Ekr