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

Benjamin Kaduk <bkaduk@akamai.com> Mon, 17 July 2017 16:39 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 C6FEA131B33 for <tls@ietfa.amsl.com>; Mon, 17 Jul 2017 09:39:27 -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 EPLBY4nfR8qj for <tls@ietfa.amsl.com>; Mon, 17 Jul 2017 09:39:26 -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 8EAB3131A88 for <tls@ietf.org>; Mon, 17 Jul 2017 09:39:26 -0700 (PDT)
Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6HGb1rU016408; Mon, 17 Jul 2017 17:39:21 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : from : to : cc : references : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=8vyDAEqT++ADChJUvQB1o4kGhExNuQciHy+EIeDBCP4=; b=HhPiT4WeTWNItjra5aesvYtPfjO9KDrfuK1FCrYM2lF2t1tzq0M42XOV9+e5dO+zEK1e GXypBhBg+mkNGkeHDmmeYD9gyIJIG2gvHWEM1oOFviGDbdNlK6poFdyuyvZW5y0/i9M0 0CSaiqlwAH3f0XjsG6O4AZQkk/L/mXg+qheyf/3HhpOr7uO08WqnqERxwaAGZ5o3NzF5 /e1vZLP1fPgufa/eA7BiI7gF49af1c5uzeITxEDAHQ6Au2bDWd3WdcAFGYp1EHY5hfBP /Mknv0JLe5HAAPsEIDH+flkM1hqQhpFLeS4fUsYtUfR+w6KQt3zJRYIrLS1h7HYFWQ8M xw==
Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2bq84d9000-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 17 Jul 2017 17:39:20 +0100
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6HGZnp2022497; Mon, 17 Jul 2017 12:39:19 -0400
Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint2.akamai.com with ESMTP id 2bqecun0am-1; Mon, 17 Jul 2017 12:39:19 -0400
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 8BFC11FC73; Mon, 17 Jul 2017 16:39:19 +0000 (GMT)
From: Benjamin Kaduk <bkaduk@akamai.com>
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> <8013b86e-fbaf-cbd2-8680-fae37b71ec39@akamai.com>
Message-ID: <8123085b-897f-7455-ca4b-383087c73171@akamai.com>
Date: Mon, 17 Jul 2017 11:39:19 -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: <8013b86e-fbaf-cbd2-8680-fae37b71ec39@akamai.com>
Content-Type: multipart/alternative; boundary="------------FDE339784AA0ED9C8F0E0D42"
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-1707170266
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-1707170266
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/CENiEKA_E3KAJFXzMPv_C-iv_Ww>
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:39:28 -0000

On 07/17/2017 11:35 AM, Benjamin Kaduk wrote:
>
> 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).

Whoops, a little too hand-wavy, since only one DH private value is
needed to generate the shared secret.  But it's "easy" to have some
crypto that requires both contributions, especially if you are willing
to modify the key schedule for the traffic keys.

-Ben