Hi,
The IESG has received a request from the Using TLS in Applications WG
(uta) to consider the following document:
- 'Updated TLS Server Identity Check Procedure for Email Related
Protocols'
<draft-ietf-uta-email-tls-certs-05.txt> as Proposed Standard
Abstract
This document describes TLS server identity verification procedure
for SMTP Submission, IMAP, POP and ManageSieve clients. It replaces
Section 2.4 of RFC 2595, updates Section 4.1 of RFC 3207, updates
Section 11.1 of RFC 3501, updates Section 2.2.1 of RFC 5804.
The introduction of the draft explains that one of the goal is to define
consistent rules between a few protocols implemented at the same time in
email clients:
Use of TLS by SMTP Submission, IMAP, POP and ManageSieve clients is
described in [RFC3207], [RFC3501], [RFC2595] and [RFC5804]
respectively. Each of the documents describes slightly different
rules for server certificate identity verification (or doesn't define
any rules at all). In reality, email client and server developers
implement many of these protocols at the same time, so it would be
good to define modern and consistent rules for verifying email server
identities using TLS.
Couldn't the draft also update Section 5 of RFC 4642 about the use of
TLS in NNTP?
The NNTP protocol is also a protocol that is found in email clients, so
it would make sense to have consistent rules between email and netnews.
For instance, Thunderbird, SeaMonkey, Gnus, Opera Mail, Windows Live
Mail, Forté Agent or tin (to mention only them) are both email and
netnews clients.
Amongst other things, Section 5 of RFC 4642 says:
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).
Or another idea: wouldn't the draft be worthwhile for a BCP like BCP
195 "Recommendations for Secure Use of Transport Layer Security (TLS)
and Datagram Transport Layer Security (DTLS)"?
It could indeed be "Recommendations for TLS Server Identity Check
Procedure". The advantage would be that the BCP can apply to email
protocols, as well as other protocols using TLS.
It would save time for others, and permit to have homogeneity and
consistent rules across protocols, as well as increasing security.
--
Julien ÉLIE
« Destiny decides who you meet in life but it's only your heart that
can decide who gets to stay in your life. »