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

From: Flemming Andreasen <[email-masked]>
Date: Mon, 23 May 2016 15:46:11 -0400

Greetings

This is to announce a 2 week WGLC for

     draft-ietf-mmusic-4572-update-03

as Proposed Standard. Please review and provide any comments you may 
have on the document by Monday, June 6, 2016. Comments should be sent to 
the document authors and the MMUSIC WG list. If you review the document 
but do not have any comments, please send a note to that effect as well.

Thanks

-- Flemming (MMUSIC co-chair)

---

From: Martin Thomson <[email-masked]>
Date: Mon, 23 May 2016 16:24:55 -0400

>     draft-ietf-mmusic-4572-update-03

LGTM

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 23 May 2016 20:35:19 +0000

> On May 23, 2016, at 3:46 PM, Flemming Andreasen <[email-masked]> wrote:
> 
> Greetings
> 
> as Proposed Standard. Please review and provide any comments you may have on the document by Monday, June 6, 2016. Comments should be sent to the document authors and the MMUSIC WG list. If you review the document but do not have any comments, please send a note to that effect as well.
> 
> Thanks
> 

4572 forbid the use of MD5 and MD2 in almost all circumstances, by forbidding their use in self-signed certs.  By removing the tie between the certificate hash algorithm and the fingerprint algorithm, we’ve lost this requirement.  Should we re-add it?

SHA-256 is only “preferred”.  Do we want to make its inclusion mandatory, now that we support multiple algorithms?

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 24 May 2016 07:11:39 +0000

Hi,

>4572 forbid the use of MD5 and MD2 in almost all circumstances, by
>forbidding their use in self-signed certs.  By removing the tie between
>the certificate hash algorithm and the fingerprint algorithm, we¹ve lost
>this requirement.  Should we re-add it?

The old text indicated the impacts on the fingerprints based on the rules
for calculating certificate signatures.

But, is it within the scope of 4572 to define the general rules for
calculating certificate signatures? I assume they are defined somewhere
else, and as they no longer impact the fingerprints we don¹t need to
include them. 

>
>SHA-256 is only ³preferred².  Do we want to make its inclusion mandatory,
>now that we support multiple algorithms?

My suggestion would be to NOT make it mandatory, because that would make
existing endpoints that do not include it non-compliant.

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Tue, 24 May 2016 09:10:51 -0700

> else, and as they no longer impact the fingerprints we don¹t need to

I don't think that is Jonathan's point.  The point is that we no
longer have text that expressly forbids bad hashes (to which I would -
carefully - add SHA-1).  Something like:

    [...] the
    defined hash functions are 'SHA-1' [11] [19], 'SHA-224' [11],
    'SHA-256' [11], 'SHA-384' [11], 'SHA-512' [11], 'MD5' [12], and
    'MD2' [13].  Implementations MUST provide and validate 'SHA-256'.
    The 'MD5', and 'MD2' functions are considered weak and MUST NOT be
used.  Though 'SHA-1' is also considered weak, it MAY be used to
retain compatibility with existing implementations.

I think that this captures the intent: if you implement this update,
you will use SHA-256.  However, we concede that you will have to
include SHA-1 and verify fingerprints based on it because there is no
other way to talk to implementations that haven't implemented this
update.

I agree that we shouldn't say anything about the signature in the
certificate.  It doesn't help at all.

> existing endpoints that do not include it non-compliant.

MUST and MUST NOT are our best tools here for encouraging people to
fix their software.  Existing implementations will be non-compliant
with that spec, but if that provides them a little incentive to
upgrade, then that is good.  They will, of course, remain compliant
with 4572.

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 24 May 2016 16:16:45 +0000

+1 to all this — Martin captures (and addresses) my comments perfectly.

> On May 24, 2016, at 12:10 PM, Martin Thomson <[email-masked]> wrote:
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 24 May 2016 17:49:49 +0000

Hi,

Questions for clarification:

Does "provide" mean that endpoints MUST always, for each certificate, include a fingerprint calculated using SHA-256?

Does "validate" mean the endpoints MUST always check the SHA-256-calculated fingerprint (if present) against the used certificate?

Regards,

Christer

-----Original Message-----
From: Jonathan Lennox [mailto:[email-masked]] 
Sent: 24 May 2016 19:17
To: Martin Thomson <[email-masked]>
Cc: Christer Holmberg <[email-masked]>; Flemming Andreasen <[email-masked]>; [email-masked]; mmusic <[email-masked]>
Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-4572-update-03

>> calculating certificate signatures? I assume they are defined 
>> somewhere else, and as they no longer impact the fingerprints we 
>> don¹t need to include them.
> 
>>> SHA-256 is only ³preferred².  Do we want to make its inclusion 
>>> mandatory, now that we support multiple algorithms?
>> 
>> My suggestion would be to NOT make it mandatory, because that would 
>> make existing endpoints that do not include it non-compliant.
>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 24 May 2016 11:38:21 -0700

> Does "validate" mean the endpoints MUST always check the SHA-256-calculated fingerprint (if present) against the used certificate?

Yes and Yes.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 24 May 2016 18:51:06 +0000

So, does anyone object to Martin's suggestion?

Regards,

Christer

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: 24 May 2016 21:38
To: Christer Holmberg <[email-masked]>
Cc: Jonathan Lennox <[email-masked]>; Flemming Andreasen <[email-masked]>; [email-masked]; mmusic <[email-masked]>
Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-4572-update-03

Yes and Yes.

---

From: Roman Shpount <[email-masked]>
Date: Tue, 24 May 2016 14:54:09 -0400

What if I already to include SHA-384 or SHA-512, do I still MUST include
SHA-256?

Regards,
_____________
Roman Shpount

On Tue, May 24, 2016 at 2:51 PM, Christer Holmberg <
[email-masked]> wrote:

> Cc: Jonathan Lennox <[email-masked]>; Flemming Andreasen <
> [email-masked]>; [email-masked]; mmusic <
> [email-masked]>
> > Does "provide" mean that endpoints MUST always, for each certificate,
> include a fingerprint calculated using SHA-256?
> >
> > Does "validate" mean the endpoints MUST always check the
> SHA-256-calculated fingerprint (if present) against the used certificate?
>
>
> Yes and Yes.
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 24 May 2016 12:54:54 -0700

> What if I already to include SHA-384 or SHA-512, do I still MUST include

Do you like interoperability?  Then yes.  Otherwise, don't let a mere
RFC tell you what to do.

---

From: Roman Shpount <[email-masked]>
Date: Tue, 24 May 2016 16:06:40 -0400

> Do you like interoperability?  Then yes.  Otherwise, don't let a mere

So, based on your proposal I should include SHA-1 for backwards interop,
SHA-256 for current and SHA-384 or SHA-512 for future.
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 May 2016 16:09:19 -0400

> Do you like interoperability?  Then yes.  Otherwise, don't let a mere

So this RFC will need to be revised when SHA-256 is broken and no longer 
safe to use?

ISTM that the general mechanism for multiple fingerprints ought to be 
separate from the (transient) recommendations of particular crypto 
algorithms.

	Thanks,
	Paul

---

From: Martin Thomson <[email-masked]>
Date: Tue, 24 May 2016 13:11:22 -0700

> SHA-256 for current and SHA-384 or SHA-512 for future.

Well, the SHA-384 and SHA-512 is your prediction, but if you believe
that they are (or will be) necessary, sure.

I'd have said firstly that they won't be needed, and that only one of
them is likely to be needed if they are.  But I'm willing to accept
the possibility that I'm wrong, and that is why we have an extension
point here.  I wouldn't start using SHA-512 right away though.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 24 May 2016 13:12:35 -0700

> So this RFC will need to be revised when SHA-256 is broken and no longer

When that happens, I will volunteer my time to fix the problem.  I'm
sure that fixing the specs will be much easier than fixing all the
things that depend on SHA-256.

I see no value in doing more specs.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 25 May 2016 07:11:56 +0000

Hi,

In addition to the text change suggested by Martin, I¹ve also identified
the following changes by mandating SHA-256.

-----

Abstract & Introduction:

OLD:

"The document also updates the preferred cipher suite to be used,..."

NEW:

³The document also replaces the preferred cipher suite with a mandate to
support a stronger cipher suite,Š²

-----

Section 5:

The changes to the currently suggested new text between <new> and </new>.

 NEW TEXT:

     Multiple SDP fingerprint attributes can be associated with an m-
     line. This can occur if multiple fingerprints have been calculated
     for a certificate using different hash functions. It can also
     occur if one or more fingerprints associated with multiple
     certificates have been calculated. This might be needed if multiple
     certificates will be used for media associated with an m- line
     (e.g. if separate certificates are used for RTP and RTCP), or where
     it is not known which certificate will be used when the
     fingerprints are exchanged. In such cases, one or more fingerprints
     MUST be calculated for each possible certificate. <new>An endpoint
MUST, as a minimum, calculate a fingerprint using the ŒSHA-256¹
hash function for each possible certificate.</t>

     If fingerprints associated with multiple certificates are
     calculated, the same set of hash functions MUST be used to
     calculate fingerprints for each certificate associated with the
     m- line.

     For each used certificate, an endpoint MUST be able to match at
     least one fingerprint, calculated using the hash function that the
     endpoint supports and considers most secure, with the used
     certificate. <new> If a fingerprint calculated using the ¹SHA-256¹
hash
function is present, the endpoint MUST be able to match it </new>. If
there is no match, the
endpoint MUST NOT establish the TLS connection. In addition, the endpoint
MAY also check
     fingerprints calculated using other hash functions that it has
     received for a match. For each hash function checked, one of the
     received fingerprints MUST match the used certificate.

     NOTE: The SDP fingerprint attribute does not contain a reference to
     a specific certificate. Endpoints need to compare the fingerprint
     with a certificate hash in order to look for a match.

-----

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 26 May 2016 09:41:54 +0000

Are people ok with this?

Regards,

Christer

On 25/05/16 10:11, "mmusic on behalf of Christer Holmberg"
<[email-masked] on behalf of [email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 26 May 2016 11:31:54 +0000

You can also see the suggested changes in this pull request:

https://github.com/cdh4u/draft-4572-update/pull/1/files

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Thu, 26 May 2016 10:47:59 -0400

I still think SHA-256 requirement should be a SHOULD not a MUST.

_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 26 May 2016 14:50:17 +0000

WFM

Sent from my Windows Phone
________________________________
From: Roman Shpount<mailto:[email-masked]>
Sent: ‎26/‎05/‎2016 17:48
To: Christer Holmberg<mailto:[email-masked]>
Cc: Martin Thomson<mailto:[email-masked]>; Paul Kyzivat<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-4572-update-03

_____________
Roman Shpount

On Thu, May 26, 2016 at 5:41 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Are people ok with this?

Regards,

Christer

On 25/05/16 10:11, "mmusic on behalf of Christer Holmberg"
<[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>>
wrote:

>[email-masked]<mailto:[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 27 May 2016 07:15:45 +0000

Hi,

Does anyone object to “SHOULD provide and validate SHA-256”, instead of MUST?

Regards,

Christer

From: mmusic <[email-masked]<mailto:[email-masked]>> on behalf of Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Date: Thursday 26 May 2016 at 17:50
To: Roman Shpount <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[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

WFM

_____________
Roman Shpount

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Fri, 27 May 2016 19:53:50 +1000

> Does anyone object to “SHOULD provide and validate SHA-256”, instead of

What would we say about the reasons for not following this advice?

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 27 May 2016 10:13:33 +0000

We say what we normally say when we use SHOULD: nothing.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Martin Thomson<mailto:[email-masked]>
Sent: ‎27/‎05/‎2016 12:53
To: Christer Holmberg<mailto:[email-masked]>
Cc: Roman Shpount<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Paul Kyzivat<mailto:[email-masked]>
Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-4572-update-03

---

From: Martin Thomson <[email-masked]>
Date: Fri, 27 May 2016 20:55:20 +1000

> We say what we normally say when we use SHOULD: nothing.

That's singularly unhelpful.  Presumably when we decided that a SHOULD
was necessary, we established at least one valid reason that a MUST
wouldn't do.  You see, though Roman is saying that he doesn't want a
MUST, I'm not seeing an actual reason for it not to be.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 27 May 2016 11:09:50 +0000

Hi,

I agree that, when one uses SHOULD, there needs to be text clarifying when
it doesn¹t apply.

But, that doesn¹t always happen, and sometimes it¹s because people don¹t
know when it doesn¹t apply - they just feel that there may be a case (now
or later) where it doesn¹t applyŠ

Having said that, asking Roman for justification is fair.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Fri, 27 May 2016 10:35:43 -0400

Hi Christer,

In general, requirement to always insert SHA-256 is to insure
interoperability. If the network is limited to devices only supporting more
secure hash algorithms, it would be safe not include SHA-256 if higher
security is desired.

For example, when an end point communicates with another end point for
which it is known in advance what fingerprint hash algorithms are
supported, only a single desired fingerprint can be inserted. In other
words, if an end point communicates, let's say, with Firefox version X,
which is known to support SHA-512, and end point desires higher security,
it can include only SHA-512 fingerprint.  There is no need for SHA-256.

Another example, if I design a "higher security" communication service
where I control all the end points, I can only support SHA-512 certificates
within this service and not include SHA-256.

I believe it important to have a solution which works in the described
situations and still claims standard compliance.

This is no different then requirement to support PCMU by all devices
implementing audio/video profile to insure interop (
https://tools.ietf.org/html/rfc3551#section-6), which us a SHOULD.

Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 27 May 2016 13:00:22 -0400

On 5/27/16 10:35 AM, Roman Shpount wrote:
> interoperability. If the network is limited to devices only supporting
> more secure hash algorithms, it would be safe not include SHA-256 if
> higher security is desired.
>
> which is known to support SHA-512, and end point desires higher
> security, it can include only SHA-512 fingerprint.  There is no need for
> SHA-256.
>
> where I control all the end points, I can only support SHA-512
> certificates within this service and not include SHA-256.

So any valid exception will include a hash that the sender thinks is 
*stronger* than SHA-256?

This could be stated as:

"A fingerprint using the SHA-256 hash MUST/SHOULD be included except in 
cases where a fingerprint is included that uses a hash known to be 
stronger than SHA-256."

There could be additional text stating that even in that case SHA-256 
should still be included except in cases where it is known that the 
recipient will support the stronger hash.

	Thanks,
	Paul

> implementing audio/video profile to insure interop
> (https://tools.ietf.org/html/rfc3551#section-6), which us a SHOULD.
>
> Regards,
> _____________
> Roman Shpount
>
> On Fri, May 27, 2016 at 7:09 AM, Christer Holmberg
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     Hi,
>
>     On 27/05/16 13:55, "Martin Thomson" <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>     ><[email-masked]
>     <mailto:[email-masked]>> wrote:

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 27 May 2016 17:16:04 +0000

Hi,

There are two questions: what MUST/SHOULD be sent, and what MUST/SHOULD be validated.

As far as validation is concerned, I am not sure whether we need to mandate the receiver to validate SHA-256. The suggestion has been that the receiver matches a fingerprint that it considers strong enough. 

Whether the sender MUST/SHOULD provide SHA-256 I have no strong opinion about.

Regards,

Christer

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 27 May 2016 20:00
To: Roman Shpount <[email-masked]>; Christer Holmberg <[email-masked]>
Cc: Martin Thomson <[email-masked]>; [email-masked]
Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-4572-update-03

On 5/27/16 10:35 AM, Roman Shpount wrote:
> words, if an end point communicates, let's say, with Firefox version 
> X, which is known to support SHA-512, and end point desires higher 
> security, it can include only SHA-512 fingerprint.  There is no need 
> for SHA-256.
>

This could be stated as:

"A fingerprint using the SHA-256 hash MUST/SHOULD be included except in cases where a fingerprint is included that uses a hash known to be stronger than SHA-256."

There could be additional text stating that even in that case SHA-256 should still be included except in cases where it is known that the recipient will support the stronger hash.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Fri, 27 May 2016 13:16:12 -0400

> So any valid exception will include a hash that the sender thinks is

If an application thinks that another hash is more appropriate and is
supported by remote application, it should be allowed to include just that
hash.

For instance, one can argue if end point knows in advance that it
communicates with a legacy end point that only supports SHA-1, there is no
reason to include SHA-256. It is also likely that this legacy end point
will only support a single fingerprint per m= line, so including both
SHA-256 and SHA-1 can prevent the connection from being setup.

> cases where a fingerprint is included that uses a hash known to be stronger
> than SHA-256."
>

I think what we are trying to document here is:

1. SHA-256 or better hash SHOULD be verified for each certificate to insure
adequate security, except when communicating with legacy end points that
only provide lower quality hashes in fingerprints such as SHA-1 or MD5.

2. SHA-256 SHOULD be included to for each certificate used to insure
interoperability, unless it is known in advance that remote end point is
either legacy end point that does not support SHA-256 or remote end point
supports a better hash which needs to be forced for some reason, such as
better security.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 27 May 2016 19:05:03 +0000

Hi,

We try to avoid unless-it-is-known-in-advance type of procedures.

Regards,

Christer

From: Roman Shpount [mailto:[email-masked]]
Sent: 27 May 2016 20:16
To: Paul Kyzivat <[email-masked]>
Cc: Christer Holmberg <[email-masked]>; Martin Thomson <[email-masked]>; [email-masked]
Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-4572-update-03

On Fri, May 27, 2016 at 1:00 PM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:

So any valid exception will include a hash that the sender thinks is *stronger* than SHA-256?

If an application thinks that another hash is more appropriate and is supported by remote application, it should be allowed to include just that hash.

For instance, one can argue if end point knows in advance that it communicates with a legacy end point that only supports SHA-1, there is no reason to include SHA-256. It is also likely that this legacy end point will only support a single fingerprint per m= line, so including both SHA-256 and SHA-1 can prevent the connection from being setup.

This could be stated as:

1. SHA-256 or better hash SHOULD be verified for each certificate to insure adequate security, except when communicating with legacy end points that only provide lower quality hashes in fingerprints such as SHA-1 or MD5.

2. SHA-256 SHOULD be included to for each certificate used to insure interoperability, unless it is known in advance that remote end point is either legacy end point that does not support SHA-256 or remote end point supports a better hash which needs to be forced for some reason, such as better security.
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Fri, 27 May 2016 15:34:23 -0400

> We try to avoid unless-it-is-known-in-advance type of procedures.
What does this means, exactly?

When I am communicating with a WebRTC browser, I know which browser it is,
and what hash algorithms it supports. Most of the communication networks
require some sort of interop, so it is known in advance what codecs,
encryption algorithm, fingerprint hashes are supported.

It is, actually, it-is-unknown-in-advance procedures that are uncommon in
practice.

In any case, with current proposal, end point can either be complaint to
the new draft or be able to communicate with legacy that supports a single
SHA-1 per m= line. I think this should be enough reason to make inclusion
of SHA-256 a SHOULD instead of MUST.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 30 May 2016 08:05:03 +0000

So, what about something like this:

“SHOULD, unless the endpoint knows that the peer supports a stronger hash algorithm, or unless the endpoint is used for a service, or within an environment, that mandates usage of strong hash algorithms”.

?

Regards,

Christer

From: Roman Shpount <[email-masked]<mailto:[email-masked]>>
Date: Friday 27 May 2016 at 22:34
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[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 Fri, May 27, 2016 at 3:05 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
We try to avoid unless-it-is-known-in-advance type of procedures.

When I am communicating with a WebRTC browser, I know which browser it is, and what hash algorithms it supports. Most of the communication networks require some sort of interop, so it is known in advance what codecs, encryption algorithm, fingerprint hashes are supported.

It is, actually, it-is-unknown-in-advance procedures that are uncommon in practice.

In any case, with current proposal, end point can either be complaint to the new draft or be able to communicate with legacy that supports a single SHA-1 per m= line. I think this should be enough reason to make inclusion of SHA-256 a SHOULD instead of MUST.
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Mon, 30 May 2016 10:30:45 -0400

What about legacy interop? Do we allow sending a single non SHA-256
fingerprint when working with legacy end points, or do we assume this is
covered under original RFC 4572?

Regards,
_____________
Roman Shpount

On Mon, May 30, 2016 at 4:05 AM, Christer Holmberg <
[email-masked]> wrote:

> “SHOULD, unless the endpoint knows that the peer supports a stronger hash
> algorithm, or unless the endpoint is used for a service, or within an
> environment, that mandates usage of strong hash algorithms”.
>
> ?
>
> Regards,
>
> Christer
>
> From: Roman Shpount <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, Martin Thomson <
> [email-masked]>, "[email-masked]" <[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 30 May 2016 17:08:33 +0000

Hi,

In my opinion that is covered by not mandating SHA-256 on the receiving side.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Roman Shpount<mailto:[email-masked]>
Sent: ‎30/‎05/‎2016 17:30
To: Christer Holmberg<mailto:[email-masked]>
Cc: Paul Kyzivat<mailto:[email-masked]>; Martin Thomson<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-4572-update-03

What about legacy interop? Do we allow sending a single non SHA-256 fingerprint when working with legacy end points, or do we assume this is covered under original RFC 4572?

Regards,
_____________
Roman Shpount

On Mon, May 30, 2016 at 4:05 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
So, what about something like this:

?

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Mon, 30 May 2016 13:16:36 -0400

> In my opinion that is covered by not mandating SHA-256 on the receiving

End points should also be able to generate session descriptions with a
single SHA-1 fingerprint per m= line on the sending side, when
communicating with legacy end points. Legacy end points might not be able
to handle multiple fingerprints and might not support SHA-256.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 30 May 2016 17:50:06 +0000

Hi,

> End points should also be able to generate session descriptions with a single SHA-1 fingerprint per m= line on the
> sending side, when communicating with legacy end points. Legacy end points might not be able to handle multiple fingerprints and might not support SHA-256.

I hear what you are saying, but the question is whether we want to cover that, or whether we assume that the endpoint in such cases simply have to operate in "legacy mode", i.e. according to the old RFC.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Tue, 31 May 2016 13:54:30 -0400

On Mon, May 30, 2016 at 1:50 PM, Christer Holmberg <
[email-masked]> wrote:

> single SHA-1 fingerprint per m= line on the
> > sending side, when communicating with legacy end points. Legacy end
> points might not be able to handle multiple fingerprints and might not
> support SHA-256.
>
> I hear what you are saying, but the question is whether we want to cover
> that, or whether we assume that the endpoint in such cases simply have to
> operate in "legacy mode", i.e. according to the old RFC.
>

Whether we want to cover this was exactly the question that what I was
asking. Since we make provisions in the new document to accept descriptions
with a single legacy fingerprint, should we also allow description
generation with a single legacy fingerprint? Otherwise we can simply say
that handling session descriptions with legacy hashes is not allowed and
end points should switch to "legacy mode" described by old RFC if they wish
to support it.

Also, does it ever makes sense to include hashes in the answer which were
not present in the offer? What are the chances for the end point to support
verification of some hash but not generation?

If we introduce the restriction that answer MUST only include hash
algorithms from the offer, and if legacy hashes are acceptable, offers from
legacy end point will automatically generate the legacy compatible answer.

Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 31 May 2016 14:34:48 -0400

On 5/31/16 1:54 PM, Roman Shpount wrote:
> On Mon, May 30, 2016 at 1:50 PM, Christer Holmberg
>     I hear what you are saying, but the question is whether we want to
>     cover that, or whether we assume that the endpoint in such cases
>     simply have to operate in "legacy mode", i.e. according to the old RFC.
>
>
> asking. Since we make provisions in the new document to accept
> descriptions with a single legacy fingerprint, should we also allow
> description generation with a single legacy fingerprint? Otherwise we
> can simply say that handling session descriptions with legacy hashes is
> not allowed and end points should switch to "legacy mode" described by
> old RFC if they wish to support it.
>
> Also, does it ever makes sense to include hashes in the answer which
> were not present in the offer? What are the chances for the end point to
> support verification of some hash but not generation?
>
> algorithms from the offer, and if legacy hashes are acceptable, offers
> from legacy end point will automatically generate the legacy compatible
> answer.

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.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 31 May 2016 18:44:13 +0000

Hi,

>Whether we want to cover this was exactly the question that what I was asking. Since we make
>in the new document to accept descriptions with a single legacy fingerprint, should we also allow
>description generation with a single legacy fingerprint? Otherwise we can simply say that
>handling session descriptions with legacy hashes is not allowed and end points should switch
>to "legacy mode" described by old RFC if they wish to support it.

I don’t think we can refer to text that doesn’t exist anymore (since the draft updates it).

But, if you want to cover it, what about:

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

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Tue, 31 May 2016 16:09:19 -0400

On Tue, May 31, 2016 at 2:34 PM, Paul Kyzivat <[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.
>

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: Roman Shpount <[email-masked]>
Date: Tue, 31 May 2016 16:10:27 -0400

On Tue, May 31, 2016 at 2:44 PM, Christer Holmberg <
[email-masked]> wrote:

> asking. Since we make
> can simply say that
> 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.
_____________
Roman Shpount

---

From: Martin Thomson <[email-masked]>
Date: Wed, 1 Jun 2016 12:52:07 +1000

> 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.

Editorial: The last comma can be removed, or you could turn this into
a bullet list of exemptions.

---

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

Hi,

> Might as well be a MUST given the extensive list of caveats.

WFM.

> a bullet list of exemptions.

Will be fixed.

Regards,

Christer