IETF Logo Mail Archive

Re: [dispatch] Review of draft-campbell-sip-messaging-smime-00

Ben Campbell <ben@nostrum.com> Mon, 06 November 2017 15:48 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A21A13FC4A for <dispatch@ietfa.amsl.com>; Mon, 6 Nov 2017 07:48:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level:
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=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 gGpRanDiGfYR for <dispatch@ietfa.amsl.com>; Mon, 6 Nov 2017 07:48:18 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 036D013FAD9 for <dispatch@ietf.org>; Mon, 6 Nov 2017 07:48:17 -0800 (PST)
Received: from [10.0.1.82] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id vA6FmEx2090941 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 6 Nov 2017 09:48:17 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.82]
From: Ben Campbell <ben@nostrum.com>
Message-Id: <D9882DF5-9D3C-4687-ABE0-FA4821503EFD@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_1112914B-99FF-4D5A-9EDC-B962050420C7"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Date: Mon, 06 Nov 2017 09:48:14 -0600
In-Reply-To: <D70CF5C7-5B3C-4C4D-97A7-84CF0D3AFA71@iii.ca>
Cc: DISPATCH <dispatch@ietf.org>, Russ Housley <housley@vigilsec.com>
To: Cullen Jennings <fluffy@iii.ca>
References: <D70CF5C7-5B3C-4C4D-97A7-84CF0D3AFA71@iii.ca>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/UlbIstUVyClQIaiXV_zkhVBs16U>
Subject: Re: [dispatch] Review of draft-campbell-sip-messaging-smime-00
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Nov 2017 15:48:19 -0000

Thanks for the feedback! Your comment about cert naming is interesting. Russ, do you have thought there?

Thanks!

Ben.

> On Nov 6, 2017, at 8:54 AM, Cullen Jennings <fluffy@iii.ca> wrote:
> 
> 
> Relevant comments ...
> 
> I have implement S/MIME for encryption with SIP and Simple and I think this document provides some excellent clarifications and updates.
> 
> I agree with the the new MTI ciphers.
> 
> Overall, I think the update in this draft improves the security defined in SIMPLE and MSRP.
> 
> 
> Some random food for thought ....
> 
> Getting a cert that says sip:fluffy@cisco.com signed by a LE^H^H some CA is hard. However, getting a cert that says fluffy._sip._users.cisco.com is easy and now can be highly automated. Why not allow certs that looks like that. I realize this is going to cause people to just go "that is so wrong", issues certs with the right thing. But back up for a second and ask what the hardest part of any PKI is.  If th cisco.com domain issues me the email address fluffy, it is pretty easy for it to also publish the TXT records I need for domain validation with the CA. This suggestion does not relevantly reduce the security and is is pretty pragmatic.  The problem is not making it hard for the bad guys, the thing we need most is making it easy for the good guys.
> 
> 
> 
>

v2.23.0 | Report a Bug | By Email