Re: [TLS] draft-green-tls-static-dh-in-tls13-01

Benjamin Kaduk <bkaduk@akamai.com> Mon, 17 July 2017 16:35 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 7B127131CB9 for <tls@ietfa.amsl.com>; Mon, 17 Jul 2017 09:35:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 knOFe44UGKOp for <tls@ietfa.amsl.com>; Mon, 17 Jul 2017 09:35:15 -0700 (PDT)
Received: from mx0b-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 9CC9C131CA3 for <tls@ietf.org>; Mon, 17 Jul 2017 09:35:15 -0700 (PDT)
Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6HGW7I7005506; Mon, 17 Jul 2017 17:35:11 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=FsPH9arT9YgOimnixtpQASIE2hBzJWgDp1T9eQ32cnY=; b=nk8CTO/JM9pFAAb2fjAvPCSdav6SqLpPaV9WSMSNwSe9LpLQvbJwsv4ROSWbded6yeBy G3fqA4oyPghsfkjQ2JoYcMyBJCQwmQMwpEMN+hBE3BSFMGxJgrFeEdGc0NyynU7Z17c+ MLXx/rn+22FZHUtBtqs5BB/CCk/PVZT52/kp4IeDyMrwt2FR7qdBQEzNg0i8YCm3tVQb wkOd8m/5X7FX4Jea1f6nyn4uwViJjh4Ix+v1SAsjuGW5Is5U376YAOv2T9UrK5D5xwvS YgtPMzuyR3FsQSfI5yGPl6M4bxcOFDoM9MxinY29T8QvVibVsg8dLO+V4i/KYznBXh2W ZQ==
Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050093.ppops.net-00190b01. with ESMTP id 2bqaarrtev-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 17 Jul 2017 17:35:11 +0100
Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6HGUgx7012983; Mon, 17 Jul 2017 12:35:10 -0400
Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint3.akamai.com with ESMTP id 2bqecvef89-1; Mon, 17 Jul 2017 12:35:09 -0400
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id 2937B20107; Mon, 17 Jul 2017 10:35:09 -0600 (MDT)
To: Yoav Nir <ynir.ietf@gmail.com>, Roland Dobbins <rdobbins@arbor.net>
Cc: "tls@ietf.org" <tls@ietf.org>, Matthew Green <matthewdgreen@gmail.com>
References: <CAPCANN-xgf3auqy+pFfL6VO5GpEsCCHYkROAwiB1u=8a4yj+Fg@mail.gmail.com> <87o9smrzxh.fsf@fifthhorseman.net> <CAAF6GDc7e4k5ze3JpS3oOWeixDnyg8CK30iBCEZj-GWzZFv_zg@mail.gmail.com> <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com> <CAAF6GDeSv+T1ww5_nr6NPgg9k44j7y04tJWC=KeaJF7Gtt+TVQ@mail.gmail.com> <9bd78bb6-1640-68f6-e501-7377dd92172f@cs.tcd.ie> <CAAF6GDeGKEBnUZZFXX0y0a2J2+sVg8VaHh-4H9bhN0Zzk-x9uA@mail.gmail.com> <6707e55d-63d3-01e2-4e98-5cc0644e29e0@cs.tcd.ie> <35f4c84c6505493d8035c0eaf8bf6047@usma1ex-dag1mb1.msg.corp.akamai.com> <CAAF6GDcq6_ML3yHSQTy-t5irYLS10VVzk_R+7nAUKqQpgcCkrQ@mail.gmail.com> <CAPt1N1m_Zi_2faa8KHcXnic4QjXCEDkwnf=RTbo-Crvh6nMC+g@mail.gmail.com> <CAAF6GDfmoFwQSHEF79AmSDBE6W6FwCu2=n-SU7sHipfsfVTeUg@mail.gmail.com> <a5ba6836cab6417c949d536f2a2542bb@usma1ex-dag1mb1.msg.corp.akamai.com> <52C47C57-DFCB-4378-8C7C-6D8A5AFF3075@arbor.net> <09C9DBF3-75F3-4B59-8522-7ED0D0BA3AD5@gmail.com>
From: Benjamin Kaduk <bkaduk@akamai.com>
Message-ID: <8013b86e-fbaf-cbd2-8680-fae37b71ec39@akamai.com>
Date: Mon, 17 Jul 2017 11:35:08 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <09C9DBF3-75F3-4B59-8522-7ED0D0BA3AD5@gmail.com>
Content-Type: multipart/alternative; boundary="------------35BD30273F55EAF089D55F3D"
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-17_12:, , 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-1706020000 definitions=main-1707170265
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-17_12:, , 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-1706020000 definitions=main-1707170265
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/XB94gnOjeCbzRoCRkYsw83blmKg>
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
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: Mon, 17 Jul 2017 16:35:17 -0000

On 07/17/2017 10:18 AM, Yoav Nir wrote:
>> On 17 Jul 2017, at 17:06, Roland Dobbins <rdobbins@arbor.net> wrote:
>>
>> On 16 Jul 2017, at 11:19, Salz, Rich wrote:
>>
>>> The key point here is Within the enterprise.
>> +1
> It’s an illusion that inside the enterprise uses different technologies than outside the enterprise. IP was for outside, and yet it’s all over the inside.
>
> In the end, either this is in OpenSSL (perhaps plus a patch) or it’s not. Either it’s in SChannel or it’s not. Either F5 have it or they don’t.
>
> If it’s not, it will be impossible to deploy in the enterprise network. They’re not all going to implement it themselves. And if it is, then it’s on the open Internet, and then at least some people will have it turned on. The border between the enterprise and the non-enterprise is pretty blurry.
>

Right, and that's the core motivation for a lot of the fierce resistance
this draft is experiencing.

Fundamentally, we are here talking about things at the Internet
Engineering Task Force.  We have an Internet threat model, partially
manifested in things like RFC 7624 but largely just latent institutional
knowledge, that includes a hostile network.  We know that Internet
protocols get used in Intranets as well, but that is not the main use
case for our work, and only a small portion of the scenarios that we
must consider when designing Internet protocols.  On at least many
Enterprise Intranets, the threat model is different from the one we
generally use for designing Internet protocols, so there is an impedance
mismatch between what features are desired or seen as problematic on the
Intranet and the Internet.

Because the risks/disadvantages of the current proposal, when applied to
the Internet as a whole, are so large, there is a lot of pushback, and a
desire to provide strong assurances that any proposal in this space does
not leak from the Intranet onto the Internet, both at a protocol level
and a implementation level.  If there was a scheme that
cryptographically required input from both TLS client and server in
order to enable the needed "key exfiltration" (or equivalent) for the
Intranet use case, that seems like it would resolve most of the concerns
being raised.  Unfortunately, it seems really hard to come up with
something like that, when there are so many options that are unilateral
for the server.

This is not just a question of "we promise we'll only use it on the
Intranet" because of the reasons Yoav states above -- even though I
assume that everyone participating in this thread is acting in good
faith, once the capability is in popular software packages, it could
easily be enabled accidentally on the Internet, or coercively required
of certain entities, e.g., by national security letter, once enablement
is just a configuration setting (as opposed to writing code).

So, in order to have something that is verifiably opt-in by both
parties, it seems like it would have to be a ClientHello/ServerHello
extension (included in the transcript for the generated traffic keys)
where both sides commit that they are willing to exfiltrate keys to a
given named entity(ies) (whether that's by raw public key, certificate
name, etc., is quite flexible).  Because of the key schedule (the
traffic keys are produced after that point in the handshake), it seems
like such a scheme would require encrypting DH private values to the
third party (and potentially a PSK as well).

I'm curious whether a non-handwavy writeup of such a scheme would get a
better reception than draft-green-tls-static-dh-in-tls13 is getting.  It
does lose forward secrecy for the traffic in question, but such traffic
is clearly marked, and rotating the third-party key sufficiently often
could regain some forward secrecy properties.  (Of course I'm also
interested in hearing if that is not feasible for the Enterprise case
since I don't understand those requirements very well.)  But it seems
that we're not really getting anywhere just arguing about the current
proposal (and repeating ourselves a lot), and proposing concrete
alternatives (that do not require rearchitecting the enterprise
networks) might be a way to make progress.

(It's still unclear whether such a scheme would be acceptable as a WG
item or Standards-Track, of course.)

-Ben