Re: [TLS] PR#625: Change alert requirements
Timothy Jackson <tjackson@mobileiron.com> Wed, 07 September 2016 18:57 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 9BD9612B117 for <tls@ietfa.amsl.com>; Wed, 7 Sep 2016 11:57:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level:
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 yN1m1o5ODvQE for <tls@ietfa.amsl.com>; Wed, 7 Sep 2016 11:57:46 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0084.outbound.protection.outlook.com [104.47.41.84]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B442012B2C9 for <tls@ietf.org>; Wed, 7 Sep 2016 11:57:45 -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=Kc1bPBJT/D/B4EbAsalYTJGRcmOqDxq9XeAnnEfp0HA=; b=1XW56y9UdaYUzkupv3XSei1QRGVFHo5arK9P5cKt6SA730LMb8rWrrqLLL58yhQcr9J9hoJQbgeahwsNWOvRI4BjTTw9v4I3gNNZhk4sm6oJvgBUc3Y1diigONROPTBw5+TpjQ1BC2Kle9pi/4XeXeaaszfKWMGuL10gOBkXGHs=
Received: from BN6PR10MB1524.namprd10.prod.outlook.com (10.173.31.18) by BN6PR10MB1523.namprd10.prod.outlook.com (10.173.31.17) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.599.9; Wed, 7 Sep 2016 18:57:43 +0000
Received: from BN6PR10MB1524.namprd10.prod.outlook.com ([10.173.31.18]) by BN6PR10MB1524.namprd10.prod.outlook.com ([10.173.31.18]) with mapi id 15.01.0599.016; Wed, 7 Sep 2016 18:57:43 +0000
From: Timothy Jackson <tjackson@mobileiron.com>
To: David Benjamin <davidben@chromium.org>, Eric Rescorla <ekr@rtfm.com>, Andrei Popov <Andrei.Popov@microsoft.com>
Thread-Topic: [TLS] PR#625: Change alert requirements
Thread-Index: AQHSB5/gdixB194trkK9mLH+7eAB3qBuRNSAgAADxwCAAAnyAIAABw8AgAAAKoCAAAc/gP//jc4A
Date: Wed, 07 Sep 2016 18:57:43 +0000
Message-ID: <66936A3E-6DF5-4CF9-A248-01F002D5DD82@mobileiron.com>
References: <CABcZeBMeLgqjvr2cjWL=AHTQJbS9siNBB6U2=0654yigbBGkYA@mail.gmail.com> <1558569.9rZYFBiQ0G@pintsize.usersys.redhat.com> <CABcZeBMCkSJ1nGfZDjx3CJcUsLhH4AMZ=0wOc+uNs0YKu6kW1Q@mail.gmail.com> <3902031.op4bE2I96X@pintsize.usersys.redhat.com> <DM2PR0301MB0847A61D65DBF3AEC2149E168CF80@DM2PR0301MB0847.namprd03.prod.outlook.com> <CABcZeBNLSTMT6ARTyXAAXzHJujzxrn7Sc6NwDTSQBS8VCvqe0w@mail.gmail.com> <CAF8qwaDbroqSfMs5fHeRSWnaZCj=U9dgxDSX9z8Pn_=H9-e3BQ@mail.gmail.com>
In-Reply-To: <CAF8qwaDbroqSfMs5fHeRSWnaZCj=U9dgxDSX9z8Pn_=H9-e3BQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=tjackson@mobileiron.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [198.61.62.10]
x-ms-office365-filtering-correlation-id: 85a9b39b-2218-4fd9-2cad-08d3d750d982
x-microsoft-exchange-diagnostics: 1; BN6PR10MB1523; 6:YIdJ2n6MYinUbBdVAkBucaH7YfMmhvVKg01ESysZLQlllkJDFtKfCjZARj9HruULsren9XsPs4XvbyBtnolAn2vlxihNRnYq8OAmZgpgA3T1bdtJ0fXjjlUI1i+r6Yrg6ldXilGwhQWloghpvNulySeGCQlH3G11uq3VhnIXa4jCYKiQRnitLAbGdINi/qB6UvxzdDw5lYKzuy/Dy+bC2YzNNUOx2olbQZYaKo/lG3gAjHFGHLaZI8Nc8+AtvoVQsl+nHFvhyw+2s6kz87A8KqZyOqcMgit+V3dhZfpWBi4=; 5:fLjXU8P5SxsoaxZ5TIu1n751MXamcuFqhrFp54idgmNJsz/EKou6CysKmT2BaHuFmW14bd/rMs0VWl/MdydjOfQelxrxnWxaXgsCZX+wxJ9mDNAWVfGjupdJ1CEYagQOaZ7Cg3DNp0wWT5NN6bhyNw==; 24:4hnen/yfW63k6U2MAfoINGiddpwKlwoqMCZN9RzUd+YiFWHfalYKMs9S7t6xPcg77h3F1PbSSurI1bYnzbV+/EKSov0OVtn568iwSAk88qA=; 7:dyNeBHpJc1OwFi3xmWzx1npCHwSNfPcgOz7oR24R2N/xM57sm1Ozt8GDf8G5kD+9R1xNLsaEeFdUjGuWVw/wRZOvPAIQa3+LHGFOoZeo58jluWwKPdRZ2yZ5OyphEJkLUlR0ZXqsI/w0Zv5/UhDCDjOMTj6ott+n54d1ldG/vheBJusrqV3/RM5bUDOG3MFsRY7iXowRrhwCtFeA9EnLuCGWLZ/gjF8sp3taU5fcMuQJ0gaOpFDWMnzYOPHUSdb/
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR10MB1523;
x-microsoft-antispam-prvs: <BN6PR10MB1523ECDCEBAE24D17C00F02AAAF80@BN6PR10MB1523.namprd10.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:BN6PR10MB1523; BCL:0; PCL:0; RULEID:; SRVR:BN6PR10MB1523;
x-forefront-prvs: 0058ABBBC7
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(189002)(199003)(377454003)(24454002)(3846002)(8676002)(1511001)(8936002)(11100500001)(92566002)(586003)(10400500002)(16236675004)(81166006)(19580395003)(66066001)(3660700001)(15650500001)(50986999)(10710500007)(122556002)(36756003)(77096005)(2420400007)(68736007)(2906002)(3280700002)(5002640100001)(81156014)(19580405001)(2900100001)(6116002)(5660300001)(87936001)(7736002)(82746002)(83716003)(7846002)(102836003)(86362001)(4326007)(106356001)(2561002)(5001770100001)(8666005)(2950100001)(33656002)(76176999)(54356999)(189998001)(2421001)(15975445007)(19300405004)(106116001)(97736004)(105586002)(19625215002)(99286002)(7110500001)(93886004)(101416001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR10MB1523; H:BN6PR10MB1524.namprd10.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: mobileiron.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_66936A3E6DF54CF9A24801F002D5DD82mobileironcom_"
MIME-Version: 1.0
X-OriginatorOrg: mobileiron.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Sep 2016 18:57:43.3222 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8392379d-8a98-4cb4-8cfe-5e7fa92e4e60
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR10MB1523
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/4a6vI0ZNK_16M7bEGyb7MH9HgoY>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] PR#625: Change alert requirements
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 07 Sep 2016 18:57:52 -0000
We probably want to discuss the potential for side-channels introduced by alerting. I’ve seen at least one case where there were two possible classes of errors at a particular state in the protocol. One caused an alert, the other caused the TLS stack to close the channel. Unfortunately, this difference in behavior could give information to an attacker. The only viable solution was to modify the TLS stack to close the channel in both cases. If we’re going to continue having alerts, I think we would need to be sure that an implementations following the RFC will not wind up in this situation. I suspect that will be difficult at best. Tim From: TLS <tls-bounces@ietf.org> on behalf of David Benjamin <davidben@chromium.org> Date: Wednesday, September 7, 2016 at 11:46 AM To: Eric Rescorla <ekr@rtfm.com>, Andrei Popov <Andrei.Popov@microsoft.com> Cc: "tls@ietf.org" <tls@ietf.org> Subject: Re: [TLS] PR#625: Change alert requirements On Wed, Sep 7, 2016 at 2:21 PM Eric Rescorla <ekr@rtfm.com<mailto:ekr@rtfm.com>> wrote: On Wed, Sep 7, 2016 at 11:19 AM, Andrei Popov <Andrei.Popov@microsoft.com<mailto:Andrei.Popov@microsoft.com>> wrote: > > the only popular stack I found that does not seem to send alerts is > > the schannel from Microsoft To clarify, schannel does generate alerts per RFC, but the HTTP stack (which actually owns the socket) sees no value in sending them. My impression is that this sometimes applies to Chrome as well. Chrome doesn't send close_notify. I'm not sure if error alerts get swallowed or not. I thought they did, but they do seem to make it through some layers in the stack. Probably whether they manage to get sent depends on how long higher layers happen to hold on to objects when an error is reported. For Chrome, writing to a socket is asynchronous (we have some callback-based interface which ultimately uses select/poll/whatever + non-blocking write/send on POSIX), but tearing down a socket or its owners is synchronous (it's just C++ delete), so we would attempt to post the write but then immediately cancel everything if it's just before everything gets torn down. Trying to wait for that write to actually clear (and then account for timing it out if it takes forever, etc) would be a ton of trouble and not actually do much useful. I imagine Andrei's story with the HTTP stack is similar. David
- [TLS] PR#625: Change alert requirements Eric Rescorla
- Re: [TLS] PR#625: Change alert requirements Sean Turner
- Re: [TLS] PR#625: Change alert requirements Watson Ladd
- Re: [TLS] PR#625: Change alert requirements Eric Rescorla
- Re: [TLS] PR#625: Change alert requirements Hubert Kario
- Re: [TLS] PR#625: Change alert requirements Hubert Kario
- Re: [TLS] PR#625: Change alert requirements Andrei Popov
- Re: [TLS] PR#625: Change alert requirements Eric Rescorla
- Re: [TLS] PR#625: Change alert requirements Martin Rex
- Re: [TLS] PR#625: Change alert requirements David Benjamin
- Re: [TLS] PR#625: Change alert requirements Timothy Jackson
- Re: [TLS] PR#625: Change alert requirements Ilari Liusvaara
- Re: [TLS] PR#625: Change alert requirements Salz, Rich
- Re: [TLS] PR#625: Change alert requirements Martin Rex
- Re: [TLS] PR#625: Change alert requirements Salz, Rich
- Re: [TLS] PR#625: Change alert requirements Salz, Rich
- Re: [TLS] PR#625: Change alert requirements Hubert Kario
- Re: [TLS] PR#625: Change alert requirements Hannes Tschofenig
- Re: [TLS] PR#625: Change alert requirements Benjamin Kaduk
- Re: [TLS] PR#625: Change alert requirements Martin Thomson
- Re: [TLS] PR#625: Change alert requirements Ilari Liusvaara
- Re: [TLS] PR#625: Change alert requirements Hubert Kario
- Re: [TLS] PR#625: Change alert requirements Sean Turner
- Re: [TLS] PR#625: Change alert requirements Eric Rescorla
- Re: [TLS] PR#625: Change alert requirements Eric Rescorla
- Re: [TLS] PR#625: Change alert requirements Eric Rescorla
- Re: [TLS] PR#625: Change alert requirements Hubert Kario
- Re: [TLS] PR#625: Change alert requirements Eric Rescorla
- [TLS] (strict) decoding of legacy_record_version? Benjamin Kaduk
- Re: [TLS] (strict) decoding of legacy_record_vers… David Benjamin
- Re: [TLS] (strict) decoding of legacy_record_vers… Eric Rescorla
- Re: [TLS] (strict) decoding of legacy_record_vers… Brian Smith
- Re: [TLS] (strict) decoding of legacy_record_vers… Martin Thomson
- Re: [TLS] (strict) decoding of legacy_record_vers… Brian Smith
- Re: [TLS] (strict) decoding of legacy_record_vers… Martin Thomson
- Re: [TLS] (strict) decoding of legacy_record_vers… Benjamin Kaduk
- [TLS] Treatment of (legacy_record_)version field … Andreas Walz
- Re: [TLS] Treatment of (legacy_record_)version fi… Eric Rescorla
- Re: [TLS] Treatment of (legacy_record_)version fi… Andreas Walz