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

"Leif Johansson" <leifj@sunet.se> Sat, 21 November 2015 16:15 UTC

Return-Path: <leifj@sunet.se>
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 969871ACE24; Sat, 21 Nov 2015 08:15:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.235
X-Spam-Level:
X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, MIME_BASE64_BLANKS=0.001, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] 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 uiUXqN3vojKz; Sat, 21 Nov 2015 08:15:10 -0800 (PST)
Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59E861ACDDA; Sat, 21 Nov 2015 08:15:10 -0800 (PST)
Received: from smtp1.sunet.se (smtp1.sunet.se [192.36.171.214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id tALGF7tU020914 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 21 Nov 2015 17:15:07 +0100
Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.9/8.14.7) with ESMTP id tALGF3nX015039 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Nov 2015 17:15:05 +0100 (CET)
VBR-Info: md=sunet.se; mc=all; mv=swamid.se
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sunet.se; s=default; t=1448122506; bh=P8gTQNC/AESKSjrwPfwhNilAqTf0v10jYpv7L1v/cQI=; h=From:Subject:Date:References:To:In-Reply-To:Cc; b=stpCgtuhLcfbAKeQbPOshuBh2sYtonHB/68s7GyU4OzQhKrsDtCJw6ka/l5TSvybs w6T2mpAAQ6tq6DC0hBgsvis8US/mLqTM2XP3qpDqhwkN7DlUy+bUP6jcy0h47UXady QrK4oCWYCJlnopB9a6bySHIHQeg9eimN2QPhL2jI=
X-Footer: c3VuZXQuc2U=
Received: from [62.102.145.131] ([62.102.145.131]) by kerio.sunet.se (Kerio Connect 8.5.2); Sat, 21 Nov 2015 17:15:00 +0100
From: Leif Johansson <leifj@sunet.se>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Mime-Version: 1.0 (1.0)
Message-Id: <43D830E5-E12F-4688-AD29-718FE4AFC573@sunet.se>
Date: Sat, 21 Nov 2015 17:15:00 +0100
References: <20151120142925.18541.72151.idtracker@ietfa.amsl.com> <0C545746-E755-487D-8F0C-BB5981C2C5EE@vigilsec.com> <56508299.9070505@isode.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>
In-Reply-To: <56508299.9070505@isode.com>
X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN)
X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=59.3294; longitude=18.0686; http://maps.google.com/maps?q=59.3294,18.0686&z=6
X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default)
X-Canit-Stats-ID: 09PIgf7yJ - 00ffd9309ecb - 20151121
X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw
Received-SPF: neutral (e-mailfilter01.sunet.se: 192.36.171.210 is neither permitted nor denied by domain leifj@sunet.se) receiver=e-mailfilter01.sunet.se; client-ip=192.36.171.210; envelope-from=<leifj@sunet.se>; helo=smtp1.sunet.se; identity=mailfrom
X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201
Archived-At: <http://mailarchive.ietf.org/arch/msg/uta/Bx7BCwvlscLLuys0Ebp_1HlLtZI>
Cc: "uta@ietf.org" <uta@ietf.org>, "uta-chairs@ietf.org" <uta-chairs@ietf.org>, "draft-ietf-uta-email-tls-certs@ietf.org" <draft-ietf-uta-email-tls-certs@ietf.org>, Russ Housley <housley@vigilsec.com>, "ietf@ietf.org" <ietf@ietf.org>
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: Sat, 21 Nov 2015 16:15:13 -0000


Skickat från min iPhone

> 21 nov. 2015 kl. 15:41 skrev Alexey Melnikov <alexey.melnikov@isode.com>:
> 
> Hi Russ,
> Thank you for your comments.
> 
>> On 20/11/2015 21:36, Russ Housley wrote:
>> I support this document going forward.  Below I suggest four improvements to the document.
>> 
>> (1)  In Introduction says:
>> 
>>   Note that this document doesn't apply to use of TLS in MTA-to-MTA
>>   SMTP.
>> 
>> Can this be enhanced to include a pointer to where this can be found?
> 
> Currently this is discussed in draft-friedl-uta-smtp-mta-certs, but this
> is not a WG document, so I would rather not have a pointer.
> 

The energy seems to have run out in the group. We should not introduce dependencies that may needlessly hold publication imo.

>> (2)  The next paragraph in the Introduction says:
>> 
>>   The main goal of the document is to provide consistent TLS server
>>   identity verification procedure across multiple email related
>>   protocols.
>> 
>> Since this is a standards-track document, I think it would be better to say:
>> 
>>   This document provides a consistent TLS server identity
>>   verification procedure across multiple email related protocols.
> 
> Changed, thank you.
> 
>> (3)  Section 2 does a lot by reference, which is fine.  I think it would help the reader to duplicate a bit of context from RFC 6125, in particular repeating the definitions of CN-ID, DNS-ID, and SRV-ID.
> 
> Yes, I struggled with this as well. This would be lots of cut & pasted
> text.
> 
>> (4)  Section 3 needs to state first that the certificate passes certification path validation as described in Section 6 of RFC 5280, and second passes the email-specific rules in this section.
> 
> Yes, this was implied. Added to my copy.
>