Re: [TLS] 1rtt thoughts

Michael StJohns <> Tue, 15 July 2014 18:37 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0DF021AD6B0 for <>; Tue, 15 Jul 2014 11:37:34 -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=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NJwz56HFhGkZ for <>; Tue, 15 Jul 2014 11:37:30 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CD5AA1B278E for <>; Tue, 15 Jul 2014 11:37:29 -0700 (PDT)
Received: by with SMTP id w8so4877072qac.16 for <>; Tue, 15 Jul 2014 11:37:28 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=spl1Lec/1h3oXBObZNRJGL5W2mNw5dFaqDxovOnHRTI=; b=UqBp9Sydv18Zjp/zI5P6frtqITP6Xethv/8aWh6vUCVd6X07xVdggy7IPLJyJC6lrK Xz9IGyXa9vFx40pigLQFRErOEki201GjtPyvnlrxT8rYnTrHb6FeEKSDztNtgcJD0DbC oPRyBAE/ho7rxcZa7U7r106+kCSntIzo64I/LgiiWFqF7LYT/sKV8xjE29PrciUh1a7B /kfqi/OCZwatcsIAzdv/O8YIJ7omNdYeJzoEaEDrzizE1ZReezag4yduhV1wYyCQrPI0 2Bwkhz1Zwa8exgJdedbUK+DY+8xsLXP/rx3ggfNvdP5TfmITtmwtrSIOXIHybVaZUHHN TFQA==
X-Gm-Message-State: ALoCoQmj3voiR+5db2serYCvGNAyFyKvc1x3uC6lBk7HMMTtLTG6BPJ7wBFziDChhQWkEmA1wL8P
X-Received: by with SMTP id p11mr31274133qak.93.1405449448752; Tue, 15 Jul 2014 11:37:28 -0700 (PDT)
Received: from ?IPv6:2601:a:2a00:390:7115:22d1:58da:3b8e? ([2601:a:2a00:390:7115:22d1:58da:3b8e]) by with ESMTPSA id ik1sm27214917qab.32.2014. for <> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Jul 2014 11:37:28 -0700 (PDT)
Message-ID: <>
Date: Tue, 15 Jul 2014 14:37:31 -0400
From: Michael StJohns <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------020004050003080501010904"
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: Tue, 15 Jul 2014 18:37:34 -0000

Daniel  - inline below, but first

For grins I wrote a quick and dirty program to send a ClientKeyExchange 
before a ClientHello, read the response, try again, and then close the 

I got three different results from three different machines:

 From my local apache server, I got a single "unexpected_message" alert, 
and afterwards anything sent to the TCP connection was blackholed.  The 
TCP connection remained up though.

 From "" I got an abort of the TCP connection without 
any error alert.

 From "" I got no error message, and no response 
on any further data sent on the TCP connection.  The TCP connection 
appeared to remain up.

These were the first and only ones I tried.  I'm sure if I worked 
through a larger list I'd probably get even a wider set of responses.

On 7/14/2014 5:22 PM, Daniel Kahn Gillmor wrote:
> 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.

This is an interesting comment that made me consider what the issues 
might be lurking with things like STARTTLS style connections. Although 
all the current STARTTLS models have the clear text/non TLS only at the 
beginning of the TCP connection, I'm wondering if there isn't some 
application where interspersing TLS with plaintext (or maybe multiple 
differently credentialed TLS sessions) over the life of the TCP 
connection has any utility.  This is just a thought experiment for now.

> 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.
It's not exactly an API, but an interface question.  RFC793 (TCP) is 
sort of a gold standard in my eyes for how you describe them.  It talks 
about what TCP offers to the upper layer protocol, and what it needs 
from the lower layer protocol.  For the specifics of IP as the LLP for 
TCP, it provides some guidance on IP parameters.

The TLS spec is very good at specifying the on-the-wire and TLS protocol 
processor to TLS protocol processor, but less good at specifying 
interface characteristics for talking to the protocol levels above or 
the protocols levels below.

Later, Mike

> 	--dkg
> _______________________________________________
> TLS mailing list