IETF Logo Mail Archive

Re: [TLS] Draft RHRD

"Salz, Rich" <rsalz@akamai.com> Wed, 01 November 2017 16:27 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 EC66913F7FA for <tls@ietfa.amsl.com>; Wed, 1 Nov 2017 09:27:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 dMLXT7Yr7V-a for <tls@ietfa.amsl.com>; Wed, 1 Nov 2017 09:27:22 -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 7D11C13F7A6 for <tls@ietf.org>; Wed, 1 Nov 2017 09:27:21 -0700 (PDT)
Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id vA1GP2pn025896; Wed, 1 Nov 2017 16:27:18 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=VOuVciEHVAwGbHbwZAdo+maScx2fMBfsSy2rLWKkMiM=; b=BV7xA6Nqhqk6jdmA3Uh+Wh1j6MTMp2qoz6N0dXUi2+RTD8omju0cOZNVDmrxJ1i4YXlu TFdz+REOJ4I8qU+HlryfBxKpNLQK6XJ3wg4n9HF4QulvkABtNPkMOJAHIlhA2Y42/M2Q AHb3HXVr22i+1F4fuYaZQaX7J9rBynQjsJOBhBZAyxca1CPVVP9OzIoYe0dSxQ81uRYC s5slztps09ZAIkJN38euKD1Y0c3X3QHrVzdmu/5yCbZLWhdw0gjuwy+/mvDIWaAMogjX ost4/5jRcDuZN/KRD9E0xX95dH436euBIJB1cp6XTeuK3ELF3l5uuJPVTWEKfU8RvNl7 QQ==
Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050096.ppops.net-00190b01. with ESMTP id 2dvmwkfb3r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 01 Nov 2017 16:27:17 +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 vA1GGU0o009575; Wed, 1 Nov 2017 12:27:17 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2dvn7uuxa5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 01 Nov 2017 12:27:17 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 1 Nov 2017 12:27:16 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Wed, 1 Nov 2017 12:27:16 -0400
From: "Salz, Rich" <rsalz@akamai.com>
To: Nick Sullivan <nicholas.sullivan@gmail.com>
CC: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Draft RHRD
Thread-Index: AQHTUyukRAt1aB3Y8ka0ENvf7zGMLqL/+UYA
Date: Wed, 01 Nov 2017 16:27:16 +0000
Message-ID: <5D22EE0B-248C-4614-99B5-0007E8E72E2B@akamai.com>
References: <C2DD7992-0A5A-4970-8DDB-DBA651B4D6D7@akamai.com> <CAOjisRzBarfdVPf4OaQ_7PeL+dGsv5stw-ofCPC2bGU16HHr_g@mail.gmail.com>
In-Reply-To: <CAOjisRzBarfdVPf4OaQ_7PeL+dGsv5stw-ofCPC2bGU16HHr_g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.27.0.171010
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.35.44]
Content-Type: multipart/alternative; boundary="_000_5D22EE0B248C461499B50007E8E72E2Bakamaicom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-01_03:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711010219
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-01_03:, , 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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711010219
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/78UNWj-_kvOATSl4mFO-ZSakbAE>
Subject: Re: [TLS] Draft RHRD
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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, 01 Nov 2017 16:27:24 -0000

  *   I think you're mixing things up a bit.

That’s quite possible.


  *   I'm comparing draft-rhrd to draft-green. The wireshark option requires storage of n keys to inspect n connections, both draft-rhrd and draft-green only require a single master key to inspect n connections.

Draft-green requires limited use of ECDH keys, so that they can be sent to the third party.  Draft-rhrd allows limited use, but does not require it.  It allows a great deal of flexibility, from one key for days, to one key for each session.  Right?

We can’t control what a server will do, and we never could.  No matter how much we jump up and down and say “don’t give away the keys unless you see the RHRD extension” we’ll never know.  An unforceable rule is a very bad rule and shouldn’t be a rule.  Draft-green is much more intellectually honest, and doesn’t provide the cleartext signal.



  *   Your rejection of the cleartext signal expresses implies a preference for draft-green over draft-rhrd, not a preference for the wireshark option over draft-rhrd. Without draft-rhrd, it's likely that draft-green gets implemented whether it's standardized or not and no client will be able to opt out or even know that it's happening.

Yes; I am surprised that’s being questioned, but after this note it should be obvious to all.  In fact, I think it was before Matt’s proposal that I stood at the mic and said we should treat it like prohibition: “this is grape juice, but if you do this… and this… and this… it will become wine. That’s illegal so don’t do that.”



  *   Users won't have any option, or any knowledge that servers are using a master key to protect the
confidentiality of their connection and that their security may be lessened because of it

They still don’t. We might all like to think that they do, but with or without either draft, there is no way to ensure anything about the server’s behavior beyond the bits it sends on the wire.  It was always so, and hoping that some text will make it more than this is a disservice to the end users.

v2.23.0 | Report a Bug | By Email