Re: [TLS] Antw: Re: Antw: Re: Suspicious behaviour of TLS server implementations

Andrei Popov <Andrei.Popov@microsoft.com> Mon, 26 September 2016 16:56 UTC

Return-Path: <Andrei.Popov@microsoft.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 C2A6B12B306 for <tls@ietfa.amsl.com>; Mon, 26 Sep 2016 09:56:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.022
X-Spam-Level:
X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 NYJqjPA0pSMm for <tls@ietfa.amsl.com>; Mon, 26 Sep 2016 09:56:06 -0700 (PDT)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0112.outbound.protection.outlook.com [104.47.38.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82E8612B305 for <tls@ietf.org>; Mon, 26 Sep 2016 09:56:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/V9Xj8K1vxkB5xeyk3ufbPZdBrJCxHQdbr3kYk+fYO0=; b=Y907FZY9imYtjIFzOaL+RndJv6RG43zmkFQNNYrNCdyb2IbayVrKzMAi3N9tKtQSbqacp6IiSk5OcqJtsLeETGouHQ0MbCW0HhRGIhXiKMuVB5jPqaGfrVxu7xyYRaU57ir9rngOpnCXCCxYHjPSy6iR5jZj5j2TsX6YsBdgH9M=
Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0841.namprd03.prod.outlook.com (10.160.163.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.629.8; Mon, 26 Sep 2016 16:56:04 +0000
Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0629.018; Mon, 26 Sep 2016 16:56:04 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: Christian Huitema <huitema@huitema.net>, 'Peter Gutmann' <pgut001@cs.auckland.ac.nz>, 'Andreas Walz' <andreas.walz@hs-offenburg.de>
Thread-Topic: [TLS] Antw: Re: Antw: Re: Suspicious behaviour of TLS server implementations
Thread-Index: AQHSFM0ZdhmUcwX9zUmJWUs/tojCO6CGwi8AgAEPyQCABDCYkA==
Date: Mon, 26 Sep 2016 16:56:04 +0000
Message-ID: <CY1PR0301MB08421C80CFCE7C021D26D1378CCD0@CY1PR0301MB0842.namprd03.prod.outlook.com>
References: <57D2E218020000AC0011B17E@gwia2.rz.hs-offenburg.de> <20160909152901.9008C1A552@ld9781.wdf.sap.corp> <1473853106532.3256@cs.auckland.ac.nz> <57D96E34020000AC0011B73F@gwia2.rz.hs-offenburg.de> <57E25106020000AC0011BF3A@gwia2.rz.hs-offenburg.de> <CABkgnnX7X+21wjChxkW-uhd8WXAMyp5f1F74H5ja=1mui4POiQ@mail.gmail.com>, <57E272CB020000AC0011BF63@gwia2.rz.hs-offenburg.de> <1474473207998.35647@cs.auckland.ac.nz>, <57E2E068020000AC0011BFD4@gwia2.rz.hs-offenburg.de> <1474520407230.85774@cs.auckland.ac.nz>, <57E3E821020000AC0011C0DC@gwia2.rz.hs-offenburg.de> <1474619914890.15531@cs.auckland.ac.nz> <168501d215fd$caca2400$605e6c00$@huitema.net>
In-Reply-To: <168501d215fd$caca2400$605e6c00$@huitema.net>
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=Andrei.Popov@microsoft.com;
x-originating-ip: [2001:4898:80e8:a::1d2]
x-ms-office365-filtering-correlation-id: ad01cb5e-60df-4dac-f95a-08d3e62e00ce
x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0841; 6:iJBjK1bDKG+g0gyoyF3ZEzR/Ox6vP+s8Qtm3nUJ0pVsRsJaRhmhLBUrm/taf1ERJDjd6mNwOXonBYeUtzcywyMOtpJTaHDYwwoU8L0Fubgica9xhSiRca+Am0lXYCfWKPaeW9uB7ROdZewcEpcHDvwo45IlxIN7paAY9EUjqXpCH1ffzCn58eUCf8fNv8flJ+jT7nlKLFOqJBYfOnqiLftbx/Q8Xx7gUA4pd6zDqZIprZm6ItCOgLgqVhGc1wFywOuZtO0U399lkad+Od+2qQMH06n6Vy/pDu2q/LDBRDV2dQqg/69TklpFktD/yHsKrJyg/ZJhwAqe1k/Ut26+z1Q==; 5:nvuenB29UmNpWhRHGIIJiHOPR/tc8t07G4UE/zN01uVQLrhvANoK/k2PiglC0cGt4MGRs9u4KCrYjXFV9exHSOOWk8rrrc86NcjsMzKw32HfhXsFXvv6yo+SbcSWNsget1C5SZKtznHmt9OfpTVCRw==; 24:3c5DKVOgrLCIHlC8V9WipztQssFUH9EHRWeZkbHDuj3aetlyO0R5U2NpgFU5XQh2rQpiw2L/lmd9LfhQcH3g5m0z+Yus9BAdXAPiOSqHaYk=; 7:SmFctA5Oft9J1isLwzSqkxthCRz2SEHou7KKLldiYoA/XtPnMzrZzG2RdnAYeyjnWDZa0aszU8FABvQSYzHIAdeSEceAt93mxLdBEAoIXzGtU6FUG39pH5Z0VOlkkD7g2urGkP/DYYlo0iDJS1GvYdLmme7SeU5DO9xgtJE5nx/37gPzI7jUZ+5WvAz0q9OnUxBJdKf22on1iHjdQUsiiMB1u5sh6RAiPEGYQw5jNnzcZlZDoGBUTDO1dOHyV5YuyI3BZNtqlF4epNGp1mjBshIET0eb/pldfmTd/aP219SHMZ/MbtED8t3Qiav6kc5R
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0841;
x-microsoft-antispam-prvs: <CY1PR0301MB08412D4FFCA9D844AF382B818CCD0@CY1PR0301MB0841.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB0841; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0841;
x-forefront-prvs: 00770C4423
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(13464003)(377454003)(199003)(24454002)(189002)(86612001)(10290500002)(33656002)(97736004)(10400500002)(76576001)(5001770100001)(86362001)(5660300001)(54356999)(9686002)(76176999)(5005710100001)(2900100001)(68736007)(8990500004)(3660700001)(105586002)(7696004)(101416001)(3280700002)(99286002)(50986999)(106356001)(189998001)(106116001)(586003)(81166006)(81156014)(2950100002)(102836003)(5002640100001)(93886004)(6116002)(122556002)(15975445007)(8936002)(7736002)(4326007)(92566002)(87936001)(19580405001)(11100500001)(19580395003)(74316002)(2906002)(10090500001)(8676002)(305945005)(7846002)(77096005)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0841; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Sep 2016 16:56:04.2187 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0841
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/gzDmP-UuK7XhsuxZ2Yq5jzjtOJI>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Antw: Re: Antw: Re: Suspicious behaviour of TLS server implementations
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: Mon, 26 Sep 2016 16:56:08 -0000

> Pushed to the extreme, the result is a sort of protocol drift, in which buggy variants get first tolerated, and then accepted as de-facto standards.
Indeed, we're seeing several instances of this protocol drift in TLS 1.3 (2.0? 4.0?), e.g. the relaxed rules around the signature_algorithms extension and the version negotiation workaround that just got adopted...

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Christian Huitema
Sent: Friday, September 23, 2016 5:52 PM
To: 'Peter Gutmann' <pgut001@cs.auckland.ac.nz>;; 'Andreas Walz' <andreas.walz@hs-offenburg.de>;
Cc: tls@ietf.org
Subject: Re: [TLS] Antw: Re: Antw: Re: Suspicious behaviour of TLS server implementations

On Friday, September 23, 2016 1:39 AM, Peter Gutmann wrote:
> Andreas Walz <andreas.walz@hs-offenburg.de>; writes:
>
>>However, where would you draw the line between "I can't" and "I don't 
>>want to"?
> 
> It's one of those judgement-call things, I don't know if you can 
> strictly define it but as a rule of thumb I'd say that if you 
> encounter it during normal processing it's an I-can't problem while if 
> you have to add
special-
> case checks to identify it and refuse to continue it's an 
> I-don't-want-to problem.

Yes of course, but there is another aspect to it, the general health of the ecosystem. Postel's rule is nice, but it removes the pressure on broken implementations to fix their code. Pushed to the extreme, the result is a sort of protocol drift, in which buggy variants get first tolerated, and then accepted as de-facto standards. This tends to hinder future evolutions, not to mention adding complexity. We often hear that "the IETF has no protocol police," but in fact it does. Each implementation that takes a strict view of standard compliance contributes to this policing.

-- Christian Huitema



_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls