Re: [TLS] PR#625: Change alert requirements

Timothy Jackson <> Wed, 07 September 2016 18:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9BD9612B117 for <>; Wed, 7 Sep 2016 11:57:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.921
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yN1m1o5ODvQE for <>; Wed, 7 Sep 2016 11:57:46 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B442012B2C9 for <>; Wed, 7 Sep 2016 11:57:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-mobileiron-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Kc1bPBJT/D/B4EbAsalYTJGRcmOqDxq9XeAnnEfp0HA=; b=1XW56y9UdaYUzkupv3XSei1QRGVFHo5arK9P5cKt6SA730LMb8rWrrqLLL58yhQcr9J9hoJQbgeahwsNWOvRI4BjTTw9v4I3gNNZhk4sm6oJvgBUc3Y1diigONROPTBw5+TpjQ1BC2Kle9pi/4XeXeaaszfKWMGuL10gOBkXGHs=
Received: from ( by ( 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 ([]) by ([]) with mapi id 15.01.0599.016; Wed, 7 Sep 2016 18:57:43 +0000
From: Timothy Jackson <>
To: David Benjamin <>, Eric Rescorla <>, Andrei Popov <>
Thread-Topic: [TLS] PR#625: Change alert requirements
Thread-Index: AQHSB5/gdixB194trkK9mLH+7eAB3qBuRNSAgAADxwCAAAnyAIAABw8AgAAAKoCAAAc/gP//jc4A
Date: Wed, 7 Sep 2016 18:57:43 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: []
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: <>
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;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_66936A3E6DF54CF9A24801F002D5DD82mobileironcom_"
MIME-Version: 1.0
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: <>
Cc: "" <>
Subject: Re: [TLS] PR#625: Change alert requirements
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.


From: TLS <> on behalf of David Benjamin <>
Date: Wednesday, September 7, 2016 at 11:46 AM
To: Eric Rescorla <>, Andrei Popov <>
Cc: "" <>
Subject: Re: [TLS] PR#625: Change alert requirements

On Wed, Sep 7, 2016 at 2:21 PM Eric Rescorla <<>> wrote:
On Wed, Sep 7, 2016 at 11:19 AM, Andrei Popov <<>> 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.