Re: [dane] List of incidents that DANE would have blocked?

William Stouder-Studenmund <wrstuden@mac.com> Thu, 02 October 2014 17:21 UTC

Return-Path: <wrstuden@mac.com>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA3D1A8A04 for <dane@ietfa.amsl.com>; Thu, 2 Oct 2014 10:21:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.413
X-Spam-Level:
X-Spam-Status: No, score=-0.413 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MALFORMED_FREEMAIL=1.487, SPF_PASS=-0.001] autolearn=no
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 gEdqxOJlhXpf for <dane@ietfa.amsl.com>; Thu, 2 Oct 2014 10:21:23 -0700 (PDT)
Received: from mr11p24im-asmtp002.me.com (mr11p24im-asmtp002.me.com [17.110.78.42]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FC651A89EF for <dane@ietf.org>; Thu, 2 Oct 2014 10:21:23 -0700 (PDT)
Received: from [17.114.110.91] (unknown [17.114.110.91]) by mr11p24im-asmtp002.me.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0NCT00L6MUVE1670@mr11p24im-asmtp002.me.com> for dane@ietf.org; Thu, 02 Oct 2014 17:21:22 +0000 (GMT)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.28,0.0.0000 definitions=2014-10-02_05:2014-10-02,2014-10-02,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1410020170
Content-type: text/plain; charset="us-ascii"
MIME-version: 1.0 (Mac OS X Mail 8.0 \(1985.3\))
From: William Stouder-Studenmund <wrstuden@mac.com>
In-reply-to: <20141002161541.GE13254@mournblade.imrryr.org>
Date: Thu, 02 Oct 2014 10:21:13 -0700
Content-transfer-encoding: 7bit
Message-id: <E0890960-1680-4766-9F41-4DB775E7708F@mac.com>
References: <DD18BA26-107D-4584-ACDE-131DD3D45AE6@mac.com> <20141002161541.GE13254@mournblade.imrryr.org>
To: dane@ietf.org
X-Mailer: Apple Mail (2.1985.3)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/0bxyIfZYtYnb9vaxAid5thpxGD4
Subject: Re: [dane] List of incidents that DANE would have blocked?
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 02 Oct 2014 17:21:24 -0000

> On Oct 2, 2014, at 9:15 AM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
> 
> On Wed, Oct 01, 2014 at 09:37:08AM -0700, William Stouder-Studenmund wrote:
> 
>> Making a case for DANE means making a case for DNSSEC.
> 
> Yes.
> 
>> I get that DANE can detect a large class of MITM attacks.
> 
> No, DANE can public associations between service end-points and
> public key material.  Protecting against MITM attacks is a matter
> for the protocols that use that key material.  DNSSEC hardens the
> lookups of that key material against MITM attacks.
> 
>> Saying that
>> isn't as convincing as handing over a list of, "DANE is designed to stop
>> this, DANE would have stopped that one," and so on.
> 
> DANE can enable opportunistic security protocol designs that are
> capable of resisting MITM attacks.  This is in use with SMTP and
> XMPP.

Thank you! These are the things I was hoping to hear.

> DANE for the web is some time away.  None of the browsers are
> planning DANE support at this time.  My hope is that at some point
> in the future the new "h2" URI scheme will support opportunistic
> DANE TLS, rather than just opportunistic unauthenticated encryption.
> 
> DANE replacing public CAs with "https" seems unlikely so long as
> there is perceived value in "EV" certificates.

Take care,

Bill