Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-4572-update-03

From: Christer Holmberg <[email-masked]>
Date: Wed, 1 Jun 2016 07:51:50 +0000

Hi,

The github pull request has now been updated with text based on the e-mail
discussions:

https://github.com/cdh4u/draft-4572-update/tree/sha-256-mandatory

Note that the text does NOT yet say anything whether an answer can only
contain the same hash functions as the answer.

Regards,

Christer

On 01/06/16 09:28, "mmusic on behalf of Christer Holmberg"
<[email-masked] on behalf of [email-masked]>
wrote:

>Hi,
>
>>>> SHOULD, unless the endpoint knows that the peer supports a stronger
>>>>hash
>>>> algorithm, or unless the endpoint knows that the peer has not been
>>>>upgraded
>>>> to support the SHA-256 algorithm, or unless the endpoint is used for a
>>>> service, or within an environment, that mandates usage of strong hash
>>>> algorithms
>>>
>>> This covers all my examples, so I would be fine with this language.
>>
>> Might as well be a MUST given the extensive list of caveats.
>
>WFM.
>
>> Editorial: The last comma can be removed, or you could turn this into
>> a bullet list of exemptions.
>
>Will be fixed.
>
>Regards,
>
>Christer
>
>_______________________________________________
>mmusic mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mmusic

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 1 Jun 2016 07:58:06 +0000

Hi,

Even if both endpoints use different hash functions to sign the certificate, Roman’s suggestions would still work as long as the offer contains fingerprints calculated using both hash functions.

Having said that, does it really matter it the answer contains additional hash functions – at long as it also contains one or more hash functions that were present in the offer? Not sure what the use-case would be, though…

Regards,

Christer

From: Roman Shpount <[email-masked]<mailto:[email-masked]>>
Date: Tuesday 31 May 2016 at 23:09
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Christer Holmberg <[email-masked]<mailto:[email-masked]>>, Martin Thomson <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-4572-update-03

On Tue, May 31, 2016 at 2:34 PM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:
According to the old scheme the hash would always match that of the cert. If the certs in the two directions used different hashs, then so would the fingerprints.

The rule you are suggesting would break that.

I do not think there is a single implementation that actually looks at the hash function that is used to sign the certificate when checking the fingerprint, so in reality this will not break anything. For RFC4572 implementations there is rarely a reason to look at certificate signature, since it will only verify who signed the certificate and certificates used by RFC4572 are normally self signed. This entire requirement was in RFC4572 by mistake.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 3 Jun 2016 13:09:09 +0000

What about something like:

“Unless the answerer has other ways of knowing what hash functions the offerer support the answerer MUST calculate, and include in the answer, at least one fingerprint using a hash function that were used for calculating a fingerprint in the associated offer. In addition, the answerer MAY calculate and include fingerprints using hash functions that were not used to calculate fingerprints in the offer.”

Regards,

Christer

From: mmusic <[email-masked]<mailto:[email-masked]>> on behalf of Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Date: Wednesday 1 June 2016 at 10:58
To: Roman Shpount <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-4572-update-03

Hi,

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Fri, 3 Jun 2016 12:57:30 -0400

On Fri, Jun 3, 2016 at 9:09 AM, Christer Holmberg <
[email-masked]> wrote:

> “Unless the answerer has other ways of knowing what hash functions the
> offerer support the answerer MUST calculate, and include in the answer, at
> least one fingerprint using a hash function that were used for calculating
> a fingerprint in the associated offer. In addition, the answerer MAY
> calculate and include fingerprints using hash functions that were not used
> to calculate fingerprints in the offer.”
>
>
LGTM
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 4 Jun 2016 06:46:01 +0000

Hi,

As we don’t talk about offers and answers elsewhere in the document, I modified the text a bit:

    “When an endpoint receives one or more fingerprints from its peer,
    and is about to calculate its own fingerprints, unless
    the endpoint has other ways of knowing what hash functions the peer
    supports the endpoint MUST calculate at least one fingerprint using
    a hash function that was also used by the peer to calculate a
    fingerprint. In addition, the endpoint MAY calculate fingerprints
    using hash functions that were not used by the peer.”

Regards,

Christer

From: Roman Shpount [mailto:[email-masked]]
Sent: 03 June 2016 19:58
To: Christer Holmberg <[email-masked]>
Cc: Paul Kyzivat <[email-masked]>; [email-masked]
Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-4572-update-03

On Fri, Jun 3, 2016 at 9:09 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
“Unless the answerer has other ways of knowing what hash functions the offerer support the answerer MUST calculate, and include in the answer, at least one fingerprint using a hash function that were used for calculating a fingerprint in the associated offer. In addition, the answerer MAY calculate and include fingerprints using hash functions that were not used to calculate fingerprints in the offer.”

LGTM
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 4 Jun 2016 06:59:41 +0000

The change in github:

https://github.com/cdh4u/draft-4572-update/tree/sdp-answer-clarification

Regards,

Christer

From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 04 June 2016 09:46
To: Roman Shpount <[email-masked]>
Cc: [email-masked]; Paul Kyzivat <[email-masked]>
Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-4572-update-03

Hi,

Regards,

Christer

From: Roman Shpount [mailto:[email-masked]]
Sent: 03 June 2016 19:58
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Cc: Paul Kyzivat <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-4572-update-03

LGTM
_____________
Roman Shpount