Hi Jeffrey,
Here is an extract of the paragraphs dealing with TLS in the draft, so that
you can easily see what to comment (wording improvement, missing stuff...).
The point of COMPRESS as an NNTP extension is to behave as a
transport layer, similar to STARTTLS [RFC4642]. Compression can
therefore benefit to all NNTP commands sent or received after the use
of COMPRESS.
It kind of sounds doomed under threat models with active attackers.
The active attacker can swallow the STARTTLS message and no one would
be the wiser.
How does the protocol thwart downgrades under active attackers?
First of all, one should note that STARTTLS is not widely used in
practice for NNTP. Implicit TLS on a dedicated port (TCP 563) is the
common way for NNTP clients to negotiate a TLS layer.
To answer your question, the Security Considerations Section of RFC 4642
(Using TLS with NNTP) mentions:
Before the TLS handshake has begun, any protocol interactions are
performed in the clear and may be modified by an active attacker.
For this reason, clients and servers MUST discard any sensitive
knowledge obtained prior to the start of the TLS handshake upon the
establishment of a security layer. Furthermore, the CAPABILITIES
command SHOULD be re-issued upon the establishment of a security
layer, and other protocol state SHOULD be re-negotiated as well.
[...]
During the TLS negotiation, the client MUST check its understanding
of the server hostname against the server's identity as presented in
the server Certificate message, in order to prevent man-in-the-middle
attacks. Matching is performed according to these rules:
- The client MUST use the server hostname it used to open the
connection (or the hostname specified in TLS "server_name"
extension [TLS-EXT]) as the value to compare against the server
name as expressed in the server certificate. The client MUST NOT
use any form of the server hostname derived from an insecure
remote source (e.g., insecure DNS lookup). CNAME canonicalization
is not done.
- If a subjectAltName extension of type dNSName is present in the
certificate, it SHOULD be used as the source of the server's
identity.
- Matching is case-insensitive.
- A "*" wildcard character MAY be used as the left-most name
component in the certificate. For example, *.example.com would
match a.example.com, foo.example.com, etc., but would not match
example.com.
- If the certificate contains multiple names (e.g., more than one
dNSName field), then a match with any one of the fields is
considered acceptable.
If the match fails, the client SHOULD either ask for explicit user
confirmation or terminate the connection with a QUIT command and
indicate the server's identity is suspect.
Additionally, clients MUST verify the binding between the identity of
the servers to which they connect and the public keys presented by
those servers. Clients SHOULD implement the algorithm in Section 6
of [PKI-CERT] for general certificate validation, but MAY supplement
that algorithm with other validation methods that achieve equivalent
levels of verification (such as comparing the server certificate
against a local store of already-verified certificates and identity
bindings).
A man-in-the-middle attack can be launched by deleting the STARTTLS
capability label in the CAPABILITIES response from the server. This
would cause the client not to try to start a TLS session. Another
man-in-the-middle attack would allow the server to announce its
STARTTLS capability, but alter the client's request to start TLS and
the server's response. An NNTP client can partially protect against
these attacks by recording the fact that a particular NNTP server
offers TLS during one session and generating an alarm if it does not
appear in the CAPABILITIES response for a later session. (Of course,
the STARTTLS capability would not be listed after a security layer is
in place.)
If the client receives a 483 or 580 response, the client has to
decide what to do next. The client has to choose among three main
options: to go ahead with the rest of the NNTP session, to (re)try
TLS later in the session, or to give up and postpone
newsreading/transport activity. If an error occurs, the client can
assume that the server may be able to negotiate TLS in the future and
should try to negotiate TLS in a later session. However, if the
client and server were only using TLS for authentication and no
previous 480 response was received, the client may want to proceed
with the NNTP session, in case some of the operations the client
wanted to perform are accepted by the server even if the client is
unauthenticated.
Does it answer your question?
--
Julien ÉLIE
« Contra factum non datur argumentum. »
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
