Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

Eric Rescorla <> Wed, 09 November 2016 10:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2B4FF12996D for <>; Wed, 9 Nov 2016 02:25:47 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HiC6acw-nJ7C for <>; Wed, 9 Nov 2016 02:25:44 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A692612959D for <>; Wed, 9 Nov 2016 02:25:44 -0800 (PST)
Received: by with SMTP id i145so108212205ywg.2 for <>; Wed, 09 Nov 2016 02:25:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CijFGCR65A4SnAeZzvRJogBe8LMOUaitivWzkrez8g0=; b=H7YQohWGCwl+rxtalCEcww6CmVyptgyNG9nJpV5jGCy/VBpnXj5N+cGIt4X2YA1jgu 0bsh5qG/SXSDCD/My3vxRfdL0WawejwoyibD3pOXQw3ce9HXmz8u35jblYQBc2+e+qz3 aMKbszGx4KQ2BjRSVwlDi2dhUcLUF9RwQOV0IRiOZC/srF843cyu8FmZuoLvhEGhk55L pauBx4L8ONVFUdD7wKmd/fbyZFRVe9Ge9xsbrR78/Tcs2mWDH3pA9eC4DVJrY0oyLkFr KnzRvdSkb3UJ6RLRi8m2XmMj+vWGjygRxxgtb8mEUlwwnI83Nr9LiRer0YVxoRJjmzAP gloQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CijFGCR65A4SnAeZzvRJogBe8LMOUaitivWzkrez8g0=; b=fZcuSqvTkv3+5M7UcUcZwpevM8+/1J1O5QNgxw0iCHtLu7pDCLRnrblPabdLMx47VE McAC5MET83K5Y8rqzzic5tIN5qpLEiyUkIG7DkJTZ9LUjpvM4d3PBDC2MmKC5OB3k4e5 ME0yBLPLEtS3Bjp3VTzqa2iIw5pEi/CKOu0Wd0SeNgzyS9vipqf6MplQ1pTJv23BOjkC 3W+p8cAnH2DATtfNUns/zMF95W9UsnA8kGn7+GM2+OPD+tEpny2gvH1sQahkkNAkFv6T 2EgLO5Me9Q0fPn1iacT5J+FwyCF3DEoEz2ifyiK2BAoCUAwn92QwzM2M7PFdr3r2ZMYk EgQw==
X-Gm-Message-State: ABUngvfzWZgQ0QKgWoy20F/LzwiE7Cx/gs55S/F6SfNKsUvN33FTCvjyuZQo3xRSZwpjLfXBTaW9MQPOK3sfuQ==
X-Received: by with SMTP id y206mr15425206ywc.234.1478687143849; Wed, 09 Nov 2016 02:25:43 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 9 Nov 2016 02:25:03 -0800 (PST)
In-Reply-To: <>
References: <> <>
From: Eric Rescorla <>
Date: Wed, 09 Nov 2016 02:25:03 -0800
Message-ID: <>
To: "" <>
Content-Type: multipart/alternative; boundary="001a11492dfaf1a2580540dbada2"
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18
X-Mailman-Version: 2.1.17
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: Wed, 09 Nov 2016 10:25:47 -0000

On Wed, Nov 9, 2016 at 1:31 AM, Martin Rex <> wrote:

> Salz, Rich wrote:
> >> the PDUs are still pretty much predictable
> >> heuristically (by their ordering), even when they're padded.
> >
> > ...
> >
> >> So besides being completely pointless, can you describe any realistic
> >> problem that is worth breaking middleware at the endpoints so badly?
> >
> > I found the language difference interesting.  We could conduct an
> > interesting thought experiment by reversing the emphasis on each
> > of the above fragments.  But I won't.
> >
> > Instead, I'll point out that this is in-charter, in-scope, and WG
> consensus
> > has generally been to "encrypt all the bits" as much as feasible.
> The problem here is that this breaks (network) flow control, existing
> (network socket) event management, and direction-independent connection
> closure, and does so completely without value.
> When TLS records with AppData can be left in the network socket while
> the application layer is not ready to process & consume it, then TCP flow
> control works better in high load situation.
> The semantics defined for the TLS Closure Alert in SSLv3->TLSv1.2
> is somewhat difficult for full-duplex communication, direction-independent
> shutdown, and confirmation of receipt:
>    7.2.1.  Closure Alerts
>    The client and the server must share knowledge that the connection is
>    ending in order to avoid a truncation attack.  Either party may
>    initiate the exchange of closing messages.
>    close_notify
>       This message notifies the recipient that the sender will not send
>       any more messages on this connection.  Note that as of TLS 1.1,
>       failure to properly close a connection no longer requires that a
>       session not be resumed.  This is a change from TLS 1.0 to conform
>       with widespread implementation practice.
>    Either party may initiate a close by sending a close_notify alert.
>    Any data received after a closure alert is ignored.
>    Unless some other fatal alert has been transmitted, each party is
>    required to send a close_notify alert before closing the write side
>    of the connection.  The other party MUST respond with a close_notify
>    alert of its own and close down the connection immediately,
>    discarding any pending writes.  It is not required for the initiator
>    of the close to wait for the responding close_notify alert before
>    closing the read side of the connection.
> The issue here is that the receiving TLS stack, when processing an
> incoming TLS CloseNotify Alert, will typically immediately respond
> with a TLS CloseNotifyAlert on its own, precluding the application
> from sending any further data in the other direction in response
> When hiding the TLS record ContentType, then pre-reading and coalescing
> (=streaming) application data records suddenly becomes a problem, because
> receiving and processing a hidden TLS CloseNotify Alert will cause
> a TLS CloseNotify Alert response (an alleged indicator for a graceful
> connection closure) being generated and returned even before
> the application has (a) seen and (b) had a chance to respond to the
> latest batch of application data.
> To prevent this from happening, and leave the decision to the application
> of whether to read a (potential) CloseNotify alert from the wire,
> I would have to go back to trickling TLS records (including those
> pathologically fragmented ones from Google) to the application
> whenever TLSv1.3 is negotiated.

I'm not quite following who's who in this scenario, so some potentially
questions below.

As I understand it, you have the following situation:

- A Web application server
- Some middleware, which comes in two pieces
  - A crypto-unaware network component
  - The TLS stack (you control this piece as well, right?)
- The client

So, in this case, the client sends a flight of records which (ignoring
and other TLS 1.3 post-handshake shenanigans such as KeyUpdate) contains
a bunch of application data traffic potentially terminating in a
close_notify. In
TLS 1.2 you inspect the content type, deliver all the app data to the TLS
but hold the close_notify. And those packets are in turn handed to the Web
server/application. Is that correct? If so, when do you deliver the
and how do you know how?

In the TLS 1.3 case, as I understand it, you can't see which packets are
so you just have to deliver all the packets to the TLS processor, and if
one of
them contains a close_notify, then it responds with its own close_notify
(I'm getting this from the text above where you say "being generated and
returned even before the application has..."). Is that right as well? Can
you explain
further why this is a problem: are you expecting that if you send
data to the client after sending the close_notify itself, the client will
it? Or are we somehow concerned with side effects on the application server?

Can you help me understand?


There is a similar (slightly smaller) issuer with the coalesced TLS
> handshake/alert/css record processing during the TLS handshake phase,
> Feeding the whole "flight" already waiting in network buffers into
> the TLS stack at once will no longer be possible, with hidden ContentTypes
> I will have to start trickling TLS records with handshake messages into
> the TLS stack, and have to poll the handshake state after each TLS record
> in order to heuristically determine whether the next record waiting in
> the network buffer is (likely) a record with AppData--which I must leave
> in the network buffer until the application caller explicitly calls for it.
> The really painful issue are constantly mind-changing browsers loosing
> interest in responses and sending TLS CloseNotify instead of TCP RSTs
> -- I don't know how to deal with these without breaking the current
> (network socket) event semantics for the app.
> -Martin
> _______________________________________________
> TLS mailing list