Re: [dane] An Update on Danelaw
Warren Kumari <warren@kumari.net> Sat, 05 April 2014 23:31 UTC
Return-Path: <warren@kumari.net>
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 614211A0192 for <dane@ietfa.amsl.com>; Sat, 5 Apr 2014 16:31:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.631
X-Spam-Level:
X-Spam-Status: No, score=-0.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_LOW=-0.7] 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 frUPR_6BWPFm for <dane@ietfa.amsl.com>; Sat, 5 Apr 2014 16:31:31 -0700 (PDT)
Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) by ietfa.amsl.com (Postfix) with ESMTP id 810E01A01AC for <dane@ietf.org>; Sat, 5 Apr 2014 16:31:30 -0700 (PDT)
Received: by mail-lb0-f178.google.com with SMTP id s7so3506190lbd.23 for <dane@ietf.org>; Sat, 05 Apr 2014 16:31:25 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=kgrPSkSrMoZJn1xMETfKyo72apUGTMzAg0CM3yQ5sFQ=; b=hWc6GacTNdc8ovQ/JJKUhu21lxOsoTYj6N6kGGSjNxdKAiWO1mOtzynwxr+ZLdBJjN TAeJ7P8bUJkZHLmhiQe9lpJq0BEht2nM/iLH946B6488xt7kX2TUkARRZTUMwcQJ8Fdo xXoLRzMnCAD+xTVrWxe4nafwqp0H8Jr684L/saqkNan2s/2Z2Ow0Tf+A7nL7orA/AfkI nkAIi6A5IZ1zHoJXbKbr7OoYBjbr86Is5lduvquqzUOmekunbc0bybWodUJUkVwp0yex yut1/HK7S9dhLMsfwCFGUiIiq6Q0wedOyksh+BVAlSwM9oMPLT7LROb7WaLsU1Pz9vbe tGyA==
X-Gm-Message-State: ALoCoQkB0UkKHLIOb7n9PeZto8fXlrkwDELfafJVw4HOofLyJhyBzFVYd6qOZoxvlX9KsedpZ+cs
MIME-Version: 1.0
X-Received: by 10.112.135.106 with SMTP id pr10mr13988431lbb.24.1396740685076; Sat, 05 Apr 2014 16:31:25 -0700 (PDT)
Received: by 10.114.0.243 with HTTP; Sat, 5 Apr 2014 16:31:25 -0700 (PDT)
X-Originating-IP: [66.84.81.58]
In-Reply-To: <20140405040326.GO12559@mournblade.imrryr.org>
References: <533EF994.7000009@nist.gov> <20140405040326.GO12559@mournblade.imrryr.org>
Date: Sun, 06 Apr 2014 07:31:25 +0800
Message-ID: <CAHw9_iJuRbKBuG_fy4hTfsc_B=NSGzjZcth9=f_cX6igG07x0g@mail.gmail.com>
From: Warren Kumari <warren@kumari.net>
To: "<dane@ietf.org>" <dane@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/StaJrQLxEK9PTFX50TZeltlkTeE
Subject: Re: [dane] An Update on Danelaw
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: Sat, 05 Apr 2014 23:31:35 -0000
On Sat, Apr 5, 2014 at 12:03 PM, Viktor Dukhovni <viktor1dane@dukhovni.org> wrote: > On Fri, Apr 04, 2014 at 02:27:32PM -0400, Stephen Nightingale wrote: > >> https://www.had-pilot.com/dane/danelaw.html. > >> The three DANE clients based on TLSlite 0.4.6, GnuTLS 3.1.16 and OpenSSL >> 1.0.1e all now incorporate Viktor Dukhovni's 'C' language dane checker >> and return consistent - though not identical - results. > > To be precise, currently each of these: connects, dumps the server > certificate chain to a PEM chain file, and invokes my DANE verification > code in an "offline" mode to validate the chain against each of > the TLSA records. That way the verification code is independent > of the TLS toolkit used to complete the connection. > >> - Dougbarton.us works with GnuTLS, but generates handshake failures with >> TLSlite and OpenSSL. > > Something is not right with the above, at least with OpenSSL 1.0.1 > I get a working SSL connection with dougbarton.us. Now this server > presents a chain with just the leaf certificate, even though the > issuing CA is an intermediate CA. When I put both the intermediate > cert (attached) and its issuing root (attached) in a CAfile, I can > verify the dougbarton.us "1 0 2" TLSA record just fine. > >> - Kumari.net and Spodhuis.org both complete handshakes with TLSlite and >> GnuTLS, but fail against OpenSSL. > > OpenSSL succeeds for me with spodhuis.org. Same StartCom root and > intermediate as dougbarton.us, but spodhuis actually presents a > full chain. > > Likewise www.kumari.net works, and the "TLSA 1 0 1" record matches > with the PKIX root from Equifax. > > Do connections to these sites work for you with "openssl s_client"? Works for me with OpenSSL 1.0.1. > This warrants further investigation. > Yup. >> - Kumari.net returns 403 forbidden to TLSlite and GnuTLS, but works with the >> Browsers. I am guessing the 403 is generated because my clients do not send >> a certificate. I will be testing for bi-directional verification sometime >> in the future. Actually the 403 was being returned because some stupid webscrawler script kept DoSing me, so I denied anything that didn't include an "accept: " header. I've now removed that and the TLSlite and GnuTLS tests now show a page instead of the 403. While looking into this I found: [Sat Apr 05 19:12:50 2014] [error] [client 66.84.81.58] script not found or unable to stat: /usr/lib/cgi-bin/dane, referer: https://www.had-pilot.com/dane/yourdane.html in my log, which made me giggle... W > That's an application layer issue, that is not really relevant for > testing DANE. Once the TLS session is up, you can just disconnect, > without even sending an HTTP request. > >> GnuTLS is running all 0xx and 1xx certificate uses, serving a single end >> certificate per use. It runs 24/7 robustly. It can only be configured to >> take a single end certificate for the server handshake. When presented with >> a concatenation of PEM certs, it will send only the end cert in the server >> side handshake. > > That does not sound right, are you sure about that? RFC 2246, 4346 > and 5246 all require servers to present a chain with more than just > the leaf certificate unless directly issued by a root CA. So it > would be rather surprising of GnuTLS were not capable of presenting > a complete chain. Almost certainly you just need to invoke it > differently to load a complete chain. > >> The OpenSSL DANE server is running all 3xx certificate uses, with a single >> wild card end certificate. Whether it can serve a full PEM concatenated >> certificate chain is a question still to be investigated. > > OpenSSL definitely supports presenting a complete chain. > >> The near-future course of the DANE project at NIST will now focus on SMTP >> uses, for both MUAs and MTAs. > > I think the issues with the HTTP use case are not protocol-specific > and will crop up again with SMTP. So they should be addressed. > > -- > Viktor. > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >
- Re: [dane] An Update on Danelaw Viktor Dukhovni
- Re: [dane] An Update on Danelaw Warren Kumari
- [dane] An Update on Danelaw Stephen Nightingale