IETF Logo Mail Archive

Re: [TLS] Minutes from Tuesday

Marsh Ray <maray@microsoft.com> Wed, 22 October 2014 01:10 UTC

Return-Path: <maray@microsoft.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 607D21A88E5 for <tls@ietfa.amsl.com>; Tue, 21 Oct 2014 18:10:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 dhZdpBohY9sN for <tls@ietfa.amsl.com>; Tue, 21 Oct 2014 18:09:51 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0710.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:710]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBF881A88D9 for <tls@ietf.org>; Tue, 21 Oct 2014 18:09:50 -0700 (PDT)
Received: from BY2PR03MB554.namprd03.prod.outlook.com (10.141.141.156) by BY2PR03MB556.namprd03.prod.outlook.com (10.141.142.145) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Wed, 22 Oct 2014 01:09:27 +0000
Received: from BY2PR03MB554.namprd03.prod.outlook.com ([10.141.141.156]) by BY2PR03MB554.namprd03.prod.outlook.com ([10.141.141.156]) with mapi id 15.00.1054.004; Wed, 22 Oct 2014 01:09:27 +0000
From: Marsh Ray <maray@microsoft.com>
To: "mrex@sap.com" <mrex@sap.com>, "Salz, Rich" <rsalz@akamai.com>
Thread-Topic: [TLS] Minutes from Tuesday
Thread-Index: Ac/s/80MFVvbkl4TRbKNfELmt8XWcwAQKq0AABRz8dA=
Date: Wed, 22 Oct 2014 01:09:27 +0000
Message-ID: <9a38ce96a67b4cb4bae5074bb9a6cf5d@BY2PR03MB554.namprd03.prod.outlook.com>
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C4AA6@USMBX1.msg.corp.akamai.com> <20141021150536.DA17C1AEFE@ld9781.wdf.sap.corp>
In-Reply-To: <20141021150536.DA17C1AEFE@ld9781.wdf.sap.corp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [2001:4898:80e8:ee31::2]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB556;
x-forefront-prvs: 037291602B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(51704005)(189002)(199003)(86612001)(106356001)(86362001)(95666004)(99286002)(105586002)(92566001)(4396001)(2656002)(87936001)(85852003)(19580395003)(19580405001)(107046002)(76482002)(101416001)(40100003)(31966008)(122556002)(20776003)(120916001)(99396003)(54356999)(76176999)(50986999)(85306004)(21056001)(97736003)(2501002)(74316001)(33646002)(108616004)(46102003)(80022003)(76576001)(64706001)(3826002)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB556; H:BY2PR03MB554.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/eAc7bLZ2izDP5-lGqKIO0ZJ8JDk
Cc: "TLS@ietf.org (tls@ietf.org)" <tls@ietf.org>
Subject: Re: [TLS] Minutes from Tuesday
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 22 Oct 2014 01:10:10 -0000

From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Rex
Sent: Tuesday, October 21, 2014 8:06 AM
> Rather than aborthing the TLS handshake, the server ought to 
> include a TLS extension in the ServerHello indicating that he 
> recognized a potentially inappropriate fallback

Even better would be something the client could authenticate,
but that an attacker might not be able to detect without a
full real-time compromise of the master secret. E.g.,
invert all the bits in the Finished message.

> and otherwise 
> continue the TLS handshake in the regular fashion
> clients who do perform insecure fallbacks.
>
> This would also allow clients (browsers probably) to gather 
> real data on potentially incorrect fallbacks, rather than 
> have users face random connection failures.

If the client was really determined to use a downgraded connection,
it could always just connect again without FALLBACK_SCSV.

But that would be stupid.

- Marsh

v2.15.0 | Report a Bug | By Email