IETF Logo Mail Archive

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

"John R Levine" <johnl@taugh.com> Wed, 02 December 2015 15:54 UTC

Return-Path: <johnl@taugh.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 F11161A92F2 for <uta@ietfa.amsl.com>; Wed, 2 Dec 2015 07:54:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.137
X-Spam-Level:
X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 iuNSEER--bKg for <uta@ietfa.amsl.com>; Wed, 2 Dec 2015 07:54:12 -0800 (PST)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA3621A92FC for <uta@ietf.org>; Wed, 2 Dec 2015 07:54:08 -0800 (PST)
Received: (qmail 16487 invoked from network); 2 Dec 2015 15:54:07 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=4066.565f141f.k1512; bh=O2+Rw/dSwuXuYMbg71XILm+adRPdEIAMzfcTtIs+eyE=; b=Tsv5O/vt2VVm3zgYiIIErO2RRtA5aE2GEDxc2HylAQ28UeHGShiRYlPIRcInReenAC35NPm9CViH2r5xdrKsQ4ARm20CQW7HCpbp7vyEi6795aCKSWu25l8CgaVEiwk6lP/ofjU+VgU4U50QaN1cGAAzQXExaVzatv95hgnHft/OLeTvvZ9jW06GhlrW93HA06X+55IUbUCWwS4jRNLF3y+07pUAU/ja4HgIcbnCuuBUlur9oN8NcWiQSraDN79T
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=4066.565f141f.k1512; bh=O2+Rw/dSwuXuYMbg71XILm+adRPdEIAMzfcTtIs+eyE=; b=oDM/K/bz6VEdmSir6bT+pMco4TxnW+qGvxNC9TAvWtqUqeLCQ/xpIq5aOm3q76gd6ougqpjpRPqeiI+CRV0/OllMtPSLkqtAvCvQy0z8hfFGbPei0+VrztrOTPmeFfY7xNrgKJTsiX43kKQ/hFvawsmxJpjcT+N7gV/iYKYCMfoum8VAU7ernU3kWbYPwMa7BzS6uq3SulzBLQAY1PhMxR5FoyyYRjvQSK0Wy7fa5mnclsZOF/AMvt56SihgI03U
Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 02 Dec 2015 15:54:07 -0000
Date: Wed, 02 Dec 2015 10:54:06 -0500
Message-ID: <alpine.OSX.2.11.1512021051220.21537@ary.lan>
From: John R Levine <johnl@taugh.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>
In-Reply-To: <565F12D1.6050700@isode.com>
References: <20151202151716.22721.qmail@ary.lan> <565F0DC8.9060507@isode.com> <alpine.OSX.2.11.1512021039490.21537@ary.lan> <565F12D1.6050700@isode.com>
User-Agent: Alpine 2.11 (OSX 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Archived-At: <http://mailarchive.ietf.org/arch/msg/uta/sj-5SQk0aqFGezQwX90X_B9o6IU>
Cc: uta@ietf.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 15:54:13 -0000

>> If there's no SRV-ID, you don't need SNI since all 100,000 domains point at 
>> the same server name.
> Yes, but then they can't be verified automatically by MUAs, so each of them 
> would need to be approved manually by users.

Aren't we back to RFC 6186?  If the MUA developers are going to open up 
the code to add new checks for the server's certificate, why not also add 
checks for the appropriate SRV records?  I realize that not everyone does 
DNSSEC, but the SRV check will be a lot more effective than yet another 
baffling warning that ends with "check OK if you ever want to see your 
mail again".

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

v2.23.0 | Report a Bug | By Email