Re: [TLS] TLS Next Proto negotiation

Marsh Ray <> Thu, 21 July 2011 22:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8C9C921F8579 for <>; Thu, 21 Jul 2011 15:06:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eEv+r5Rq6tF1 for <>; Thu, 21 Jul 2011 15:06:23 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 17D4021F8576 for <>; Thu, 21 Jul 2011 15:06:23 -0700 (PDT)
Received: from ([]) by with esmtpa (Exim 4.72) (envelope-from <>) id 1Qk1Nu-000GKU-Lj; Thu, 21 Jul 2011 22:06:22 +0000
Received: from [] (localhost []) by (Postfix) with ESMTP id 293EC6073; Thu, 21 Jul 2011 22:06:21 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Report-Abuse-To: (see for abuse reporting information)
X-MHO-User: U2FsdGVkX184VltCkkMv40a8478i96BoATtilY5fdB4=
Message-ID: <>
Date: Thu, 21 Jul 2011 17:06:13 -0500
From: Marsh Ray <>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
To: Adam Langley <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: tls <>
Subject: Re: [TLS] TLS Next Proto negotiation
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 21 Jul 2011 22:06:23 -0000

On 07/18/2011 07:43 AM, Adam Langley wrote:

The server needs to see the client's NextProtocol message to know what 
protocol will be in use. But when a session is resumed, the server sends 
the Finished message before the client. Some app protocols have the 
server send the first application data, e.g., "username: ". If such an 
app protocol is a possibility, doesn't the use of NPN introduce an extra 
round-trip delay in case of session resumption?

Also, since the semantics of NPN apply explicitly to the connection 
(rather than the session or connection state), perhaps the use of NPN 
ought to be contingent on the successful negotiation of RFC 5746 
Renegotiation Indication. Multiplexing multiple protocols from same 
server port are likely to provide additional opportunities for an 
attacker to put the server in a state where it is willing to accept a 
renegotiating ClientHello. It will also provide more ways for an 
attacker to have the server echo back chosen plaintext to be interpreted 
as HTTP response headers (or other protocols could be attacked).

- Marsh