Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

Ilari Liusvaara <ilariliusvaara@welho.com> Thu, 12 April 2018 18:46 UTC

Return-Path: <ilariliusvaara@welho.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E15D212DA09 for <tls@ietfa.amsl.com>; Thu, 12 Apr 2018 11:46:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=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 YsO8RyVTtJou for <tls@ietfa.amsl.com>; Thu, 12 Apr 2018 11:46:33 -0700 (PDT)
Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22DD9126DED for <tls@ietf.org>; Thu, 12 Apr 2018 11:46:33 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id DA67D53CB4; Thu, 12 Apr 2018 21:46:30 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id VuzaAJPoWeMq; Thu, 12 Apr 2018 21:46:30 +0300 (EEST)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 6BAE727F; Thu, 12 Apr 2018 21:46:27 +0300 (EEST)
Date: Thu, 12 Apr 2018 21:46:27 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Willem Toorop <willem@nlnetlabs.nl>
Cc: Paul Wouters <paul@nohats.ca>, "<tls@ietf.org>" <tls@ietf.org>
Message-ID: <20180412184627.GA22922@LK-Perkele-VII>
References: <CAOgPGoAhzEtxpW5mzmkf2kv3AcugNy0dAzhvpaqrTSuMSqWqfw@mail.gmail.com> <47ba1f3b-5fed-47b6-8701-e12dd2d473f4@nlnetlabs.nl> <alpine.LRH.2.21.1804101112350.20887@bofh.nohats.ca> <823877a3-9e51-bcdb-e43f-4313130aff4e@nlnetlabs.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <823877a3-9e51-bcdb-e43f-4313130aff4e@nlnetlabs.nl>
User-Agent: Mutt/1.9.4 (2018-02-28)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/a6ruR3juOu6MKXuqi7wfo9tT5xQ>
Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Apr 2018 18:46:36 -0000

On Thu, Apr 12, 2018 at 08:20:22PM +0200, Willem Toorop wrote:
> Sorry for being confusing.  I meant to say full Denial of Existing is in
> the draft implicitly already (because of the reference to DANE
> authentication according to RFC6698 and RFC7671 (which do mention it) in
> Section 6).
> 
> 
> I do like the idea of STS for this extension (and augment it with the
> more restrictive DANE use cases), but I'm unsure about the security of a
> built-in version.
> 
> I notice that existing STS documents (HSTS [RFC6797] and MTA-STS
> [draft-ietf-uta-mta-sts]) are all one layer above TLS.  Is a STS TTL
> conveyed in a ServerHello message secure when it would be just for SSL?

One has to wait for the handshake to complete for most cases (basically
all except the "clear pins with DoE" case).

> I can see this might be different for the DANE use case because of the
> signed statements that come alongside the TTL, but for example...
> In case of built-in STS with the extension, what does a 0 TTL mean?
> 
>   - When 0 has been the only value seen ever, it is clear to me that the
>     mechanism is equivalent with what we have in the draft now, but..
> 
>   - When another value has been seen before, is a value of 0 then enough
>     to clear the pin?  Or would a DoE proof (or insecurity proof)
>     alongside it be necessary?

The way I understand it would work, it would clear the pin at end of
handshake (one could clear immediately on DoE, but maybe better to
delay that too).
 
>     In case of the latter, what does that mean for sites that do have
>     DANE records, but no servers that support the extension?  Can they
>     be hampered (for an indefinite period) by a MiTM?  That would be
>     really bad for DANE deployment.
 
That type of attack is possible in some scenarios:

- The DANE records pin a CA and MITM can get misissued certificate from
  that CA.
- The server private keys get stolen.

Since the MITM would need to present a key that exists in the DANE
records in order to actually activate this pinning.

Recovery would need deploying the extension (the data needed is
public in DNS).


-Ilari