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, 6 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
>