Re: [Uta] UTA: Server certificate management (Re: Last Call: <draft-ietf-uta-email-tls-certs-05.txt>)

Alexey Melnikov <alexey.melnikov@isode.com> Wed, 02 December 2015 12:19 UTC

Return-Path: <alexey.melnikov@isode.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 971AB1A8927 for <uta@ietfa.amsl.com>; Wed, 2 Dec 2015 04:19:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level:
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 e3tXJcDWl1vc for <uta@ietfa.amsl.com>; Wed, 2 Dec 2015 04:19:58 -0800 (PST)
Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 452381A890F for <uta@ietf.org>; Wed, 2 Dec 2015 04:19:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1449058797; d=isode.com; s=selector; i=@isode.com; bh=X5ToFU1t8mmBZpYBaXcrAdS/UoXaoC5Grr99ClE2ZzQ=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=gA9UGI7DbuK5bhOAsP7MKwLJeAR2EvPCS0j1NcH1USbJW/O4h3beGXdUXTITG+HbDu+72E JvW8D6IamnT9ohvg5kvnYQMUA/d3HrvLGBNxP3bMHAvMWI9mNA22wCxueMAb9l0QkmE4xs aDNjR0UIg1U49NMxL/m4KtoZT+x5cD0=;
Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id <Vl7h7AAlTm=J@statler.isode.com>; Wed, 2 Dec 2015 12:19:57 +0000
Message-ID: <565EE1DB.4030707@isode.com>
Date: Wed, 02 Dec 2015 12:19:39 +0000
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
To: John Levine <johnl@taugh.com>, uta@ietf.org
References: <20151201183802.18651.qmail@ary.lan>
In-Reply-To: <20151201183802.18651.qmail@ary.lan>
MIME-Version: 1.0
Content-Type: text/plain; charset="gbk"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/uta/e0aD16uBRq80kkmYdinUcFDC9wo>
Cc: ietf-dane@dukhovni.org
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: Wed, 02 Dec 2015 12:19:59 -0000

On 01/12/2015 18:38, John Levine wrote:
>> 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.
> Then we have a problem, since the SRV-ID is just an assertion from the
> server.
But it has to be signed by a CA. If the CA is not happy for you to 
assert SRV-ID, it should not include SRV-ID in an issued certificate.

> What's to keep an evil MITM from putting dukhovni.org as a
> SRV-ID in its submit and imaps certificate?  If the cert is signed,
> the signer will look at the DNS-ID.  There's no way other than RFC
> 6186 to tell what the real pop or imap servers for a domain are.