Re: [Uta] UTA: Server certificate management (Re: Last Call: <draft-ietf-uta-email-tls-certs-05.txt>)
Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 01 December 2015 17:37 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 7AF8B1B2D20; Tue, 1 Dec 2015 09:37:28 -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 Y0YCr4NiWei9; Tue, 1 Dec 2015 09:37:26 -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 964551B2CE3; Tue, 1 Dec 2015 09:37:26 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 5462A284E35; Tue, 1 Dec 2015 17:37:24 +0000 (UTC)
Date: Tue, 01 Dec 2015 17:37:24 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: ietf@ietf.org, uta@ietf.org
Message-ID: <20151201173724.GH18315@mournblade.imrryr.org>
References: <20151120142925.18541.72151.idtracker@ietfa.amsl.com> <565DAFF8.10603@alvestrand.no>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <565DAFF8.10603@alvestrand.no>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <http://mailarchive.ietf.org/arch/msg/uta/TJvaet4UjnO2uWXuOgj_7WaAns8>
Subject: Re: [Uta] UTA: Server certificate management (Re: Last Call: <draft-ietf-uta-email-tls-certs-05.txt>)
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, 01 Dec 2015 17:37:28 -0000
On Tue, Dec 01, 2015 at 03:34:32PM +0100, Harald Alvestrand wrote: > If I understand this draft correctly, I object. > > It says: > > > 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. The key word in that text is "another". This does not require the server to have a certificate that matches this identifier, provided there is some other some suitable identifier. It provides additional flexibility, not a constraint. NOTE HOWEVER, that use of the server name from the SRV record as a DNS-ID reference identifier offers no security at all absent DNSSEC. So "another" might become "only" in that case. The 6186 approach to address lack of trustworthy identifiers basically boils down to "ask the user". Once the user confirms the SRV record it becomes pinned, and the server name becomes one of the reference identifiers. My question upthread was whether this draft continues that legacy, or departs from it. HOWEVER: > If I understand RFC 6186 correctly, a (possibly large scale) IMAP email > service provider that wishes to serve a new domain "example org" > according to RFC 6186 must do two things: I am not aware of any adoption of RFC 6186. Are there are any MUAs actually doing RFC 6186 SRV lookups? If there are none, is it worth debating? > - Change its certificate to include a complete list of all the domains > it is serving, and have its CA sign off on that certificate. Not needed in the "ask the user" approach, which is what 6186 entails. Also not needed with SRV records protected with DNSSEC. With plain-old SRV records, and no user confirmation, one is left with no trustworthy identifiers other than SRV-ID (_imap.domainpart of user's email address and the like). So, if indeed MUAs want to implement this draft, and "ask the user" is acknowledged as denial of reality, then they MUST use SNI. For example RFC7671 and RFC7672 mandate SNI for DANE clients. Indeed in TLS 1.3 SNI becomes mandatory to implement and send: https://tools.ietf.org/html/draft-ietf-tls-tls13-10#section-8.2 > The reason it cannot provide one certificate per served domain is that > neither this specification nor any other specification I have found says > that the client MUST include any distinguishing information (such as a > Server Name Indication) that says what name it is expecting the server > to provide service for. See above. -- 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