Re: [TLS] close_notify and TLS 1.3
Eric Rescorla <ekr@rtfm.com> Sun, 12 November 2017 01:13 UTC
Return-Path: <ekr@rtfm.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 00BE8127076 for <tls@ietfa.amsl.com>; Sat, 11 Nov 2017 17:13:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 uY-NTQkt4HRr for <tls@ietfa.amsl.com>; Sat, 11 Nov 2017 17:13:55 -0800 (PST)
Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (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 6FA751252BA for <tls@ietf.org>; Sat, 11 Nov 2017 17:13:55 -0800 (PST)
Received: by mail-yw0-x229.google.com with SMTP id y75so10965324ywg.0 for <tls@ietf.org>; Sat, 11 Nov 2017 17:13:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IhMBGGdforyhqeYhxNlhLpUQMVqiN5BAXV5rq9YFLxA=; b=BgpjIO5eS1exB7/sMRr5BAMoP8EkCpfGzz71uJMD8IjWXgUy+coRepn5fwA8nA8acs tHEr+rDL9cOpX8/CJl8vWgZJXgPgdjPu3pvMSAdNpW47WFLoWALw2hB2FtcQwNWRlAbw rUJNk95nFjUhCnZG5qNpOAJMjujv7BrHwu3Ra0Glq+nYVfUsioeMr4yViQ5x4GapQMZX Sw/kPABiIRnINXiu9eZQaB9/C5B3RlYBR7Xn4qUiZZXhkrMM94hXYiryvfIM5sU0M2yU sxvUrSQPJ1Ob4eo1bMYvTM1bhZYTqt6coIshmY57ggyfV8T+DF1FtzhIn4ZebFna/s25 dBag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IhMBGGdforyhqeYhxNlhLpUQMVqiN5BAXV5rq9YFLxA=; b=sJYCs4VW/xiPe2HKzATEKAKc5I7qI/ztIK8L66/NgA++iYZH3X3oIJHBH9hNLN+188 lisF58Aju16LLWHQxHIi55wdzcl6tHoUSkBsMQApVZN2phuAdjK2TFU8e+RM9az8KVwa w5R4fEK2rz7OX6+3nA8eg9Rh1DLrIZuwh/q6HRlZx5j+bznMImdletFUcd9bibU1IVTo TyIovD8p8URiIqOF4v6+oUm3lG8M2o4BUkSWub073Ql3jWBO0D4ZnjzNfrUwyjGDcEP3 qv8KayU3kDk4R/mmEMBhai6Fuw8U6TH2Oj4qnrhN5Nsm1gLr1CVmqXBgBgRdLZiy51wD luug==
X-Gm-Message-State: AJaThX6oJmA77uOhPCqsxzSx3QLTbcVD5MtD+RV7LveRSPC2vWA2Ax2M GBdfUTIbMTehY4LhO+vKsW3LVYqwKWiMlKwakK5umw==
X-Google-Smtp-Source: AGs4zMZV7E+l4YR7bGZpYgotIcBJBSsFc/CoKIMvCca6TyEGWrlFad+5+R7HDd+ErfW4P3Sa8vzIkSRN8mZK7kvuKjQ=
X-Received: by 10.13.192.196 with SMTP id b187mr3417336ywd.416.1510449234641; Sat, 11 Nov 2017 17:13:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.61.12 with HTTP; Sat, 11 Nov 2017 17:13:14 -0800 (PST)
In-Reply-To: <CAF8qwaB2fXoiy8RLdg9Kc+5xAoCgU2JkoHXw8H-xSsEXMWWgXg@mail.gmail.com>
References: <A6C599ED-3F3D-462F-9B39-1FEF6A0B549B@apple.com> <CABkgnnU3OuzEm2gF6BYif4c0evAfzUYH-PpxoERD9xFEosQ_oQ@mail.gmail.com> <CAF8qwaB2fXoiy8RLdg9Kc+5xAoCgU2JkoHXw8H-xSsEXMWWgXg@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 11 Nov 2017 17:13:14 -0800
Message-ID: <CABcZeBPHGNHBtx4c3=jPS8-PJDHF3E608KoDswJucbaiFFkYwg@mail.gmail.com>
To: David Benjamin <davidben@chromium.org>
Cc: Martin Thomson <martin.thomson@gmail.com>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a114edd48151fce055dbeded0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Vo6-iILlvHH-6PgaN0GvPd6Y3c4>
Subject: Re: [TLS] close_notify and TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Sun, 12 Nov 2017 01:13:58 -0000
Initial inspection suggests that NSS behaves the same way, so I would be fine with this change. -Ekr On Sat, Nov 11, 2017 at 3:46 PM, David Benjamin <davidben@chromium.org> wrote: > I think this change is a good idea. > > Our implementation actually does this already anyway. We are happy to > continue servicing writes even when the read half has consumed a > close_notify. I believe we inherited this behavior from OpenSSL, so it > should be there too. Go's crypto/tls implementation appears to also already > do this. > > We don't have a particular need for the half-close semantics that I know > of, but I don't care for the current spec text (it requires yet another > undesirable read/write sync point). Aligning with TCP's semantics is also > generally a good default. > > On Sat, Nov 11, 2017 at 11:18 PM Martin Thomson <martin.thomson@gmail.com> > wrote: > >> This seems like it might be worth looking at. This seems to be >> something that harks back to SSL3 or even earlier. We aren't going to >> make it so that you can rely on this behaviour, but we might be able >> to make it possible to half-close, which for new protocols using TLS >> could be hugely useful. >> >> On Sat, Nov 11, 2017 at 5:21 PM, David Schinazi <dschinazi@apple.com> >> wrote: >> > Hello all, >> > >> > Currently TLS 1.3 specifies close_notify in the same way that TLS 1.2 >> did. >> > I believe that has issues and this might be the right time to fix them. >> > The purpose of close_notify is to protect against data truncation >> attacks, >> > each side is required to send close_notify before closing the write >> side of >> > the transport connection so the other side knows that the data was not >> > truncated. >> > As such, close_notify only needs half-close semantics to prevent >> truncation. >> > >> > However, the specification contains the following text: >> > << Each party MUST send a “close_notify” alert before closing the write >> side >> > of the connection, unless some other fatal alert has been >> transmitted. >> > The other party MUST respond with a “close_notify” alert of its own >> and >> > close >> > down the connection immediately, discarding any pending writes. >> >> > >> > This means that an application-layer client can't send a query then >> close >> > their >> > write transport when they know that they're done, because the server >> would >> > terminate the TLS session before sending the reply. On top of this, when >> > the server receives the close_notify, it may have already sent part of >> the >> > reply >> > (or wrote it to the socket send buffer) so the responding close_notify >> would >> > in effect be inflicting a truncation attack on the client. >> > >> > This doesn't make much difference for HTTP because clients already >> > don't close their write transport after sending a reply, however having >> the >> > option do do this could allow innovation in new protocols that can >> define >> > the semantics of when they use close_notify. An example is DNS PUSH: >> > https://tools.ietf.org/html/draft-ietf-dnssd-push >> > >> > A proposal to solve this problem would be to give close_notify >> half-close >> > semantics: we keep the requirements that a close_notify be sent before >> > closing the transport, and that any data received after a close_notify >> is >> > ignored, but we simply remove the requirement to immediately reply >> > with a close_notify. This has the advantage that current implementations >> > are already compliant but future ones can leverage this improvement. >> > >> > What do you think? Is this worth discussing on Thursday? >> > >> > Thanks, >> > David Schinazi >> > >> > _______________________________________________ >> > TLS mailing list >> > TLS@ietf.org >> > https://www.ietf.org/mailman/listinfo/tls >> > >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > >
- [TLS] close_notify and TLS 1.3 David Schinazi
- Re: [TLS] close_notify and TLS 1.3 Martin Thomson
- Re: [TLS] close_notify and TLS 1.3 David Benjamin
- Re: [TLS] close_notify and TLS 1.3 Eric Rescorla
- Re: [TLS] close_notify and TLS 1.3 David Schinazi
- Re: [TLS] close_notify and TLS 1.3 Eric Rescorla
- Re: [TLS] close_notify and TLS 1.3 Martin Thomson
- Re: [TLS] close_notify and TLS 1.3 David Schinazi
- Re: [TLS] close_notify and TLS 1.3 Ilari Liusvaara
- Re: [TLS] close_notify and TLS 1.3 Hubert Kario
- Re: [TLS] close_notify and TLS 1.3 Eric Rescorla
- Re: [TLS] close_notify and TLS 1.3 David Benjamin
- Re: [TLS] close_notify and TLS 1.3 Hubert Kario
- Re: [TLS] close_notify and TLS 1.3 Eric Rescorla