Re: [TLS] some thoughts on dnssec-chain-extension, pinning, and broader semantics

Benjamin Kaduk <bkaduk@akamai.com> Tue, 06 November 2018 03:27 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 1BBFD1276D0 for <tls@ietfa.amsl.com>; Mon, 5 Nov 2018 19:27:52 -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 Keo4cvLa025K for <tls@ietfa.amsl.com>; Mon, 5 Nov 2018 19:27:51 -0800 (PST)
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 35812127148 for <tls@ietf.org>; Mon, 5 Nov 2018 19:27:51 -0800 (PST)
Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.27/8.16.0.27) with SMTP id wA63LrsD018615; Tue, 6 Nov 2018 03:27:50 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=6PL1zl0LB50Dzq5KizkwCtkRUWlFbJsuvdMQKDOZGac=; b=NfhFkWdDOR8Fa2pRsFxb4/HXkVMvy7KY8sPKeCvlWxTkJqsgefS4x2INGEJVgqCKasDj lFnnXdbq0gh/rtmqSwcjHpq3DqZtj2onM6Bg1znWqguzDq0mC9U9TdbL9qB01+xJEgoj A4myvYScHSxljcQgsrInrQ8m/sklnfNFrXhGpdyVTVm+kVbPwU99Dt2oZYCOt4lAHBnZ LilsKJOWGoaDD0thd81jdqPMvRlgjO8XbDgQP1uWla4XA51w1+ivnpuFLwHO7TAg8rTX UoB2Of44MAUuSSu8rp2wCpOTMkzgBiEp789O4RQQ2+M8duxocXA/5Fa8NgzyjPddkt9c pA==
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 2njyaa0jxm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 06 Nov 2018 03:27:50 +0000
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 wA63JwiU002952; Mon, 5 Nov 2018 22:27:49 -0500
Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint4.akamai.com with ESMTP id 2njxerru2u-1; Mon, 05 Nov 2018 22:27:49 -0500
Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay14.akamai.com (Postfix) with ESMTP id 0991E81460; Tue, 6 Nov 2018 03:27:49 +0000 (GMT)
Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from <bkaduk@akamai.com>) id 1gJs1r-0006vw-Ug; Mon, 05 Nov 2018 21:27:47 -0600
Date: Mon, 05 Nov 2018 21:27:47 -0600
From: Benjamin Kaduk <bkaduk@akamai.com>
To: Paul Wouters <paul@nohats.ca>
Cc: "Salz, Rich" <rsalz@akamai.com>, "<tls@ietf.org>" <tls@ietf.org>
Message-ID: <20181106032747.GF4141@akamai.com>
References: <20181105130157.GF54966@kduck.kaduk.org> <2714F93F-3658-4E2E-8390-284C6D401447@dukhovni.org> <1450B335-5F7D-43A6-8BC6-181DFE1865C9@akamai.com> <alpine.LRH.2.21.1811052149490.3332@bofh.nohats.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <alpine.LRH.2.21.1811052149490.3332@bofh.nohats.ca>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-06_01:, , 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-1811060026
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-06_01:, , 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=1011 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-1811060026
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/3UvrpQ6BwBk5GwgTp25mg0NN9Ao>
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: Tue, 06 Nov 2018 03:27:52 -0000

On Mon, Nov 05, 2018 at 09:54:19PM -0500, Paul Wouters wrote:
> On Mon, 5 Nov 2018, 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?
> 
> The draft tries to enable a trust model based on DNSSEC, but due to
> missing pinning, fails to deliver that.
> 
> A better way is saying the draft enables a trust model that restricts
> the webpki, addressing the problems of too many unrestricted root CA
> players being accepted by  TLS clients these days [provided the draft
> adds a mechanism like pinning to prevent downgrade attacks]

If we don't agree on what the draft is trying to do, it seems rather
difficult to attempt to claim that there is WG consensus to publish it.

This seems to suggest that we may need more precise text in the
document about what it is (and is not) trying to do.  The slides Sean
posted for the Wednesday session note that fairly early in the timeline
we thought:

    Primarily aimed at making
    DANE practical for HTTPS,
    where last-mile considerations
    on the client end are a
    significant part of the adoption
    barrier.

Paul, are you proposing that this would only be PKIX-{EE,CA} to the
exclusion of DANE-{EE,CA}?  (In terms of "restricts the webpki".)

Thanks,

Ben