+1
On Mar 8, 2018, 12:56 PM -0500, Tony Putman , wrote:
> Fully agree. Defer it until there is a need.
> -- Tony
>
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of David Schinazi
> Sent: 08 March 2018 17:48
> To: Tony Putman
> Cc: tls@ietf.org
> Subject: Re: [TLS] TLS
Fully agree. Defer it until there is a need.
-- Tony
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of David Schinazi
Sent: 08 March 2018 17:48
To: Tony Putman
Cc: tls@ietf.org
Subject: Re: [TLS] TLS 1.3, how to close the read side of a connection?
Hi Tony,
I agree with you, TLS should not
David,
I think this is a valid concern. It's been commented on
(https://www.ietf.org/mail-archive/web/tls/current/msg25579.html) that the
draft has NO requirements on the underlying transport. There are potentially
other transports for TLS (such as being worked by the ATLAS WG) which may not
Hi Xuelei,
Can you elaborate on what proxy protocol you're using that can reuse the TCP
connection for follow on connections, and what semantics it has?
As far as I know, SOCKS and HTTP CONNECT don't support this.
Additionally, the close_notify alerts are sent encrypted so the proxy wouldn't
be
Hi Xuelei,
Do you have an example for when you would need to gracefully close the read
side?
If you're downloading a 10GB video and the user cancels the download, you can
simply tear down the TCP connection by sending a RST.
The benefit of having a graceful read close would be for the server to
Well, this is like TCP in that respect. You send close_notify and then you
either stop reading off of or close the TCP socket.
-Ekr
On Wed, Mar 7, 2018 at 9:40 AM, Xuelei Fan wrote:
> Hi,
>
> Per TLS 1.3 draft (Section 6.1, Closure Alerts), the close_notify alert is
>