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

Watson Ladd <watsonbladd@gmail.com> Wed, 09 November 2016 22:07 UTC

Return-Path: <watsonbladd@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 351FD1299BE for <tls@ietfa.amsl.com>; Wed, 9 Nov 2016 14:07:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-QmfZ1AbBFF for <tls@ietfa.amsl.com>; Wed, 9 Nov 2016 14:07:50 -0800 (PST)
Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB3FA129431 for <tls@ietf.org>; Wed, 9 Nov 2016 14:07:50 -0800 (PST)
Received: by mail-vk0-x22c.google.com with SMTP id p9so188126585vkd.3 for <tls@ietf.org>; Wed, 09 Nov 2016 14:07:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 10.31.151.13 with SMTP id z13mr1373011vkd.41.1478729269752; Wed, 09 Nov 2016 14:07:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.176.85.18 with HTTP; Wed, 9 Nov 2016 14:07:48 -0800 (PST)
Received: by 10.176.85.18 with HTTP; Wed, 9 Nov 2016 14:07:48 -0800 (PST)
In-Reply-To: <20161109194210.8ED431A579@ld9781.wdf.sap.corp>
References: <CABcZeBPygA5XOAwnGpV+GL5rJhz81MizWvhgPO1gKsQPkzx=JA@mail.gmail.com> <20161109194210.8ED431A579@ld9781.wdf.sap.corp>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Wed, 9 Nov 2016 14:07:48 -0800
Message-ID: <CACsn0cn1-+1Mk+JL3HMC+7kE9=08kwhK7L0avuDxoikDRq5B=w@mail.gmail.com>
To: mrex@sap.com
Content-Type: multipart/alternative; boundary=001a1140fd58d7ba250540e57c8c
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/WuZeKSo4ihn0xcxNWNWNXSlxbAw>
Cc: tls@ietf.org
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=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
close_notify
> > 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
close_notify
> alert, do you know what happens to further calls of SSL_write() of the
same
> 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
channel.
>
>
> -Martin
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls