Re: [Uta] Eric Rescorla's Yes on draft-ietf-uta-email-deep-09: (with COMMENT)

Keith Moore <moore@network-heretics.com> Fri, 27 October 2017 02:56 UTC

Return-Path: <moore@network-heretics.com>
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA83F13F628; Thu, 26 Oct 2017 19:56:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level:
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com
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 LNto5UODDnXZ; Thu, 26 Oct 2017 19:56:41 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ED2013F62D; Thu, 26 Oct 2017 19:56:41 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 6587620B9E; Thu, 26 Oct 2017 22:56:40 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Thu, 26 Oct 2017 22:56:40 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=/UbpPT1Dh2KhNecDYXwWA7MvHe6j7 rwc6NrYy6/+D9M=; b=jRNA3JMi64NCQfN9l7rUh/sko6+Fadq0ZYHoKWkq3XQvJ N2xa9mgXg6/qyeXmS+E0vlSC25oOrDOLafjW3CgjEmIlq70p6lbb1nkhnCItKvfn g7a9M/+gDPrrb/mmyTgSeL110UB4UDKpDvLMTUihMcUPSJN5ByxnOW2vSyOKk014 qOSw/iqhEJNrYqI31QXifNoWneaFInfQFDrNs2UozIO7QywE03PCeAKUq3oTFT4i 4OksbANc/e2E6Oj3BFg5WN6eW2C0t+WJtmujA71S3diqt0e0WYbfE+9PhkY/JNAm q+JqMx5OHLDk/t4WIR+shxqs29O7AJWMNROkG0CKQ==
X-ME-Sender: <xms:aKDyWTpf6QZTA3P-Nequo3tlaWz9Te2iA6VcZ67fPum0xFwxwrCIbQ>
Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 3EE3B7FA90; Thu, 26 Oct 2017 22:56:39 -0400 (EDT)
To: Chris Newman <chris.newman@oracle.com>
Cc: Eric Rescorla <ekr@rtfm.com>, The IESG <iesg@ietf.org>, draft-ietf-uta-email-deep@ietf.org, uta-chairs@ietf.org, leifj@sunet.se, uta@ietf.org
References: <150852235551.15416.1247335476327491501.idtracker@ietfa.amsl.com> <98fddd93-a0a8-efa3-ce2e-530449ae536c@network-heretics.com> <8B20BC5A-A60A-4A31-9345-E970B31BC2C3@oracle.com>
From: Keith Moore <moore@network-heretics.com>
Message-ID: <a67ef1d0-1637-fe48-9fb1-664ad8b3172d@network-heretics.com>
Date: Thu, 26 Oct 2017 22:56:38 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <8B20BC5A-A60A-4A31-9345-E970B31BC2C3@oracle.com>
Content-Type: multipart/alternative; boundary="------------4A286908FE353C23C173C842"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/SfU9MrorbBJHCf1sZR_MYGiNJSM>
Subject: Re: [Uta] Eric Rescorla's Yes on draft-ietf-uta-email-deep-09: (with COMMENT)
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 27 Oct 2017 02:56:43 -0000

On 10/26/2017 07:18 PM, Chris Newman wrote:

>>> Line 304
>>>        preference to services supporting STARTTLS (if offered).  (See
>>>        also Section 4.5.)
>>> I note that 6186 is kind of unclear on what should go in SNI. It 
>>> obviously
>>> needs to be what you are checking against (which 6186 gets right) 
>>> but maybe
>>> it's worth clarifying in this document somewhere.
>> Hmm.    I might need to come back to that one.   Lots of layers to 
>> sift through.  Feel free to suggest text.
>
> I believe RFC 7817 handles this issue sufficiently. 

Not sure whether EKR was referring specifically to the use of SNI with 
SRV records or not, but that's what I had assumed he meant.  So far I 
haven't found any specific advice for (a) what name the MUA should 
specify in SNI, or (b) what names the server should recognize and have 
certificates for.   It's pretty clear that the server needs to have a 
certificate for the name on the right hand side of the SRV record, but 
should it also have a certificate for the name on the left hand side?  
(e.g. _pop3s._tcp.example.com?)  That would potentially make SRV 
discovery more secure.

But I think that's well beyond what the WG (and IESG) approved.   So I 
guess I'm inclined to leave the -10 text as it is now without 
specifically addressing this issue.

Keith