Hi Geoffrey,
I bet other protocols would also need similar new specifications to
explain how compression can be enabled.
I think that's the idea. TLS compression only works for NNTP because no
confidentiality is required. In other protocols, there's at least
something (if not everything) where confidentality is desirable and so
compression needs to be specified very carefully if at all.
OK, understood.
Even in NNTP, you don't want compression if you're using
AUTHINFO---and how do you know AUTHINFO will or won't be used at the
time of STARTTLS?
Note that AUTHINFO can also use any available SASL mechanisms instead of
sending plain user/pass. (Depending on the SASL mechanism, a security
layer can be negotiated during the SASL exchange.) Unfortunately, that
facility is not wide-spread in news clients and servers.
To respond to your question, STARTTLS is not available after a
successful authentication. Therefore, it cannot be used after STARTTLS.
RFC 4642 states:
A server supporting the STARTTLS command as defined in this document
will advertise the "STARTTLS" capability label in response to the
CAPABILITIES command ([NNTP] Section 5.2). However, this capability
MUST NOT be advertised once a TLS layer is active (see Section 2.2.2)
or after successful authentication [NNTP-AUTH].
However, though that practice is discouraged, most of news clients still
connect to port 563 (dedicated to NNTPS) and negotiate a TLS security
layer upon connection. They do not use STARTTLS in that case; and
clients can authenticate with AUTHINFO, with an active TLS layer.
--
Julien ÉLIE
« Tant qu'il y a des marmites, il y a de l'espoir ! » (Astérix)
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
