Re: [TLS] 1rtt thoughts

Michael StJohns <> Mon, 14 July 2014 20:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2530C1A8BB2 for <>; Mon, 14 Jul 2014 13:06:41 -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 XU46-K1X8bXI for <>; Mon, 14 Jul 2014 13:06:39 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E5B971ABB90 for <>; Mon, 14 Jul 2014 13:06:38 -0700 (PDT)
Received: by with SMTP id r5so3203059qcx.41 for <>; Mon, 14 Jul 2014 13:06:38 -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 :cc:subject:references:in-reply-to:content-type; bh=abbn7CxL/PbfzzH4egOk2nihFJZV1Wz4JWssEmtDE9w=; b=EzRoRjUVGY5oEsSjb2LzUZybM/bAtp7ra9H9GKsHc+N5aEgPkBE8lQk7t1mT5HNWaD mNnpCiFbZftb2aoZy4jMWHmrf67cEmCvuj89WgN1f1WaThjkimf1soBd4O7OyNODHsDx N6T7aUFGkEsHaSLF8QdYtcFYfV3PUxfy/KBtXUaDKYOPbaoh02OTG+hY96GlTjjkBFJ5 IP0RFSX/CwPtRwOWUlZpyRUEgfG6sc7z/xyWYD49iCJbHXTpxDyGv8qvh84tqqpWiDbz nZETegGvmQShyMvcH/y7IKZSjunIrLRv/hIbdqgIWNj8JBwIWd1fWYbcmBakgr10KN8i oncA==
X-Gm-Message-State: ALoCoQkxMf7ci/a+vRE77dYU4jhb/QEEr2CUYR2Ux5ryquX364llAtIt+l7snldiBz42GXQg6rrH
X-Received: by with SMTP id u7mr25066137qaf.58.1405368398012; Mon, 14 Jul 2014 13:06:38 -0700 (PDT)
Received: from ?IPv6:2601:a:2a00:390:d81:350c:1e85:a7c? ([2601:a:2a00:390:d81:350c:1e85:a7c]) by with ESMTPSA id r10sm22011294qar.40.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Jul 2014 13:06:37 -0700 (PDT)
Message-ID: <>
Date: Mon, 14 Jul 2014 16:06:50 -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
To: Eric Rescorla <>, Adam Langley <>
References: <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------040306000404070301000007"
Cc: "" <>
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 20:06:41 -0000

On 7/14/2014 1:49 PM, Eric Rescorla wrote:
> On Mon, Jul 14, 2014 at 10:27 AM, Adam Langley < 
> <>> wrote:
>     On Mon, Jul 14, 2014 at 10:16 AM, Michael StJohns
>     < <>> wrote:
>     > A
>     > TLS1.2 server receiving things in this order discards the
>     ClientKeyExchange
>     > with an out of sequence error, and then starts the handshake
>     normally with
>     > the receipt of the ClientHello.
>     I've never encountered a TLS 1.2 implementation that will discard an
>     unexpected handshake message like that as opposed to sending a fatal
>     alert (maybe) and closing the connection.
> Indeed, it's required by TLS.


Part of the problem I have at times in discussions about TLS is the 
confusion between what happens as part of the transport connection and 
what happens as part of the TLS connection.  I think of TLS as a record 
connection over a bearer transport service.  They interact, but not 
strongly, and usually not without intervention from the client or server 
application.  The TLS thing (server, message processor, etc) attached to 
the server side of the transport connection snarfs up individual TLS 
records one by one and processes them according to its current state.

While you're both correct that TLS requires the "connection" to be 
closed in the event of a fatal error  (and here I'm referring to 7.2.2 
of RFC5246), the context of the word "connection" in that section 
doesn't appear to be same as closing the "transport" (see just above 
that where the two different terms are used).   It appears to only refer 
to closing the current TLS connection.

Nothing in section 7.2.2 suggests either the requirement to close the 
transport, nor the requirement to discard pending data in the transport 
connection.  I'm not arguing that implementations don't do exactly that 
though - I don't actually know.   if you're arguing that the standard 
says to close the transport and discard the pending TLS records, can you 
point me at that section?

I also can't find anything that says that a new connection can't be 
opened on the same transport connection after a fatal close.

So I would suggest that even with 7.2.2 you get this as an error case 
between a 1rtt TLS1.3 client and a 1.2 server:

Client                                                      Server
ClientKeyExchange ----->
ClientHello ---->
notices data waiting on the transport
begins a connection state
receives and processes unexpected ClientKeyExchange
sends a fatal alert and discards the connection state]
                                        <--------------- Error Alert 
(unexpected_message) (plus close_notify??)
  [Client receives the error alert
    checks for type and discards it as expected]
notices data waiting on the transport
begins a connection state
Receives and processes ClientHello
sends its part of a TLS1.2 handshake]
                                         <--------------- ServerHello, 
ServerKeyExchange etc
[Client receives the Server Side messages and processes
  Client resends the ClientKeyExchange that was ignored above]
ClientKeyExchange  ------>
etc --->
  .............................  Continue through the normal connection 

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


> -Ekr
>     We could refine TLS 1.2 processing, of course, but if you were
>     expecting that to be backwards compatible with existing code then I
>     fear it won't work.
>     Cheers
>     AGL
>     --
>     Adam Langley
>     <>
>     _______________________________________________
>     TLS mailing list
> <>