Re: [TLS] Enforcing Protocol Invariants

"Salz, Rich" <rsalz@akamai.com> Sun, 18 November 2018 14:30 UTC

Return-Path: <rsalz@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 4BAC41294D0 for <tls@ietfa.amsl.com>; Sun, 18 Nov 2018 06:30:59 -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 kCyHfg8eXs8o for <tls@ietfa.amsl.com>; Sun, 18 Nov 2018 06:30:58 -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 470741277BB for <tls@ietf.org>; Sun, 18 Nov 2018 06:30:58 -0800 (PST)
Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.27/8.16.0.27) with SMTP id wAIEMYjC020129 for <tls@ietf.org>; Sun, 18 Nov 2018 14:30:57 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=M2KaaX4Wp4QK7xWDVAGbvrdwf1KDooxAYoVJovxfUNI=; b=hbnYAAtdJmpNDFdy2U5OExxS5rG4w88+srv/bFYdv5w+oeSJB3XmLau2L68r0/LoDAI1 nQ+GxqaBsNGPVMPWYKrEVZnt1cVBjbWEZk3Nk7Y1DUiv/MaBFG0dbAtl2fWnpn9ndhtc zMgYUYXyPp/6RFdUfsFuhCDJFRTdW+KlORFkS1lI+pHGZ+zDW8JpXLBq8+g6eyJAagls ArE0xYkD0+I5ERTn3eVGmaZkleA2fVvTjJBG1rMh+7nb4J3D3iazj0qZuRl0XYtk6Y0B dVNAfosjTp3limsEmgV6qhyXPB+EVdBeGfo4kIroyjC15YdECm8iBvS6dcFB2YOi/Vhh aw==
Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050102.ppops.net-00190b01. with ESMTP id 2nt8xgd3hs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <tls@ietf.org>; Sun, 18 Nov 2018 14:30:57 +0000
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id wAIEFSjt014655 for <tls@ietf.org>; Sun, 18 Nov 2018 09:30:56 -0500
Received: from email.msg.corp.akamai.com ([172.27.25.30]) by prod-mail-ppoint1.akamai.com with ESMTP id 2ntf6yw8rq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for <tls@ietf.org>; Sun, 18 Nov 2018 09:30:56 -0500
Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.27.107) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Sun, 18 Nov 2018 06:30:55 -0800
Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1365.000; Sun, 18 Nov 2018 08:30:55 -0600
From: "Salz, Rich" <rsalz@akamai.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [TLS] Enforcing Protocol Invariants
Thread-Index: AQHUdz9GESLPHjpeoUu9qsmfgtttFaVUQZsAgAChfYCAANXLgA==
Date: Sun, 18 Nov 2018 14:30:53 +0000
Message-ID: <AF08DB30-144B-427E-9B3E-AC90C4B7E7DB@akamai.com>
References: <CAO7N=i0g9d9x5RdF_guKm3GDAxVRHSV+eHffs6kiJm6dWO7tvw@mail.gmail.com> <CANLjSvXD9_u1UDkRkaNc8fnr=iQYKq73c8j9huMEPnH0XzuU0Q@mail.gmail.com> <D880B51B-ECAB-4158-A0EE-8FF67F9247EC@dukhovni.org>
In-Reply-To: <D880B51B-ECAB-4158-A0EE-8FF67F9247EC@dukhovni.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.13.0.181109
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.34.168]
Content-Type: text/plain; charset="utf-8"
Content-ID: <988D1E8A85F7364D96B71F01299AE05D@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-18_04:, , 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=742 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1811180135
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-18_04:, , 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=739 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1811180136
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/oRylpKnVOIU4GKfHucGz7DYvC9c>
Subject: Re: [TLS] Enforcing Protocol Invariants
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: Sun, 18 Nov 2018 14:30:59 -0000

>    [ FWIW, TLS is trust-model agnostic, it is the WebPKI that uses the
      usual panoply of CAs. ]
 
No, it is not agnostic.  It does support other trust models -- raw keys, PGP web-of-trust -- but it's default and primary model from its inception is X509 and its (so ingrained you might consider it implicit) "trust the issuer" model.  Look at the definitions of certs and CA's and things like path validation in PKIX and its predecessors, the "trust anchors" which builds on the chain model -- chained through *issuers* -- in the protocol, and so on.

The "usual panoply of CAs" is the WebPKI instantiation of a trust model, but do not confuse it with the trust model itself. I have deployed several instances of the X509/PKI trust model at work, and none of them use a conventional WebPKI set of anchors.

If DANE-TLS is to come back, the authors should use a new TLS certificate type that is perhaps an X509 structure, but whose trust semantics are defined by DANE. The recent IEEE vehicle cert did similar, and all it took was a couple of pieces of email.