Re: [dane] I-D Action: draft-ietf-dane-srv-04.txt

mrex@sap.com (Martin Rex) Mon, 17 February 2014 13:31 UTC

Return-Path: <mrex@sap.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 AD2971A0006 for <dane@ietfa.amsl.com>; Mon, 17 Feb 2014 05:31:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level:
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 qcOa4N41hnEt for <dane@ietfa.amsl.com>; Mon, 17 Feb 2014 05:31:01 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7C81A01E0 for <dane@ietf.org>; Mon, 17 Feb 2014 05:31:00 -0800 (PST)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s1HDUvh4019855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <dane@ietf.org>; Mon, 17 Feb 2014 14:30:57 +0100 (MET)
In-Reply-To: <20140215164446.GN278@mournblade.imrryr.org>
To: dane@ietf.org
Date: Mon, 17 Feb 2014 14:30:57 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20140217133057.2BDF41AC10@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/MCp2GfwshbuyMH2k9CeBHEEzVws
Subject: Re: [dane] I-D Action: draft-ietf-dane-srv-04.txt
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
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: Mon, 17 Feb 2014 13:31:04 -0000

Viktor Dukhovni wrote:
>>
>> Defective implementations excepted, the TLS protocol engine will
>> look at the KeyUsage attribute of the Server certificate and check
>> the cipher suite selection for compatibility -- and the application
>> call will NOT have a say in this.
> 
> You seem to be wedded to the idea that DANE support will be in
> application code and not in "TLS engine code".

That isn't my idea, that is a fundamental part of the architecture
of TLS, described in every existing TLS specification at the end
of section 1, Introduction.

  http://tools.ietf.org/html/rfc2246#page-4

                        The TLS standard, however, does not specify how
   protocols add security with TLS; the decisions on how to initiate TLS
   handshaking and how to interpret the authentication certificates
   exchanged are left up to the judgment of the designers and
   implementors of protocols which run on top of TLS. 


>
> Having actually implemented a complete DANE verifier, I can assure
> you that there will be very few applications indeed that attempt
> to do this.

We know painfully well just how poor apps are in doing certificate
verification:
 "The most dangerous Code in the World"
 http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf


A number of TLS protocol implementations come with utility functions
to make the task easier for applications to consume TLS.

The model how server endpoint identites are checked in HTTP-over-TLS,
as described in rfc2818, is a matter of the application from the
TLS protocol perspective.  Leaving the checking of certificates
entirely to applications is what leads to the problem described in
above paper.

The situation with DANE is very much alike.  DANE does not change
anything about how TLS works, it only changes how applications make
use (including certificate (parh) validation) of the certificates
exchanged within the TLS protocol.


It is likely that TLS implementation will add support for DANE to
the the set of utility functions that are supposed to facilitate
consumption of TLS for applications.  DANE is *NOT* part of TLS,
and it will be the task of application to actually have the checks
performed.


-Martin