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

Watson Ladd <> Wed, 09 November 2016 22:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 351FD1299BE for <>; Wed, 9 Nov 2016 14:07:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 f-QmfZ1AbBFF for <>; Wed, 9 Nov 2016 14:07:50 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AB3FA129431 for <>; Wed, 9 Nov 2016 14:07:50 -0800 (PST)
Received: by with SMTP id p9so188126585vkd.3 for <>; Wed, 09 Nov 2016 14:07:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mrK5ULr7V2KItPWn7p8QQ0/W4oHEmcTL4vMb8piVVSI=; b=XVoFyoYlgUjsxxgmBS87FzfPMGcnkeAC2HUJctCeXAjkB7nZAyQasMvezoDR9wz7he 7iX5Pak5O7EGYS5T5LxPTZdzKPwkgyciI90gTEa0J23CEs+N41B88JJXQA98JllIdNHm fuwNn7YyEbx+RVdxaCJm68lcOd7bpRvceT90qhErfrhENln5DtFdTcJ/JpAatZTcqGaH ODJ79cWBKFccVrY9uS0VT6y7KJByPZ8t/PrOHjYF9rqwDsHFa+z3DBgjv2ZMSBQwC7Y3 njGg8mfTqoN544ZP7G1QinaR8CF15jENFZTIjH+LWGwkmTJHsD0oAWPylMrGITVNukk5 ycyw==
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=mrK5ULr7V2KItPWn7p8QQ0/W4oHEmcTL4vMb8piVVSI=; b=Bmyet8ljO22qZmnDxOg9lp+xOh/pGFBg8jYeWcMBt0EFHwnEd7RkYFg/y7kbkF3Vbl 87N/v79spJrXk/TKuwRl8UMVSJB1oglokFh8Wg04qg6wr/xRexqRgFUO7DTW94gXStZN m0uhXqkldaNTjuQsrCApmrSqs7ZiVra0/Y9/GNVPeZrOZ2Z1F3PzRmmBTmHLfe000wYJ yUlvR439Nu5g5UNuzvSGBTbEJNVBHgECB5m/HiABL6cANN14UvLIE6jMuR61TYbTMf6P pJPOaNwdoe/CswGiJULokmj2s0UrLRRucT1pbO5uewdOuD9i6ebQi2ViYun2agJzO3Ky 0HaA==
X-Gm-Message-State: ABUngveGyfbn/+E+NY3IktUwMTvzcLXYKlCquWNyRcYN4arS1kfZDEoSp+CmyKZaV2Kxr01UOj57dPfv0brtHw==
X-Received: by with SMTP id z13mr1373011vkd.41.1478729269752; Wed, 09 Nov 2016 14:07:49 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 9 Nov 2016 14:07:48 -0800 (PST)
Received: by with HTTP; Wed, 9 Nov 2016 14:07:48 -0800 (PST)
In-Reply-To: <>
References: <> <>
From: Watson Ladd <>
Date: Wed, 09 Nov 2016 14:07:48 -0800
Message-ID: <>
Content-Type: multipart/alternative; boundary="001a1140fd58d7ba250540e57c8c"
Archived-At: <>
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 22:07:54 -0000

> There is no magic involved here.
> Apps *know* when to perform reads, and when not to perform reads.
> The middleware doesn't because it is protocol ignorant (it is used
> by SMTP, ldaps, HTTPS, HTTP/2.0, websockets, etc).
> Think of a simple HTTP-based server app receiving a HTTP/1.0 request
> from a TLS-stack on top of a blocking network socket.  If the App would
> keep calling SSL_read() (for an OpenSSL-style API), it would get stuck
> (blocked on read), and at some point the client would give up and
> close the connection (with close_notify or TCP RST), and the server
> waking from either the processing of the close_notify or the TCP RST
> would be unable to deliver a response (which the client would not read
> anyway).

This is an example of the application not knowing which channels are ready.
So no the app doesn't "know when to read".

> Whether or not the calling App wants to shutdown a communication
> at different times in both directions depends on the existing semantics
> of that application (which has just added TLS protection around its
> communication).  Reading and processing a close_notify in the TLS stack
> (e.g. OpenSSL) will tear down *BOTH* directions immediately, and preclude
> any further of sending of responses by the application, so the middleware
> really will want to hold of processing of close_notify alerts unless
> _explicitly_ asked to read further AppData by the application.
> With TLS up to TLSv1.2 streaming is no problem, the middleware can
> easily recognize non-AppData records and avoid passing them to
> the TLS stack for processing unless the application explicitly asks
> the middleware to do so.  When TLSv1.3 hides the ContentType,
> the fact that a close_notify was received & processed can only be
> determined after the fact, when the shattered pieces are on the floor.
> Communication in the other direction will be impossible, and it will
> not be possible to prevent this from happening.
> While it is conceivable to jump hoops and implement new APIs and
> callback for the TLS stack to allow the middleware instrumenting
> and holding off the processing of TLS close_notify, this is not
> going to allow a drop-in replacement of an existing TLSv1.2 with
> a ContentType-hiding TLSv1.3 implementation underneath an existing
> application.

Yes, you will need to update the middleware component as well. Why is this
a problem?

> For SSLv3->TLSv1.2, there was *NO* such backwards-incompatibilty.
> We were able just fine to drop-in a TLSv1.2 implementation underneath
> apps that were originally built on top of an SSLv3-only stack.
> >
> > Can you explain further why this is a problem: are you expecting that
> > if you send application data to the client after sending the
> > itself, the client will consume it?
> >
> > Can you help me understand?
> TCP is a full-duplex communication channel and allows shutdown for each
> of the two communication directions performed independently.  There are
> existing communication protocols (other than HTTP) that _use_ independent
> shutdown, and may want to continue using it even after starting to
> protect their original cleatext communication with TLS.
> If you're vaguely familiar with OpenSSL:
> when SSL_read() has received and processed a TLS record with a
> alert, do you know what happens to further calls of SSL_write() of the
> handle, which technically is _the_other_ communication direction.

Is this the case? Actually alerts trigger teardown of both sides. There is
no half open state for TLS. Nginx manages fine on OpenSSL.

> If you don't know: SSL_write() will fail, because OpenSSL will push out
> a close_notify alert from within SSL_read(), and make the connection
> unusable.  Being able to distinguish AppData records from non-AppData
> records, an application caller of SSL_read() (such as my middleware)
> can prevent loosing the backchannel with no prior warning -- if it
> wants to.  For streaming operation, my middleware DESPERATELY wants to
> prevent the communication channel becoming unusable in both directions
> _before_ the application has received/seen all the app data from the
> -Martin
> _______________________________________________
> TLS mailing list