Re: [TLS] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps

Benjamin Kaduk <bkaduk@akamai.com> Wed, 17 October 2018 01:15 UTC

Return-Path: <bkaduk@akamai.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 5616B1252B7 for <tls@ietfa.amsl.com>; Tue, 16 Oct 2018 18:15:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.766
X-Spam-Level:
X-Spam-Status: No, score=-0.766 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.064, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com
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 eFtpfNbk76uP for <tls@ietfa.amsl.com>; Tue, 16 Oct 2018 18:15:19 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A15F126CC7 for <tls@ietf.org>; Tue, 16 Oct 2018 18:15:19 -0700 (PDT)
Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.23/8.16.0.23) with SMTP id w9H17PTm027427; Wed, 17 Oct 2018 02:15:17 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=BBpQL/cYGTgdbHt1RyYmSXiM0mj3O6AjiGK9JtWgHps=; b=a/jKU9fpsSpzhCAQgK46xgaIO14V8aOpvI2eXISmjoc+pHB642uWh2LaXdyXBl4HKt+Z 5ul7UGywHML0XwIsP+JVpgdEjnM0kUgMTrf98rqw1lPipLxDdUTvDvGNSKponjuQrYH1 +nR4J/z/Zt3CpgB0gDVB7Tp8ggRgxKI4N6yTyBNE3n2aCXPWCdpnAw0fa7w7nq8eDvIV M9/sIWZuJBt1t3YStpCSzfxV/KYpicAFpd+DgbL55gwBN3gnN4C01Yd+9hr1uW2rpta/ Hl826/OEKmSzbfXPRsGRFfeInNQoNxCjlhgVEpCA6eYg+tBm1RiYGmOW0BRRQ40M7YL7 9g==
Received: from prod-mail-ppoint4 (a96-6-114-87.deploy.static.akamaitechnologies.com [96.6.114.87] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2n5neagxs9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 17 Oct 2018 02:15:17 +0100
Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w9H15IeH017414; Tue, 16 Oct 2018 21:15:16 -0400
Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint4.akamai.com with ESMTP id 2n3c2cyxjg-1; Tue, 16 Oct 2018 21:15:16 -0400
Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id 3F32720069; Wed, 17 Oct 2018 01:15:16 +0000 (GMT)
Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from <bkaduk@akamai.com>) id 1gCaQd-0002UC-GW; Tue, 16 Oct 2018 20:15:15 -0500
Date: Tue, 16 Oct 2018 20:15:15 -0500
From: Benjamin Kaduk <bkaduk@akamai.com>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Cc: tls@ietf.org
Message-ID: <20181017011515.GL7773@akamai.com>
References: <CAO8oSXnv5Gpdw-0c9jXtx1rQqpgwmfrZyiFgHF=Kd5qWZSMPCA@mail.gmail.com> <875zy1czbd.fsf@fifthhorseman.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <875zy1czbd.fsf@fifthhorseman.net>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-16_14:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810170007
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-16_14:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810170008
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/5Y0VcW2wciDqOUzMsymhjwhRTZA>
Subject: Re: [TLS] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 17 Oct 2018 01:15:21 -0000

On Tue, Oct 16, 2018 at 06:16:22PM -0400, Daniel Kahn Gillmor wrote:
> 
> I agree with both Tom and Viktor that the current draft seems to be
> misaligned between the goals and the stated scope.

I also agree that there is some misalignment of this nature.

My attempt at a root cause analysis would be that the current text in
the Introduction is essentially saying "let clients in bad networks do
DANE", but "doing DANE" is a fairly nebulous thing, and if different
people are focusing on "doing DANE" in different ways, we can get into
conflict about whether a specific proposed mechanism advances our
particular goals.


So what is "doing DANE", then?  In the course of the on-list, off-list,
side meeting and interim discussions, I've benefited greatly from
hearing from a lot of experts, and I deeply appreciate the patience and
persistence that the participants thereof have shown in working to
advance a document in this space.  It was not always easy, but I think
we are making progress.

In the context of this discussion, I propose that DANE is a way to allow
a TLS server operator[1] to indicate to a TLS client information about
how the server would like to be authenticated.  The practical effect of
this new source of information depends on what the client would be doing
*without* the DANE information, though, since we have this large
deployed base that is currently not doing DANE but could do DANE in the
future.  If we want to analyze the (security and other) properties of
adding DANE, we must consider both the starting point and the end state.

I suggest that if we limit the stated scope from an open-ended "doing
DANE" to also state which cases of "doing DANE" we have analyzed
(leaving open the possibility for future analysis to confirm the
mechanisms we define as usable in other cases), then we can get a clear
answer on whether the proposed mechanism meets the requirements of each
listed case, without introducing negative externalities for either the
protocol participants or the Internet as a whole.  This is not to
exclude the "greenfield" case, of course -- a list of cases to consider
might include things like:

- client does not currently exist, and insists on receiving DANE records
  via TLS extension; server wants to use TLSA with PKIX-{TA,EE}

- client does not currently exist, and insists on receiving DANE records
  via TLS extension; server wants to use TLSA with DANE-{TA,EE}

- client currently accepts "Web PKI" certificates but is willing to do
  DANE; server wants to use TLSA with PKIX-{TA,EE}

- client currently accepts "Web PKI" certificates but is willing to do
  DANE; server wants to use TLSA with DANE-{TA,EE}

- client currently will opportunistically accept any certificate but is
  willing to apply DANE restrictions; server wants to use TLSA with
  DANE-{TA,EE}

- client currently will opportunistically accept any certificate but is
  willing to apply DANE restrictions; server wants to use TLSA with
  PKIX-{TA,EE}

where I separate out the DANE- and PKIX- usage values since they may
require a separate security analysis.  (If they don't; great, we can
consolidate them in the document.)

I don't think we would necessarily need to come to consensus on which of
these cases are "most important", so long as we can provide a mechanism
that will satisfy the requirements of all cases that we want to list in
the document.

> I wanted the draft to be done by now because i think it will be useful
> in "greenfield" scenarios -- ones where the use case itself can mandate
> the extension without negotiation, but i understand Viktor's point that
> without any sort of negotiated pinning mechanism, the draft is probably
> not useful for non-greenfield scenarios (without pinning the existence
> of the extension, it cannot reduce the attack surface represented by the
> CAs, and instead only represents an additional vector of attack).

Right -- if the client is currently willing to do Web PKI (or worse), an
attacker that can get a bogus Web PKI (or self-signed) certificate could
keep the client ignorant of the true server's preference and get the
client to errenously complete a handshake.  We would like a way to
deprive the attacker of such a capability, though in at least some
situations we cannot do so with 100% reliability.  We could perhaps have
a success criteria for this TLS extension (as a security mechanism),
that it both:

(1) provides a channel for DANE records that is reliable in the absence of
    an attack

and

(2) reduces the ability of an attacker to cause the client to ignore the
    server's authentication preference

I think that just meeting the above two conditions could provide enough
value to merit publishing, even without attempting to add something
like:

(3) allows the client to realistically hard-fail connections where DNSSEC
    validation returns bogus or indeterminate.

Getting (1) is probably trivial (though with middleboxes you never
know), and it seems fairly clear that a pinning scheme can provide (2).
(3) is more subjective and may be hard for us to make any definitive
statements about, hence my proposal to exclude it for now.

-Ben

[1] I feel comfortable consolidating the TLS server operator with the
maintainer of the DNS entr(y|ies) for that server, since the TLSA entries
must reflect the operational reality of the TLS server, and if the two
entities are in conflict either can trivially cause an outage.