[spec] comments on the proposed gemini spec revisions

[Stephane Bortzmeyer]

On Mon, Oct 11, 2021 at 08:57:59AM +0200,
 Omar Polo <op at omarpolo.com> wrote 
 a message of 87 lines which said:

> 3. close_notify
> 
> Is it still a problem? :D

Yes :-(

> (Sometimes I've left dangling questions like this hoping for Bortzmeyer
> to chime in and share some stats.  In the past it worked, hope he share
> some this time too ;-)

"50.4 % of URLs do NOT send a proper TLS shutdown (application
close). Even 36.8 % of those who return status 20 are in that case."

The future RFC on HTTP (completely rewritten and reorganised) has a
nice explanation:

9.8.  TLS Connection Closure

   TLS uses an exchange of closure alerts prior to (non-error)
   connection closure to provide secure connection closure; see
   Section 6.1 of [TLS13].  When a valid closure alert is received, an
   implementation can be assured that no further data will be received
   on that connection.

   When an implementation knows that it has sent or received all the
   message data that it cares about, typically by detecting HTTP message
   boundaries, it might generate an "incomplete close" by sending a
   closure alert and then closing the connection without waiting to
   receive the corresponding closure alert from its peer.

   An incomplete close does not call into question the security of the
   data already received, but it could indicate that subsequent data
   might have been truncated.  As TLS is not directly aware of HTTP
   message framing, it is necessary to examine the HTTP data itself to
   determine whether messages were complete.  Handling of incomplete
   messages is defined in Section 8.

   When encountering an incomplete close, a client SHOULD treat as
   completed all requests for which it has received as much data as
   specified in the Content-Length header or, when a Transfer-Encoding
   of chunked is used, for which the terminal zero-length chunk has been
   received.  A response that has neither chunked transfer coding nor
   Content-Length is complete only if a valid closure alert has been
   received.  Treating an incomplete message as complete could expose
   implementations to attack.

   A client detecting an incomplete close SHOULD recover gracefully.

   Clients MUST send a closure alert before closing the connection.
   Clients that do not expect to receive any more data MAY choose not to
   wait for the server's closure alert and simply close the connection,
   thus generating an incomplete close on the server side.

   Servers SHOULD be prepared to receive an incomplete close from the
   client, since the client can often determine when the end of server
   data is.

   Servers MUST attempt to initiate an exchange of closure alerts with
   the client before closing the connection.  Servers MAY close the
   connection after sending the closure alert, thus generating an
   incomplete close on the client side.

And also:

11.3.  Message Integrity
...
   Care is needed however to ensure that connection closure
   cannot be used to truncate messages (see Section 9.8).  User agents
   might refuse to accept incomplete messages or treat them specially.
   For example, a browser being used to view medical history or drug
   interaction information needs to indicate to the user when such
   information is detected by the protocol to be incomplete, expired, or
   corrupted during transfer.  Such mechanisms might be selectively
   enabled via user agent extensions or the presence of message
   integrity metadata in a response.