IETF Logo Mail Archive

Re: [TLS] Next Protocol Negotiation 03

Andrei Popov <Andrei.Popov@microsoft.com> Wed, 14 November 2012 20:33 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 A06A821F8792 for <tls@ietfa.amsl.com>; Wed, 14 Nov 2012 12:33:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.533
X-Spam-Level:
X-Spam-Status: No, score=0.533 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSkLm7AM+edw for <tls@ietfa.amsl.com>; Wed, 14 Nov 2012 12:33:41 -0800 (PST)
Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.27]) by ietfa.amsl.com (Postfix) with ESMTP id 680D021F86F0 for <tls@ietf.org>; Wed, 14 Nov 2012 12:33:41 -0800 (PST)
Received: from BL2FFO11FD010.protection.gbl (10.173.161.203) by BL2FFO11HUB040.protection.gbl (10.173.160.246) with Microsoft SMTP Server (TLS) id 15.0.556.9; Wed, 14 Nov 2012 20:33:38 +0000
Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD010.mail.protection.outlook.com (10.173.161.16) with Microsoft SMTP Server (TLS) id 15.0.556.9 via Frontend Transport; Wed, 14 Nov 2012 20:33:37 +0000
Received: from ch1outboundpool.messaging.microsoft.com (157.54.51.112) by mail.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.2.318.3; Wed, 14 Nov 2012 20:32:50 +0000
Received: from mail34-ch1-R.bigfish.com (10.43.68.251) by CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id 14.1.225.23; Wed, 14 Nov 2012 20:32:22 +0000
Received: from mail34-ch1 (localhost [127.0.0.1]) by mail34-ch1-R.bigfish.com (Postfix) with ESMTP id 852E544026B for <tls@ietf.org.FOPE.CONNECTOR.OVERRIDE>; Wed, 14 Nov 2012 20:32:22 +0000 (UTC)
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT001.namprd03.prod.outlook.com; R:internal; EFV:INT
X-SpamScore: -27
X-BigFish: PS-27(zzbb2dI98dI9371Id6eah542M1432Izz1de0h1202h1d1ah1d2ahzz1033IL8275dhz31h2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh9a9j1155h)
Received-SPF: softfail (mail34-ch1: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=Andrei.Popov@microsoft.com; helo=BL2PRD0310HT001.namprd03.prod.outlook.com ; .outlook.com ;
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM;SFS:(299001);DIR:OUT;LANG:en;
Received: from mail34-ch1 (localhost.localdomain [127.0.0.1]) by mail34-ch1 (MessageSwitch) id 1352925140776667_10321; Wed, 14 Nov 2012 20:32:20 +0000 (UTC)
Received: from CH1EHSMHS025.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.252]) by mail34-ch1.bigfish.com (Postfix) with ESMTP id BB24A3A01F7; Wed, 14 Nov 2012 20:32:20 +0000 (UTC)
Received: from BL2PRD0310HT001.namprd03.prod.outlook.com (157.56.240.21) by CH1EHSMHS025.bigfish.com (10.43.70.25) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 14 Nov 2012 20:32:20 +0000
Received: from BN1PR03MB071.namprd03.prod.outlook.com (10.255.225.155) by BL2PRD0310HT001.namprd03.prod.outlook.com (10.255.97.36) with Microsoft SMTP Server (TLS) id 14.16.233.3; Wed, 14 Nov 2012 20:32:20 +0000
Received: from BN1PR03MB072.namprd03.prod.outlook.com (10.255.225.156) by BN1PR03MB071.namprd03.prod.outlook.com (10.255.225.155) with Microsoft SMTP Server (TLS) id 15.0.545.9; Wed, 14 Nov 2012 20:32:19 +0000
Received: from BN1PR03MB072.namprd03.prod.outlook.com ([169.254.7.68]) by BN1PR03MB072.namprd03.prod.outlook.com ([169.254.7.106]) with mapi id 15.00.0545.000; Wed, 14 Nov 2012 20:32:00 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: Adam Langley <agl@chromium.org>
Thread-Topic: [TLS] Next Protocol Negotiation 03
Thread-Index: AQHNIlzPyXJEV/H1YEG2j4FhINiIPJarp+EAgAAXsQCAADAaAIE/FnRA
Date: Wed, 14 Nov 2012 20:31:59 +0000
Message-ID: <f5178418cb4549fea8e210d6a3bc22d1@BN1PR03MB072.namprd03.prod.outlook.com>
References: <CAL9PXLy31VzxLidgOy64MnDAyRE=HU=hxyBXW1rgB+Xnd0vKjA@mail.gmail.com> <4F981528.9010903@gnutls.org> <CAL9PXLzWNTxOjRnVPk67anfAkWizagcAsWRWJM3ShY6oWv9PjA@mail.gmail.com> <4F985162.7040405@extendedsubset.com>
In-Reply-To: <4F985162.7040405@extendedsubset.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.255.156.151]
x-forefront-prvs: 066517B35B
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OrganizationHeadersPreserved: BL2PRD0310HT001.namprd03.prod.outlook.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%CHROMIUM.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-CrossPremisesHeadersPromoted: TK5EX14MLTC102.redmond.corp.microsoft.com
X-CrossPremisesHeadersFiltered: TK5EX14MLTC102.redmond.corp.microsoft.com
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704002)(13464001)(377454001)(24454001)(479174001)(47976001)(5343655001)(54356001)(16676001)(51856001)(56816001)(53806001)(6806001)(47736001)(49866001)(4396001)(23726001)(50986001)(50466001)(550184003)(44976002)(47776002)(46102001)(47446002)(33646001)(76482001)(31966008)(46406002)(74502001)(54316002)(56776001)(74662001)(24736002); DIR:OUT; SFP:; LANG:en;
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 066517B35B
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Next Protocol Negotiation 03
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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, 14 Nov 2012 20:33:42 -0000

A number of issues have been raised with regard to the TLS NPN Internet-Draft, including the downgrade attack described by Marsh. Is an updated draft in the works?

Cheers,

Andrei

-----Original Message-----
From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Marsh Ray
Sent: Wednesday, April 25, 2012 12:33 PM
To: Adam Langley
Cc: tls@ietf.org
Subject: Re: [TLS] Next Protocol Negotiation 03

On 04/25/2012 11:40 AM, Adam Langley wrote:
>
> The idea would be that the server doesn't advertise Tor, or any other 
> possibly suspect protocol. Rather the client would simply select "tor"
> as the protocol.
>
> The fact that the server advertises is unfortunate, but necessary to 
> avoid an extra round trip. I'd rather see NPN in the clear as a 
> standard ClientHello/ServerHello negotiation then take an extra round 
> trip.

I don't speak for the Tor project, but I don't think this design is going to meet anyone's requirements for serious censorship resistance.

Nevertheless, giving some privacy to the significant bits of the handshake in a way that is more latency-friendly than full renegotiation is very appealing. It seems likely to enable new and interesting applications, SPDY is just one good example.

Unfortunately, we must keep in mind that anything sent before receiving the other endpoint's Finished message is going to raise similar considerations as False Start. The security guarantees provided to this data are somewhat squishy, as they tend to depend on all sorts of not-yet-fully authenticated details of the in-progress negotiation. As we saw with ServerKeyExchange DHE_RSA/ECDH, even the future introduction of new key exchanges and cipher suites can change these properties.

In the case of something like NP(N), a MitM might utilize a downgrade attack which allows him to decrypt the client's NP record (possibly offline). This could break the handshake, but clients are so eager to retry the user might not even notice.

So maybe any facility for "privately" negotiating handshake extensions ought to be held to a clear standard lest we invite disaster, namely, it should provide the same security guarantees as are provided to application data.

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

v2.23.0 | Report a Bug | By Email