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.
- [TLS] Interim notes and draft-ietf-tls-dnssec-cha… Christopher Wood
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Tom Ritter
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Viktor Dukhovni
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Nico Williams
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Daniel Kahn Gillmor
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Viktor Dukhovni
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… John Levine
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Benjamin Kaduk
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Viktor Dukhovni
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Paul Wouters
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Viktor Dukhovni
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Eric Rescorla
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Benjamin Kaduk
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Sean Turner
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Viktor Dukhovni
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Eric Rescorla
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Benjamin Kaduk