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
Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 24 November 2015 05:51 UTC
Return-Path: <ietf-dane@dukhovni.org>
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 C69F61B2DCA; Mon, 23 Nov 2015 21:51:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 ULGkwL7HKCGZ; Mon, 23 Nov 2015 21:51:43 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 641B11B2DC5; Mon, 23 Nov 2015 21:51:43 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 4F3AB284E34; Tue, 24 Nov 2015 05:51:41 +0000 (UTC)
Date: Tue, 24 Nov 2015 05:51:41 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: ietf@ietf.org, uta@ietf.org
Message-ID: <20151124055141.GD18315@mournblade.imrryr.org>
References: <20151120142925.18541.72151.idtracker@ietfa.amsl.com> <0C545746-E755-487D-8F0C-BB5981C2C5EE@vigilsec.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <0C545746-E755-487D-8F0C-BB5981C2C5EE@vigilsec.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <http://mailarchive.ietf.org/arch/msg/uta/nEyaA9TVIMCb39o9OqIq-MXdi8w>
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 05:51:46 -0000
On Fri, Nov 20, 2015 at 04:36:41PM -0500, Russ Housley wrote: > I support this document going forward. Below I suggest four improvements to the document. I also have some suggested improvements: Section 2: reference identifier: (as defined in [RFC6125]) One of the domain names associated by the email (i.e., an SMTP, IMAP, POP3 or ManageSieve) client with the destination email server and optionally an application service type for performing name checks on the server certificate. When name checks are applicable, at least one of the reference identifiers MUST match an [RFC6125] DNS-ID or SRV-ID (or if none are present the [RFC6125] CN-ID) of the server certificate. This speaks of a "destination email server", but none of the protocols in question deliver email to its "destination". These are submission and mailstore access protocols. So the phrase "destination email server" is perhaps misleading. I would suggest replacing "destination" with "target". Section 3: 1. For DNS-ID and CN-ID identifier types the client MUST use one or more of the following as "reference identifiers": (a) the right hand side of the email address, (b) the hostname it used to open the connection (without CNAME canonicalization). The client MAY also use (c) a value securely derived from (a) or (b), such as using "secure" DNSSEC validated lookup. The problem here is that "the right hand side of the email address" is not clearly defined, which email address? It seems that the email address in question here is that of the user (performing mail submission or accessing his own mailbox). Also I would replace "right hand side" with "domain part" (RFC 5322 email addresses are <localpart@domainpart>). 2. When using email service discovery procedure specified in [RFC6186] the client MUST also use the right hand side of the email address as another "reference identifier" to compare against SRV-ID identifier in the server certificate. As noted in Section 7 of RFC7672, when (don't know of any MUAs that do this now) MUAs start using DNS SRV records to indirectly map service domains to target servers, the WebPKI security model breaks down in some of the same ways as it does for SMTP with MX records (https://tools.ietf.org/html/rfc7672#section-1.3.2). In particular, using the target server hostname from from the SRV record is not secure unless that SRV record is protected with DNSSEC. Once it is protected with DNSSEC and the client has the capacity to perform the verification, it may as well do DANE (since it then unavodably trusts the DNS). The upshot is that once 6186 comes into play the text from part "1" is no longer applicable as-is. This is because (b) is no longer securely obtained (absent DNSSEC it is the result of an insecure SRV lookup). So part (b) of "1" only applies when DNSSEC is available. However SRV-ID is fine, because it is the domainpart of the user's email address and not subject to active attacks on DNS. This is why in the second numbered list we have (without the rationale): 2. Support for the SRV-ID identifier type (subjectAltName of SRVName type [RFC4985]) is REQUIRED for email client software implementations that support [RFC6186]. List of SRV-ID types for email services is specified in [RFC6186]. For the ManageSieve protocol the service name "sieve" is used. and then correspondingly in section 5: 2. If the email services provided are discoverable using DNS SRV as specified in [RFC6186], the Mail Service Provider MUST include the SRV-ID identifier type (subjectAltName of SRVName type [RFC4985]) for each type of email service in Certificate Signing Requests. and in the examples in Section 6, which describe only SRV-IDs and not (insecure) DNS-IDs in combination with services discovered via RFC 6186 SRV records. Section 6: More instances of "right hand side" rather than "domainpart". Section 8: TLS Server Identity Check for Email relies on use of trustworthy DNS hostnames when constructing "reference identifiers" that are checked against an email server certificate. Such trustworthy names are either entered manually (for example if they are advertised on a Mail Service Provider's website), explicitly confirmed by the user (e.g. if they are a target of a DNS SRV lookup) or derived using a secure third party service (e.g. DNSSEC-protected SRV records which are verified by the client or trusted local resolver). Future work in this area might benefit from integration with DANE [RFC6698], but it is not covered by this document. This repeats RFC 6186's waving of the "explicitly confirmed by the user" magic wand to make a fundamental gap in the security model appear to go away. The rest of the document seems to require SRV-IDs to avoid this trap, but here suddenly we're back to accepting DNS-IDs arrived at via insecure SRV records, and we just "ask the user". So the question is whether in fact that's the approach, in which case the earlier insistence on SRV-IDs is weakened and perhaps too strong, or whether this is not the case, and the security considerations should specifically explain the issue and state that asking the user is not a good idea, and the the solution is the new SRV-IDs as specified in this document. [ Other options might be DANE 7671/7671, or POSH 7711. ] -- Viktor.
- [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