Re: [TLS] Security review of TLS1.3 0-RTT

Timothy Jackson <tjackson@mobileiron.com> Wed, 03 May 2017 18:35 UTC

Return-Path: <tjackson@mobileiron.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 E1D52129BD1 for <tls@ietfa.amsl.com>; Wed, 3 May 2017 11:35:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mobileironinc.onmicrosoft.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 j8ra3_al4y0R for <tls@ietfa.amsl.com>; Wed, 3 May 2017 11:35:43 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0076.outbound.protection.outlook.com [104.47.36.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0642B129B40 for <tls@ietf.org>; Wed, 3 May 2017 11:33:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mobileironinc.onmicrosoft.com; s=selector1-mobileiron-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=69rMsJeAXx+us/9xMnb+cjMmXDYgyulWDPI0U1f1F44=; b=uL3+Fq83V0gI/4rMu+ncoszYTFxaQnYhORn+LcSOwx/rlQGUfEEIJBoIBZcxAT0w3snDOhKTt4h2DczrKNu4dq6ecRXujsMPQDM5XRbdnFu0vWxNytLcFdOMG2Bzd0FlhUm0ErXk+ztfPnH3EAN9jG6yJLD9xvEsqZz7Xko1AZA=
Received: from CY4PR10MB1734.namprd10.prod.outlook.com (10.172.69.9) by CY4PR10MB1733.namprd10.prod.outlook.com (10.172.69.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.11; Wed, 3 May 2017 18:33:33 +0000
Received: from CY4PR10MB1734.namprd10.prod.outlook.com ([10.172.69.9]) by CY4PR10MB1734.namprd10.prod.outlook.com ([10.172.69.9]) with mapi id 15.01.1075.010; Wed, 3 May 2017 18:33:33 +0000
From: Timothy Jackson <tjackson@mobileiron.com>
To: Nico Williams <nico@cryptonector.com>, TLS WG <tls@ietf.org>
Thread-Topic: [TLS] Security review of TLS1.3 0-RTT
Thread-Index: AQHSw1NKNF5IQ29vr0umUMeDlmEnG6HiVNeAgAA6vACAAAYmAIAAJaUAgAAJboCAAAGuAIAAAlsAgAAnCwD//4usgA==
Date: Wed, 03 May 2017 18:33:33 +0000
Message-ID: <51724E2C-45A3-4A18-A5FE-0A6B33C23077@mobileiron.com>
References: <CAAF6GDcKZj9F-eKAeVj0Uw4aX_EgQ4DuJczL4=fsaFyG9Yjcgw@mail.gmail.com> <cb518e35-c214-d11d-a068-c454b2e7ea6a@gmx.net> <CAAF6GDfQ+YXV4gvhBOOZKC=wtYhxQUy1_2_M+dgfbdL25pppiQ@mail.gmail.com> <BCD73E79-0675-4B71-92B4-3226F0BAB597@dukhovni.org> <CAAF6GDdpq8DgLx5Fo6apoTHgwQsbdn6hb=ozi1+JP9VMxPw6sA@mail.gmail.com> <539D071B-7DDD-4820-A9E4-EC178400B7B2@dukhovni.org> <420471d6016a41ecbcdf9562be303f62@ustx2ex-dag1mb1.msg.corp.akamai.com> <17414FC2-15BB-4A03-8673-7F8299E5428E@dukhovni.org> <20170503182955.GR10188@localhost>
In-Reply-To: <20170503182955.GR10188@localhost>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: cryptonector.com; dkim=none (message not signed) header.d=none;cryptonector.com; dmarc=none action=none header.from=mobileiron.com;
x-originating-ip: [198.61.62.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR10MB1733; 7:fY1ZqAcJkppFucsUaGmCbYzOH9jj6E97Mn1sg/N0uKAVFnt/5k2VjH8YxK2avg/DG1WRLrQPUnSBz/uDMV5C8qQmsCPcA6yPqociFqYw8odqAeGuP5s6XsRk2OerQ9G7de3QXQzf7z+qZ9ZysIfBZOHYwFOftcuj9TBEfE55eajiZccgbNd39rsqJwlsmazOW1OFteE/TqWxTHRldEmWzdKSvIbyFVMrWekgWuV6SxTmqUfzHIwXOZyHj8/06lDFnAGY5NJ70Yri3iAX/YOIct09WZ8xbun1G3d2rHpQ1iTrqGh0kBABynZAEpaGDlg6Wh0oLkQFzPTm3lX33LvtGA==
x-ms-office365-filtering-correlation-id: 3be4bd97-2714-4977-f053-08d49252e78c
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:CY4PR10MB1733;
x-microsoft-antispam-prvs: <CY4PR10MB17330941CFFB61CABCA3DF18AA160@CY4PR10MB1733.namprd10.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(192374486261705);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148); SRVR:CY4PR10MB1733; BCL:0; PCL:0; RULEID:; SRVR:CY4PR10MB1733;
x-forefront-prvs: 029651C7A1
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39850400002)(39450400003)(39410400002)(39400400002)(24454002)(377454003)(36756003)(2900100001)(93886004)(6512007)(6306002)(15650500001)(122556002)(99286003)(478600001)(3660700001)(81166006)(53546009)(86362001)(38730400002)(6246003)(189998001)(25786009)(53936002)(7736002)(6116002)(6436002)(76176999)(8936002)(50986999)(3846002)(54356999)(102836003)(305945005)(8676002)(33656002)(229853002)(6486002)(2950100002)(2906002)(6506006)(77096006)(5660300001)(3280700002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR10MB1733; H:CY4PR10MB1734.namprd10.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <52CA0D9172EEA24794695A7D2104D255@namprd10.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: mobileiron.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2017 18:33:33.3667 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8392379d-8a98-4cb4-8cfe-5e7fa92e4e60
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR10MB1733
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/8ns-SpFnQWnKF_SUq89qQp979l8>
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
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, 03 May 2017 18:35:48 -0000

>    The (mis)use of long-term STEKs is not particularly special among such practices.

This may be true, but that still doesn’t make it a good idea. We should probably do *something* about this. J

>    The protocol design should avoid setting traps for the unwary.    
>    If libraries implement "long-term" STEKs, that's a library bug, not a protocol issue.

Seems to me that both points are valid and not mutually exclusive. Why don’t we capture this discussion in the RFC itself? We often provide guidance/alerts for implementers. Why should this be different? Such a warning would presumably prevent it from being a trap for the unwary (or unweary, depending on how much rest they’ve gotten) without requiring a change to the protocol itself. 

We could even go so far as to add a “SHOULD NOT” around using STEKs that are long-lived? That would provide a strong hint to implementers but leave flexibility for those who need different behavior and understand the risks?

Cheers,

Tim
—
Tim Jackson | Product Security Architect | MobileIron, Inc.

On 5/3/17, 11:29 AM, "Nico Williams" <nico@cryptonector.com> wrote:

    On Wed, May 03, 2017 at 12:10:12PM -0400, Viktor Dukhovni wrote:
    > > On May 3, 2017, at 12:01 PM, Salz, Rich <rsalz@akamai.com> wrote:
    > > The protocol design should avoid setting traps for the unwary.
    > 
    > No, that responsibility falls on libraries.  STEKs are not a trap for the
    > unweary.  Libraries that support static session tickets by default can be
    > viewed as such a trap.  So the onus to fix this is on us (OpenSSL team)
    > not the TLS protocol.
    
    A big +1 to this.
    
    I think it would terrible if we couldn't have resumption at all because
    one common implementation mishandles old key deletion.
    
    Nico
    -- 
    
    _______________________________________________
    TLS mailing list
    TLS@ietf.org
    https://www.ietf.org/mailman/listinfo/tls