jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-tls-sni-encryption

Commentary: Trying to address the last comments ( issue ) . 
 I hope this reflects our discussion . 
 Checking in after Roman 's comments on the list .
This document does not present the design of a solution, but provides
guidelines for evaluating proposed solutions.  The need for related
work on the encryption of the Application Layer Protocol Negotiation
(ALPN) parameters of TLS is discussed in hiding-alpn.
This document does not present the design of a solution, but provides
guidelines for evaluating proposed solutions.  (The review of HTTP-
level solutionsin httpfronting is not an endorsement of these
solutions.)  The need for related work on the encryption of the
Application Layer Protocol Negotiation (ALPN) parameters of TLS is
discussed in hiding-alpn.
The SNI is probably also included in the general collection of
metadata by pervasive surveillance actors, for example to identify
services used by surveillance targets.
The SNI is probably also included in the general collection of
metadata by pervasive surveillance actors RFC7258, for example to
identify services used by surveillance targets.
Replacing clear text SNI transmission by an encrypted variant will
also thwart MITM interferences that are sometimes described as
legitimate.  As explained in end-to-end, alternative solutions will
have to be developed.
Replacing clear text SNI transmission by an encrypted variant will
break or reduce the efficacy of the operational practices and
techniques implemented in middle-boxes as described in snileak.  As
explained in end-to-end, alternative solutions will have to be
developed.
Draft: draft-ietf-tls-sni-encryption

Commentary: The delayed merge of PR left a dangling reference in the markdown source . This is an attempt to fix the issue .
There are other classes of solutions in which the master secret is
verified by verifying a certificate provided by the protected
service.  These solutions offer more protection against a Man-In-The-
Middle attack by the fronting service.  The downside is the the
client will not verify the identity of the fronting service with
risks discussed in {#frontingspoofing}, but solutions will have to
mitigate this risks.  Overall, end-to-end TLS to the protected
service is preferable.
There are other classes of solutions in which the master secret is
verified by verifying a certificate provided by the protected
service.  These solutions offer more protection against a Man-In-The-
Middle attack by the fronting service.  The downside is that the
client will not verify the identity of the fronting service, which
enables fronting server spoofing attacks such as the "honeypot"
attack discussed below.  Overall, end-to-end TLS to the protected
service is preferable, but it is important to also provide a way to
authenticate the fronting service.
Draft: draft-ietf-tls-sni-encryption

Commentary: Two sets of comments from   , received after WGLC . One is a reference to the acknowledgement section , in which he would rather not see his name spelled out . The other is about residual risks of fronting server spoofing when only the hidden service is verified in TLS .
There are other classes of solutions in which the master secret is
verified by verifying a certificate provided by the protected
service.  These solutions offer more protection against a Man-In-The-
Middle attack by the fronting service.
There are other classes of solutions in which the master secret is
verified by verifying a certificate provided by the protected
service.  These solutions offer more protection against a Man-In-The-
Middle attack by the fronting service.  The downside is the the
client will not verify the identity of the fronting service with
risks discussed in {#frontingspoofing}, but solutions will have to
mitigate this risks.  Overall, end-to-end TLS to the protected
service is preferable.
Thanks to Daniel Kahn Gillmor for a pretty detailed review of the
initial draft.  Thanks to Stephen Farrell, Mark Orchezowski, Martin
Rex and Martin Thomson for their reviews.
Thanks to Daniel Kahn Gillmor for a pretty detailed review of the
initial draft.  Thanks to Stephen Farrell, Martin Rex Martin Thomson
and employees of the UK National Cyber Security Centre for their
reviews.
Draft: draft-ietf-tls-sni-encryption

Commentary: Adding the " fallback to fronting " requirement , specifying that if third parties replay the connection attempt , they should just see a connection to the fronting server .
It is easy to imagine designs in which the client sends some client
hello extension that points to a secret shared by client and hidden
server.  If that secret is incorporated into the handshake secret,
the exchange will only succeeds if the connection truly ends at the
hidden server.  The exchange will fail if the extension is stripped
by an MITM, and the exchange will also fail if an adversary replays
the extension in a Client Hello.
The problem with that approach is clear.  Adversaries that replay the
extension can test whether the client truly wanted to access the
fronting server, or was simply using that fronting server as an
access gateway to something else.  The adversaries will not know what
hidden service the client was trying to reach, but they can guess.
They can also start directly interrogate the user, or other
unpleasant alternatives.
When designing SNI encryption schemes, we have to take into account
attacks that strip parameters from the Client Hello, or replay
attacks.  In both cases, the desired behavior is to fall back to a
connection with the fronting server, so there is no visble difference
between a regular connection to that server and an atempt to reach
the hidden server.
Draft: draft-ietf-tls-sni-encryption

Commentary: When reviewing the solutions in the draft , I kept bumping on the QUIC use case . And finding that it would not necessarily be supported by the final solution , unless we add the requirement explicitly .
The SNI encryption requirement do not stop with HTTP over TLS.
Multiple other applications currently use TLS, including for example
SMTP RFC5246, DNS RFC7858, or XMPP RFC7590.  These applications too
will benefit of SNI encryption.  HTTP only methods like those
described in httpfrontingtunnels would not apply there.  In fact,
even for the HTTPS case, the HTTPS tunneling service described in
httpfrontingtunnels is compatible with HTTP 1.0 and HTTP 1.1, but
interacts awkwardly with the multiple streams feature of HTTP 2.0
RFC7540.  This points to the need of an application agnostic
solution, that would be implemented fully in the TLS layer.
The Application Layer Protocol Negotiation (ALPN) parameters of TLS
allow implementations to negotiate the application layer protocol
used on a given connection.  TLS provides the ALPN values in clear
text during the initial handshake.  While exposing the ALPN does not
create the same privacy issues as exposing the SNI, there is still a
risk.  For example, some networks may attempt to block applications
that they do not understand, or that they wish users would not use.
In a sense, ALPN filtering could be very similar to the filtering of
specific port numbers exposed in some network.  This filtering by
ports has given rise to evasion tactics in which various protocols
are tunneled over HTTP in order to use open ports 80 or 443.
Filtering by ALPN would probably beget the same responses, in which
the applications just move over HTTP, and only the HTTP ALPN values
are used.  Applications would not need to do that if the ALPN was
hidden in the same way as the SNI.
It is thus desirable that SNI Encryption mechanisms be also able hide
the ALPN.
The TLS handshake is also used over other transports such as UDP with
both DTLS I-D.ietf-tls-dtls13 and QUIC I-D.ietf-quic-tls.  The
requirement to encrypt the SNI apply just as well for these
transports as for TLS over TCP.
This points to a requirement for SNI Encryption mechanisms to also be
applicable to non-TCP transports such as DTLS or QUIC.
Draft: draft-huitema-tls-sni-encryption

Commentary: … fix the various typos flagged by DKG , submit as WG draft .
One of the goals of SNI encryption is to prevent adversaries from
knowing which Hidden Service the client is using.  Successful replay
attacks breaks that goal by allowing adversaries to discover that
service.
The HTTP Fronting solution places a lot of trust in the Fronting
Server.  This required trust can be reduced by tunnelling HTTPS in
HTTPS, which effectively treats the Fronting Server as an HTTP Proxy.
In this solution, the client establishes a TLS connection to the
Fronting Server, and then issues an HTTP Connect request to the
Hidden Server.  This will effectively establish an end-to-end HTTPS
over TLS connection between the client and the Hidden Server,
mitigating the issues described in nocontextsharing.
The HTTP Fronting solution places a lot of trust in the Fronting
Server.  This required trust can be reduced by tunnelling HTTPS in
HTTPS, which effectively treats the Fronting Server as an HTTP Proxy.
In this solution, the client establishes a TLS connection to the
Fronting Server, and then issues an HTTP Connect request to the
Hidden Server.  This will establish an end-to-end HTTPS over TLS
connection between the client and the Hidden Server, mitigating the
issues described in nocontextsharing.
The delegation token design comes from many people, including Ben
Schwartz and Rich Salz.
The delegation token design comes from many people, including Ben
Schwartz, Brian Sniffen and Rich Salz.