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

"Ben Campbell" <ben@nostrum.com> Thu, 02 February 2017 18:01 UTC

Return-Path: <ben@nostrum.com>
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 93A721294D6 for <mmusic@ietfa.amsl.com>; Thu, 2 Feb 2017 10:01:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.098
X-Spam-Level:
X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-3.199] 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 a1IAZkChNmWO for <mmusic@ietfa.amsl.com>; Thu, 2 Feb 2017 10:01:43 -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 1870B129978 for <mmusic@ietf.org>; Thu, 2 Feb 2017 10:00:38 -0800 (PST)
Received: from [10.0.1.39] (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 v12I0a39090185 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 2 Feb 2017 12:00:37 -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.39]
From: Ben Campbell <ben@nostrum.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Date: Thu, 02 Feb 2017 12:00:35 -0600
Message-ID: <F276A9A6-2D32-4DDE-9EAB-ADFAB98DD348@nostrum.com>
In-Reply-To: <D4B8F7CE.1749C%christer.holmberg@ericsson.com>
References: <148597343438.19146.978420245557276514.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4BFD8E04@ESESSMB209.ericsson.se> <ED67E387-26CF-4737-8355-01F284997457@cooperw.in> <7594FB04B1934943A5C02806D1A2204B4BFD8EB8@ESESSMB209.ericsson.se> <CAD5OKxtjQde3QYdjFgodc76vpEnKkvOVXgYD+OZ3nvQz4ywSCQ@mail.gmail.com> <D4B8E820.17487%christer.holmberg@ericsson.com> <D4B8F7CE.1749C%christer.holmberg@ericsson.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_6D57CB39-84FE-42FA-B289-889766E78F83_="
Embedded-HTML: [{"HTML":[536, 8936], "plain":[140, 5396], "uuid":"DE6FCB6E-6130-4F6B-B5DA-0BC134189919"}]
X-Mailer: MailMate (1.9.6r5319)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/8_shAb-F0VS0WJcv6WLkzQKqQEM>
Cc: "mmusic-chairs@ietf.org" <mmusic-chairs@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>, Flemming Andreasen <fandreas@cisco.com>, IESG <iesg@ietf.org>, "draft-ietf-mmusic-4572-update@ietf.org" <draft-ietf-mmusic-4572-update@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: Thu, 02 Feb 2017 18:01:45 -0000

That looks good to me. Please submit a new revision when you are ready.

Thanks!

Ben.

On 2 Feb 2017, at 6:49, Christer Holmberg wrote:

> Pull request: https://github.com/fluffy/4572bis/pull/14
>
> Regards,
>
> Christer
>
> From: Christer Holmberg 
> <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>>
> Date: Thursday 2 February 2017 at 13:43
> To: Roman Shpount <roman@telurix.com<mailto:roman@telurix.com>>
> Cc: "alissa@cooperw.in<mailto:alissa@cooperw.in>" 
> <alissa@cooperw.in<mailto:alissa@cooperw.in>>, Flemming Andreasen 
> <fandreas@cisco.com<mailto:fandreas@cisco.com>>, 
> "mmusic-chairs@ietf.org<mailto:mmusic-chairs@ietf.org>" 
> <mmusic-chairs@ietf.org<mailto:mmusic-chairs@ietf.org>>, 
> "draft-ietf-mmusic-4572-update@ietf.org<mailto:draft-ietf-mmusic-4572-update@ietf.org>" 
> <draft-ietf-mmusic-4572-update@ietf.org<mailto:draft-ietf-mmusic-4572-update@ietf.org>>, 
> "iesg@ietf.org<mailto:iesg@ietf.org>" 
> <iesg@ietf.org<mailto:iesg@ietf.org>>, 
> "mmusic@ietf.org<mailto:mmusic@ietf.org>" 
> <mmusic@ietf.org<mailto:mmusic@ietf.org>>
> Subject: Re: [MMUSIC] Alissa Cooper's No Objection on 
> draft-ietf-mmusic-4572-update-12: (with COMMENT)
> Resent-From: <alias-bounces@ietf.org<mailto:alias-bounces@ietf.org>>
> Resent-To: Christer Holmberg 
> <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>>, 
> Jonathan Lennox <jonathan@vidyo.com<mailto:jonathan@vidyo.com>>
> Resent-Date: Thursday 2 February 2017 at 13:43
>
> Hi,
>
> Ok, it seems like there is stronger preference for removing the text, 
> and nobody has objected.
>
> So, I will remove the text in the next version of the document.
>
> Regards,
>
> Christer
>
> From: Roman Shpount <roman@telurix.com<mailto:roman@telurix.com>>
> Date: Wednesday 1 February 2017 at 22:34
> To: Christer Holmberg 
> <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>>
> Cc: "alissa@cooperw.in<mailto:alissa@cooperw.in>" 
> <alissa@cooperw.in<mailto:alissa@cooperw.in>>, Flemming Andreasen 
> <fandreas@cisco.com<mailto:fandreas@cisco.com>>, 
> "mmusic-chairs@ietf.org<mailto:mmusic-chairs@ietf.org>" 
> <mmusic-chairs@ietf.org<mailto:mmusic-chairs@ietf.org>>, 
> "draft-ietf-mmusic-4572-update@ietf.org<mailto:draft-ietf-mmusic-4572-update@ietf.org>" 
> <draft-ietf-mmusic-4572-update@ietf.org<mailto:draft-ietf-mmusic-4572-update@ietf.org>>, 
> "iesg@ietf.org<mailto:iesg@ietf.org>" 
> <iesg@ietf.org<mailto:iesg@ietf.org>>, 
> "mmusic@ietf.org<mailto:mmusic@ietf.org>" 
> <mmusic@ietf.org<mailto:mmusic@ietf.org>>
> Subject: Re: [MMUSIC] Alissa Cooper's No Objection on 
> draft-ietf-mmusic-4572-update-12: (with COMMENT)
>
> I am for removing the text.
>
> _____________
> Roman Shpount
>
> On Wed, Feb 1, 2017 at 3:18 PM, Christer Holmberg 
> <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> 
> wrote:
> Does anyone object to deleting the text? Martin? Ekr? Roman? Cullen?
>
> Regards,
>
> Christer
>
> -----Original Message-----
> From: Alissa Cooper 
> [mailto:alissa@cooperw.in<mailto:alissa@cooperw.in>]
> Sent: 01 February 2017 22:15
> To: Christer Holmberg 
> <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>>
> Cc: IESG <iesg@ietf.org<mailto:iesg@ietf.org>>; 
> draft-ietf-mmusic-4572-update@ietf.org<mailto:draft-ietf-mmusic-4572-update@ietf.org>; 
> Flemming Andreasen <fandreas@cisco.com<mailto:fandreas@cisco.com>>; 
> mmusic-chairs@ietf.org<mailto:mmusic-chairs@ietf.org>; 
> mmusic@ietf.org<mailto:mmusic@ietf.org>
> Subject: Re: Alissa Cooper's No Objection on 
> draft-ietf-mmusic-4572-update-12: (with COMMENT)
>
>
>> On Feb 1, 2017, at 3:04 PM, Christer Holmberg 
>> <christer.holmberg@ericsson.com<mailto: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
>>
>>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org<mailto:mmusic@ietf.org>
> https://www.ietf.org/mailman/listinfo/mmusic


> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic