IETF Logo Mail Archive

Re: [keyassure] TLSA record does not mandate the given certificate

Zack Weinberg <zack.weinberg@sv.cmu.edu> Tue, 29 March 2011 15:08 UTC

Return-Path: <zack.weinberg@gmail.com>
X-Original-To: keyassure@core3.amsl.com
Delivered-To: keyassure@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D0AE3A6940 for <keyassure@core3.amsl.com>; Tue, 29 Mar 2011 08:08:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.81
X-Spam-Level:
X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGCm90E4cQlo for <keyassure@core3.amsl.com>; Tue, 29 Mar 2011 08:08:05 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 849D03A6917 for <keyassure@ietf.org>; Tue, 29 Mar 2011 08:08:05 -0700 (PDT)
Received: by vws12 with SMTP id 12so242189vws.31 for <keyassure@ietf.org>; Tue, 29 Mar 2011 08:09:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ik8segDG3bxMSMnIIA7yVuIltnzYcn1jMTSSdb58wxw=; b=XzAKTwaO0NTdSVhqcej45kDpGySAOPPCZ5sFwdhBQCty3O/44D7BKoLbG6RsSk6Hpr hjv7J1IK8rsQyKH+dZ5YWzrUhV5/qkM614UIOuLzaC8kjnR3Jvebz2Y97iHrpiUa6ofO 2X7gjnw85RRegUACvV6VyvEDCsnbaqysyZYG4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Q1crxesgxMHJ6yfF20Uycue+uR6HClVEbTIuHFdvkhzukO/ZO4al2WQVs1+uWOASoH FnWH8mB4yTyFFwQNQP6tqOpRgUz6EOFxUUWLkfZ6UgUnMgJki46o+eQVWzKndlp3IhpI Wqgb0TIjcqpF0crwmRC9NAUNfH/3QhWAHra8c=
MIME-Version: 1.0
Received: by 10.52.179.69 with SMTP id de5mr1275398vdc.304.1301411355649; Tue, 29 Mar 2011 08:09:15 -0700 (PDT)
Sender: zack.weinberg@gmail.com
Received: by 10.52.166.34 with HTTP; Tue, 29 Mar 2011 08:09:15 -0700 (PDT)
In-Reply-To: <6B7AD439-2F88-4D8B-A58D-A32552D1E846@bbn.com>
References: <AANLkTikregQCBOovJz4yrcyet+60yT0EMxRkXFw0wqVi@mail.gmail.com> <4672.1301340852@marajade.sandelman.ca> <AANLkTinX7KDrHTzp996yNodFqkPhNdhyM5umA7yKH+iG@mail.gmail.com> <AA2DCA69-7C46-40DD-A444-65009480CD3C@nzrs.net.nz> <alpine.LFD.1.10.1103290430110.2105@newtla.xelerance.com> <6B7AD439-2F88-4D8B-A58D-A32552D1E846@bbn.com>
Date: Tue, 29 Mar 2011 08:09:15 -0700
X-Google-Sender-Auth: j88kHBoOrBZ73XWDUXAVxdKiiUs
Message-ID: <AANLkTina4TxqONeV+dCV+E74ud1savpD7DLFmmLVJDdW@mail.gmail.com>
From: Zack Weinberg <zack.weinberg@sv.cmu.edu>
To: "Richard L. Barnes" <rbarnes@bbn.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: keyassure@ietf.org
Subject: Re: [keyassure] TLSA record does not mandate the given certificate
X-BeenThere: keyassure@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC <keyassure.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/keyassure>
List-Post: <mailto:keyassure@ietf.org>
List-Help: <mailto:keyassure-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Mar 2011 15:08:06 -0000

On Tue, Mar 29, 2011 at 1:43 AM, Richard L. Barnes <rbarnes@bbn.com> wrote:
> I actually really disagree with the idea that DANE would be some parallel, alternative path to PKIX validation.  If DANE is going to be meaningful, it needs to be able to cause the TLS handshake to fail -- this is the correct behavior when the server says (through DANE) that things should be one way and they aren't.

I concur with this.  I see this as possibly *the* security benefit
relative to the status quo.

zw

v2.23.0 | Report a Bug | By Email