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

Christer Holmberg <christer.holmberg@ericsson.com> Wed, 01 February 2017 20:19 UTC

Return-Path: <christer.holmberg@ericsson.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 34C6B1299D7; Wed, 1 Feb 2017 12:19:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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
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 fXwSAkiOsIG8; Wed, 1 Feb 2017 12:19:04 -0800 (PST)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 E75121299A3; Wed, 1 Feb 2017 12:19:00 -0800 (PST)
X-AuditID: c1b4fb2d-a87ff70000007e3d-eb-589242b194ef
Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by (Symantec Mail Security) with SMTP id E9.27.32317.1B242985; Wed, 1 Feb 2017 21:18:59 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0319.002; Wed, 1 Feb 2017 21:18:57 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Alissa Cooper <alissa@cooperw.in>
Thread-Topic: Alissa Cooper's No Objection on draft-ietf-mmusic-4572-update-12: (with COMMENT)
Thread-Index: AQHSfLiANa/BcGrwW06zr+Sq61BcZKFUkZKA///z5ICAABGQgA==
Date: Wed, 01 Feb 2017 20:18:56 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B4BFD8EB8@ESESSMB209.ericsson.se>
References: <148597343438.19146.978420245557276514.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4BFD8E04@ESESSMB209.ericsson.se> <ED67E387-26CF-4737-8355-01F284997457@cooperw.in>
In-Reply-To: <ED67E387-26CF-4737-8355-01F284997457@cooperw.in>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.148]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsUyM2K7je5mp0kRBpunCVtMP/OX0eLgxWWs Fu8v6FrM+DOR2eL8zvVMFlOXP2ZxYPOY8nsjq8eXJy+ZPJYs+ckUwBzFZZOSmpNZllqkb5fA lfGq8TpjQZtwxa5r7WwNjGf5uxg5OSQETCSuvv/N1sXIxSEksI5RYsXvJywQziJGifU7jzJ1 MXJwsAlYSHT/0wZpEBFQlbh67AdYA7PAJ0aJv/feMYMkhAXiJaZ82MsKUZQgcWZaCztIr4iA k0T7dxaQMIuAisStzY/BbF4BX4k7G+YyQ+w6wihx9fQXRpAEp4CdxIrbk8FsRgExie+n1jCB 2MwC4hK3nsxngrhaQGLJnvPMELaoxMvH/1ghbCWJxiVPWCHqdSQW7P7EBmFrSyxb+JoZYrGg xMmZT1gmMIrOQjJ2FpKWWUhaZiFpWcDIsopRtDi1uDg33chYL7UoM7m4OD9PLy+1ZBMjMLIO bvmtu4Nx9WvHQ4wCHIxKPLwGBpMihFgTy4orcw8xSnAwK4nwMlgChXhTEiurUovy44tKc1KL DzFKc7AoifOarbwfLiSQnliSmp2aWpBaBJNl4uCUamDM9/i6pfjyiWod7fKz3kkfr0Rdz7qT NfH6goVpjxdPnWNw2qfGounXnecan3/KOGyb58fV0ed3baqxnKbl2ffVH6WOl+bv9nns/PRN 0+ztu0rPaVt43jh8+u7+7fVhH+W3tPu5T5CcvqEhcoftmvSGi+t4Z5edlkyskZgpnKYw8emx XZ6vH6duUWIpzkg01GIuKk4EAGqBeoWoAgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/IIwVkbHbQsFeWcIPAtpkN4A5RGs>
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:19:17 -0000

Does anyone object to deleting the text? Martin? Ekr? Roman? Cullen?

Regards,

Christer

-----Original Message-----
From: Alissa Cooper [mailto:alissa@cooperw.in] 
Sent: 01 February 2017 22:15
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: IESG <iesg@ietf.org>; draft-ietf-mmusic-4572-update@ietf.org; Flemming Andreasen <fandreas@cisco.com>; mmusic-chairs@ietf.org; 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> 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
> 
>