Re: [Uta] Last Call: <draft-ietf-uta-email-tls-certs-05.txt> (Updated TLS Server Identity Check Procedure for Email Related Protocols) to Proposed Standard
Julien ÉLIE <julien@trigofacile.com> Tue, 24 November 2015 21:26 UTC
Return-Path: <julien@trigofacile.com>
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1333D1A8AA6; Tue, 24 Nov 2015 13:26:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level:
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmvwyq1OVmv2; Tue, 24 Nov 2015 13:26:32 -0800 (PST)
Received: from denver.dinauz.org (denver.dinauz.org [37.59.56.11]) by ietfa.amsl.com (Postfix) with ESMTP id 4F26D1A8AC2; Tue, 24 Nov 2015 13:26:30 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by denver.dinauz.org (Postfix) with ESMTP id D7FF46008A; Tue, 24 Nov 2015 22:26:28 +0100 (CET)
Received: from denver.dinauz.org ([127.0.0.1]) by localhost (denver.dinauz.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8VgAZQ1LXYN; Tue, 24 Nov 2015 22:26:28 +0100 (CET)
Received: from macbook-pro-de-julien-elie.home (AAubervilliers-651-1-119-110.w86-198.abo.wanadoo.fr [86.198.34.110]) by denver.dinauz.org (Postfix) with ESMTPSA id A4AEF60011; Tue, 24 Nov 2015 22:26:28 +0100 (CET)
To: ietf@ietf.org, uta@ietf.org
References: <20151120142925.18541.72151.idtracker@ietfa.amsl.com>
From: Julien ÉLIE <julien@trigofacile.com>
Organization: TrigoFACILE -- http://www.trigofacile.com/
Message-ID: <5654D604.9090306@trigofacile.com>
Date: Tue, 24 Nov 2015 22:26:28 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <20151120142925.18541.72151.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/uta/NHEUuEt1mfjsmsMOlAO_k2xK6P8>
Subject: Re: [Uta] Last Call: <draft-ietf-uta-email-tls-certs-05.txt> (Updated TLS Server Identity Check Procedure for Email Related Protocols) to Proposed Standard
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: UTA working group mailing list <uta.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uta>, <mailto:uta-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uta/>
List-Post: <mailto:uta@ietf.org>
List-Help: <mailto:uta-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uta>, <mailto:uta-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Nov 2015 21:26:36 -0000
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. »
- [Uta] Last Call: <draft-ietf-uta-email-tls-certs-… The IESG
- Re: [Uta] Last Call: <draft-ietf-uta-email-tls-ce… Russ Housley
- Re: [Uta] Last Call: <draft-ietf-uta-email-tls-ce… Alexey Melnikov
- Re: [Uta] Last Call: <draft-ietf-uta-email-tls-ce… Leif Johansson
- Re: [Uta] Last Call: <draft-ietf-uta-email-tls-ce… Russ Housley
- Re: [Uta] Last Call: <draft-ietf-uta-email-tls-ce… Viktor Dukhovni
- Re: [Uta] Last Call: <draft-ietf-uta-email-tls-ce… Viktor Dukhovni
- Re: [Uta] Last Call: <draft-ietf-uta-email-tls-ce… stephen.farrell
- Re: [Uta] Last Call: <draft-ietf-uta-email-tls-ce… Alexey Melnikov
- Re: [Uta] Last Call: <draft-ietf-uta-email-tls-ce… Julien ÉLIE
- Re: [Uta] Last Call: <draft-ietf-uta-email-tls-ce… Alexey Melnikov
- Re: [Uta] Last Call: <draft-ietf-uta-email-tls-ce… Leif Johansson
- Re: [Uta] UTA: Server certificate management (Re:… Viktor Dukhovni
- Re: [Uta] UTA: Server certificate management (Re:… John Levine
- Re: [Uta] UTA: Server certificate management (Re:… Viktor Dukhovni
- Re: [Uta] UTA: Server certificate management (Re:… John Levine
- Re: [Uta] UTA: Server certificate management (Re:… Alexey Melnikov
- Re: [Uta] UTA: Server certificate management (Re:… Alexey Melnikov
- Re: [Uta] UTA: Server certificate management (Re:… John R Levine
- Re: [Uta] UTA: Server certificate management (Re:… Alexey Melnikov
- Re: [Uta] UTA: Server certificate management (Re:… John Levine
- Re: [Uta] UTA: Server certificate management (Re:… Alexey Melnikov
- Re: [Uta] UTA: Server certificate management (Re:… John R Levine
- Re: [Uta] UTA: Server certificate management (Re:… Alexey Melnikov
- Re: [Uta] UTA: Server certificate management (Re:… John R Levine
- Re: [Uta] UTA: Server certificate management (Re:… Alexey Melnikov