Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-4572-update-01 - Martin's editorial comments

From: Christer Holmberg <[email-masked]>
Date: Mon, 9 May 2016 07:42:14 +0000

Hi Martin,

Thanks for your comments! This reply addresses the editorial nits and
comments.

>Detailed nits and comments:
>
>s1p2
>
> However, RFC 4572 is currently unclear on whether multiple 'fingerprint'
> [attributes] can be associated

I¹ll fix as suggested.

>s1p2
>
> OLD 
>
> Multiple 'fingerprint' attributes are needed when an endpoint wants to
>provide multiple
> fingerprint, using different hash functions, for a certificate. MAYBE
> Multiple 'fingerprint' attributes are needed when an endpoint wants to
>support updated
> hash functions without sacrificing interoperability with existing
>implementations.
>
> ...However I think that this is not a feature that 4572 implies, so
> you should instead remove this and add to p4 (my wording is clumsy,
> but I hope the idea is OK):
>
> NEW
>
> This change also requires that multiple 'fingerprint' attribute are
> included so that implementations are able to add hashes generated with
> updated hash functions alongside those that are needed to interoperate
> with existing implementations.

Ok.

So, p2 will say:

"RFC 4572 defines the SDP 'fingerprint' attribute, which is used to
   carry a secure hash value associated with a certificate.  However,
   RFC 4572 is currently unclear on whether multiple 'fingerprint'
   attributes can be associated with a single SDP media description ("m=
   line") [RFC4566], and the associated semantics.  Multiple
   'fingerprint' attributes are also needed if an endpoint wants to
   provide fingerprints associated with multiple certificates.  For
   example, with RTP-based media, an endpoint might use different
   certificates for RTP and RTCP."

Šand p4 will say:

"RFC 4572 mandates that the hash function used to calculate the
   fingerprint is the same hash function used to calculate the
   certificate signature.  That requirement might prevent usage of
   newer, stronger and more collision-safe hash functions for
   calculating certificate fingerprints.  This change also requires that
   multiple 'fingerprint' attributes can be associated with a single
   "m=" line, so that implementations are able to provide hashes
   generated with updated hash functions alongside those that are needed
   to interoperate with existing implementations.²

Šbecause I assume you want to keep the text regarding multiple
certificates in p2, while moving the text regarding multiple hashes to p4?

>s1p5
>
> OLD
>
> The document also updates the preferred cipher suite to be used [to
>SHA-256], and
> removes the requirement to use the same hash function for calculating
>the certificate 
> fingerprint and certificate signature.

I¹ll fix as suggested.

>s6
><delete the 'p' please>

Done :)

Thanks!

Regards,

Christer

>
>
>On 6 May 2016 at 16:57, Christer Holmberg
><[email-masked]> wrote:
>> Hi,
>>
>>
>>
>> I¹ve submitted a new version (-01) of draft-ietf-mmusic-4572-update. It
>>now
>> contains updated fingerprint handling procedures, based on the
>>discussions:
>> the number of calculated fingerprints for a given cipher suite are
>> independent of each other. And, it¹s enough that one fingerprint,
>>calculated
>> using an algorithm the receiver considers secure enough, matches the
>>used
>> certificiate.
>>
>>
>>
>> There are currently no open issues in the draft, so I encourage people
>>to
>> take a look :)
>>
>>
>>
>> Regards,
>>
>>
>>
>> Christer
>>
>>
>> _______________________________________________
>> mmusic mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mmusic
>>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 9 May 2016 18:43:10 +1000

> certificates in p2, while moving the text regarding multiple hashes to p4?

That was my thought.  It keeps thing sane.