[spec] comments on the proposed gemini spec revisions

[Omar Polo]

Stephane Bortzmeyer <stephane at sources.org> writes:

> 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."

It's worst than what I thought!  We know what software this servers are
using?

Thanks for chiming in and also for sharing the excerpt about
close_notify :)

> 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.
>