Re: [TLS] 1rtt thoughts

Daniel Kahn Gillmor <> Mon, 14 July 2014 21:22 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 100D01A0118 for <>; Mon, 14 Jul 2014 14:22:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZadwVT6NPwPN for <>; Mon, 14 Jul 2014 14:22:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 55C7C1A010F for <>; Mon, 14 Jul 2014 14:22:26 -0700 (PDT)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id AA619F984 for <>; Mon, 14 Jul 2014 17:22:23 -0400 (EDT)
Message-ID: <>
Date: Mon, 14 Jul 2014 17:22:11 -0400
From: Daniel Kahn Gillmor <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Icedove/30.0
MIME-Version: 1.0
To: "" <>
References: <> <> <> <>
In-Reply-To: <>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="rvkXDhewj461Hom9MjplinGb2v01PAbt6"
Subject: Re: [TLS] 1rtt thoughts
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 14 Jul 2014 21:22:30 -0000

On 07/14/2014 04:06 PM, Michael StJohns wrote:

> From the server's side this looks like two different connections. From
> the client side, it's just negotiating to the right suite.

I'm not sure what toolkit presents this as two different connections on
the server side.  This closure and reopening smells very much like
problems we fixed with insecure renegotiation only a few years ago.  A
TLS toolkit capable of keeping the underlying transport open while
restarting a new TLS session would need to be very clear about how it
presents such a transition to the upper-layer logic, if we don't want
another round of prefix-injection attacks.

I recognize that this is an API question more than a protocol question,
and therefore at the edge of scope for the WG.  But we've seen enough
problematic APIs that cause applications to lose the security guarantees
that the protocol is supposed to provide that i can't help thinking we
should take these concerns seriously.