Re: [MMUSIC] Alissa Cooper's No Objection on draft-ietf-mmusic-4572-update-12: (with COMMENT)

Alissa Cooper <alissa@cooperw.in> Wed, 01 February 2017 20:14 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A24AB1293F9; Wed, 1 Feb 2017 12:14:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level:
X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=XG2sWzHc; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=Vr0RSpkL
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 KMoylOfNEKV1; Wed, 1 Feb 2017 12:14:49 -0800 (PST)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5988612956E; Wed, 1 Feb 2017 12:14:49 -0800 (PST)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id C0E93209E6; Wed, 1 Feb 2017 15:14:48 -0500 (EST)
Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Wed, 01 Feb 2017 15:14:48 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=kLmu8YPTRxqRzN0 S8CTwzD7VDdE=; b=XG2sWzHc6cW72a9gtCZlm9cSX39mxZd0MX7Eni1Z83Q14v7 zslGvRYAmWxmu4PpbgTyBBHNkDo72FlTK0BNC3S5uLbG50vb1/Iau542yjnLG8dU WwOwqPZppQsyvT7yMR2LOflHIvkTUc2Ry/sgySa7+QuOvRknVoL2qGf8U5+g=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=kLmu8YPTRxqRzN0S8CTwzD7VDdE=; b=Vr0RSpkL+rxTcqiOf5rN PvfFoccIqH1daR5y6cJ4L55Lq89DpfxgiPApuidSg2goheQyEbs8lrHsaXlqr6El j9EXi+CFFyBTlPiWPCFFy/2DJNYyi1ENx6oEVghonxjl6G2K2pBWfY9ZkNjAcktl Sx0Ig8fZUWGVpKH6TcJ2zGc=
X-ME-Sender: <xms:uEGSWNa7nUhykPa78KsWm8-AcfueW0oIH6-8zBAnhWNmN5hUWST3Aw>
X-Sasl-enc: VFDJeQYt9ONlCN7OOy7mLxW8Girz2cDbgP+st0avLuhV 1485980088
Received: from dhcp-10-150-9-217.cisco.com (unknown [173.38.117.85]) by mail.messagingengine.com (Postfix) with ESMTPA id 5779E241E0; Wed, 1 Feb 2017 15:14:48 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BFD8E04@ESESSMB209.ericsson.se>
Date: Wed, 01 Feb 2017 15:14:47 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <ED67E387-26CF-4737-8355-01F284997457@cooperw.in>
References: <148597343438.19146.978420245557276514.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4BFD8E04@ESESSMB209.ericsson.se>
To: Christer Holmberg <christer.holmberg@ericsson.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/aBHJBJyZG5kcZQipkfZ4he9WwVQ>
Cc: Flemming Andreasen <fandreas@cisco.com>, "mmusic-chairs@ietf.org" <mmusic-chairs@ietf.org>, "draft-ietf-mmusic-4572-update@ietf.org" <draft-ietf-mmusic-4572-update@ietf.org>, IESG <iesg@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Alissa Cooper's No Objection on draft-ietf-mmusic-4572-update-12: (with COMMENT)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Feb 2017 20:14:50 -0000

> On Feb 1, 2017, at 3:04 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
> 
> Hi Alissa,
> 
> Thank you for your review! See below.
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
>> Section 5.1 says:
>> 
>> "An endpoint MAY, in addition to its more preferred hash function,
>>  also verify that each certificate used matches fingerprints
>>  calculated using other hash functions.  Unless there is a matching
>>  fingerprint for each tested hash function, the endpoint MUST NOT
>>  establish the TLS connection."
>> 
>> This seems a little weird to me. It's up to the endpoint to decide whether to check for errors, and then if it 
>> does find an error it can't setup the connection, whereas if it just hadn't checked it would be able to setup 
>> the connection. I think it would help to explain why an endpoint would be motivated to check multiple fingerprints.
> 
> I think the only use-case that came up was a situation where the receiver is not sure which hash function is the "strongest", and therefor checks multiple. However, it was also realized that with the multiple set of hash functions such situation is very unlikely to occur.
> 
> So, I could add the following note:
> 
> "NOTE: An endpoint might choose to match each used certificate against fingerprints calculated using multiple
> hash functions e.g, if the endpoint is unsure which hash function is the strongest."
> 
> ...or we could simply delete the text. I personally would go for that, but in case others want to keep it I have no problem with that.

It would make more sense to me to delete it but either solution would be an improvement I think.

Thanks,
Alissa

> 
> Regards,
> 
> Christer
> 
>