Re: [TLS] some thoughts on dnssec-chain-extension, pinning, and broader semantics
Benjamin Kaduk <bkaduk@akamai.com> Mon, 05 November 2018 15:30 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 18677130DD2 for <tls@ietfa.amsl.com>; Mon, 5 Nov 2018 07:30:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.172
X-Spam-Level:
X-Spam-Status: No, score=-1.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, 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 iygJIrdrxq7L for <tls@ietfa.amsl.com>; Mon, 5 Nov 2018 07:30:24 -0800 (PST)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::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 7C88E12D7F8 for <tls@ietf.org>; Mon, 5 Nov 2018 07:30:21 -0800 (PST)
Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.27/8.16.0.27) with SMTP id wA5FRV1o021376 for <tls@ietf.org>; Mon, 5 Nov 2018 15:30:21 GMT
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=H6A/AETPIXur+5XRTOoLZpacJMBnJVU7mlHwpSzwWVI=; b=CLd72WWS6GnBkCfDjjt1Pnc7ZlNzsYnDdcALHuf24vPIEbN3fI3w958dwXW9O6zqTbZk zK+BawLkEaJDp1MIgOgjj8U4iTKMZKnhZS1YxId2Jt4f9Z+eexmFpOzu0lpGmQVakOGH wWVgb33H1QoLxG+7iUdxPd/aSGBUeMmmySH4Wj9LIsSXbahsUXGDf0Dgj95hRa2x5Ia2 Rf2MyMpaKBg7GGcB1Uwv6vIPfPD7QLN4DFHBzAAvz4Poyms9GKgCIjfakKn9diJDle6t KmFdjc6Dd92NEz6WbvcUU/w+fb7hJaMfkVLJjWSVWGCBWmY7c7tKCuLpDF40CLrF3dy3 7Q==
Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050095.ppops.net-00190b01. with ESMTP id 2nht2qvf9q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <tls@ietf.org>; Mon, 05 Nov 2018 15:30:20 +0000
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id wA5FK5XA005267 for <tls@ietf.org>; Mon, 5 Nov 2018 10:30:19 -0500
Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint2.akamai.com with ESMTP id 2nh70vaddw-1 for <tls@ietf.org>; Mon, 05 Nov 2018 10:30:18 -0500
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 CB5632006B; Mon, 5 Nov 2018 15:22:34 +0000 (GMT)
Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from <bkaduk@akamai.com>) id 1gJgi1-0004BV-WE; Mon, 05 Nov 2018 09:22:34 -0600
Date: Mon, 05 Nov 2018 09:22:33 -0600
From: Benjamin Kaduk <bkaduk@akamai.com>
To: "Salz, Rich" <rsalz@akamai.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Message-ID: <20181105152233.GD4141@akamai.com>
References: <20181105130157.GF54966@kduck.kaduk.org> <2714F93F-3658-4E2E-8390-284C6D401447@dukhovni.org> <1450B335-5F7D-43A6-8BC6-181DFE1865C9@akamai.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <1450B335-5F7D-43A6-8BC6-181DFE1865C9@akamai.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-05_08:, , 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-1811050140
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-05_08:, , 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-1811050142
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/AcCoZJ31IkujFM1C6jgHJTs_qTQ>
Subject: Re: [TLS] some thoughts on dnssec-chain-extension, pinning, and broader semantics
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: Mon, 05 Nov 2018 15:30:25 -0000
On Mon, Nov 05, 2018 at 02:37:26PM +0000, Salz, Rich wrote: > Is it fair to describe the draft as enabling a trust model based on DNSSEC, rather than the default X.509 hierarchy and trust store which is implemented by default? > > Please try very hard to keep the answer brief. In my mind that's one of the things it could do, but need not be the only one. In https://www.ietf.org/mail-archive/web/tls/current/msg27088.html I tried to consider the possibility for clients that currently default to the X.509 hierarchy but also clients that use opportunistic TLS or other default behaviors. The analysis of the security properties of adding DANE depends on what we use as a starting point. -Ben
- [TLS] some thoughts on dnssec-chain-extension, pi… Benjamin Kaduk
- Re: [TLS] some thoughts on dnssec-chain-extension… Viktor Dukhovni
- Re: [TLS] some thoughts on dnssec-chain-extension… Salz, Rich
- Re: [TLS] some thoughts on dnssec-chain-extension… Benjamin Kaduk
- Re: [TLS] some thoughts on dnssec-chain-extension… Viktor Dukhovni
- Re: [TLS] some thoughts on dnssec-chain-extension… Nico Williams
- Re: [TLS] some thoughts on dnssec-chain-extension… Viktor Dukhovni
- Re: [TLS] some thoughts on dnssec-chain-extension… Paul Wouters
- Re: [TLS] some thoughts on dnssec-chain-extension… Benjamin Kaduk
- Re: [TLS] some thoughts on dnssec-chain-extension… Paul Wouters
- Re: [TLS] some thoughts on dnssec-chain-extension… Viktor Dukhovni
- Re: [TLS] some thoughts on dnssec-chain-extension… Benjamin Kaduk
- Re: [TLS] some thoughts on dnssec-chain-extension… Benjamin Kaduk
- Re: [TLS] some thoughts on dnssec-chain-extension… Tim Wicinski
- Re: [TLS] some thoughts on dnssec-chain-extension… Viktor Dukhovni
- Re: [TLS] some thoughts on dnssec-chain-extension… Nico Williams
- Re: [TLS] some thoughts on dnssec-chain-extension… Paul Wouters
- Re: [TLS] some thoughts on dnssec-chain-extension… Paul Wouters