Subject: Re: [MMUSIC] Concern with status of draft-ietf-mmusic-4572-update

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 8 Sep 2016 01:12:06 +0000

Ok, I would like to request agenda time at the upcoming meeting to discuss this. I think the draft as it stands has a serious interoperability problem. Systems implementing 4572 after it is updated by this draft will not necessarily interoperate with systems that implemented 4572 before this updated it. 

Please point me at the extensive list discussions where this interoperability issue was discussed. 

> On Aug 25, 2016, at 9:52 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Define "extension". Does that mean we need a way to indicate support of that extension too?
> 
> Some people claimed that there are already implementations using multiple fingerprints, and one of the purposes of the draft is to clarify the rules and semantics of that, in order to give people a common understanding of the semantics of multiple fingerprints. 
> 
> And, things will still work even if some existing implementations only look at one of the fingerprints.
> 
> There were quite extensive list discussions, especially between Roman S and Martin T, in order to get everything right, so I REALLY think we should keep it as it is. Also, WGLC ended 19th June, and the WG that you are co-chairing have asked for this (among others) documents to be finalized :)
> 
> Regards,
> 
> Christer
> 
> 
> -----Original Message-----
> From: mmusic [mailto:[email-masked]] On Behalf Of Cullen Jennings (fluffy)
> Sent: 25 August 2016 18:22
> To: mmusic WG <[email-masked]>
> Subject: [MMUSIC] Concern with status of draft-ietf-mmusic-4572-update
> 
> 
> I do not think that draft-ietf-mmusic-4572-update can should be an "update" to 4572. RFC 4572 is widely deployed and the deployments are not going to be changed to incorporate this update. Having customers tell me equipment is not 4572 compliant because it does not implement this is not good. It will lead to interoperability problems where some people do this and others do not. For example, a 4572 is unlikely to include a SHA-256 fingerprint yet someone reading this update might make there systeme require the SHA-256 since this says it is a MUST. 
> 
> Instead I think this should be written as an extension to 4572 and JSEP and WebRTC should normatively reference it. 
> 
> For backwards compatibility, I think that  including SHA-1 as wells as SHA-256 should be a MUST
> 
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 7 Sep 2016 19:01:58 -0700

> Please point me at the extensive list discussions where this interoperability issue was discussed. 

[BA] I do not recall those discussions, but here is what I think the issue is.

For backward compatibility with RFC 4572, for each certificate, RFC 4572 Update implementations need to provide an a=fingerprint line computed using the digest algorithm used for the certificate signature. However, additional fingerprints per certificate can also be provided per RFC 4572 Update (though they will be ignored by RFC 4572 implementations).

The backward compatibility requirement exists because an RFC 4572 implementation will compute a single fingerprint from the remote cert, using the digest algorithm in the cert signature, and will attempt to match the computed value against the a=fingerprint lines.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 8 Sep 2016 06:41:07 +0000

Hi,

>Ok, I would like to request agenda time at the upcoming meeting to
>discuss this. I think the draft as it stands has a serious
>interoperability problem. Systems implementing 4572 after it is updated
>by this draft will not necessarily interoperate with systems that
>implemented 4572 before this updated it.

I think it would be REALLY good if you could point out the issues you see
BEFORE the meeting, so we can have some discussions on the list. There is
almost 2 months until the meeting, so I see no reason why we should have
to wait until then.

I am also happy to organise a phone call to discuss this. But, FIRST,
please explain your issue. Just saying ³it has serious interoperability
problem² doesn¹t help progressing the draft.

Regards,

Christer

>> Some people claimed that there are already implementations using
>>multiple fingerprints, and one of the purposes of the draft is to
>>clarify the rules and semantics of that, in order to give people a
>>common understanding of the semantics of multiple fingerprints.
>> 
>> There were quite extensive list discussions, especially between Roman S
>>and Martin T, in order to get everything right, so I REALLY think we
>>should keep it as it is. Also, WGLC ended 19th June, and the WG that you
>>are co-chairing have asked for this (among others) documents to be
>>finalized :)
>> 
>> Regards,
>> 
>> Christer
>> 
>> 
>> I do not think that draft-ietf-mmusic-4572-update can should be an
>>"update" to 4572. RFC 4572 is widely deployed and the deployments are
>>not going to be changed to incorporate this update. Having customers
>>tell me equipment is not 4572 compliant because it does not implement
>>this is not good. It will lead to interoperability problems where some
>>people do this and others do not. For example, a 4572 is unlikely to
>>include a SHA-256 fingerprint yet someone reading this update might make
>>there systeme require the SHA-256 since this says it is a MUST.
>> 
>> Instead I think this should be written as an extension to 4572 and JSEP
>>and WebRTC should normatively reference it.
>>

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 8 Sep 2016 09:40:20 -0400

I think that's a very fair request.

The document has completed WGLC and was about to be submitted for 
publication. Obviously, if there are issues, then we need to resolve 
those, but I don't see any reason why that can't progress on the mailing 
list at this point.

Also, as an FYI for everybody, we have had (and still have) an extensive 
discussion on the Working Group chairs list around what "Updates" 
actually means (see 
https://www.ietf.org/mail-archive/web/wgchairs/current/msg14618.html). 
While that thread hasn't completely ended at this point, it looks like 
there is convergence at least, and I believe we have a way forward to 
address that one, however I will let the author speak to that.

Thanks

-- Flemming (with chair hat on)

On 9/8/16 2:41 AM, Christer Holmberg wrote:
> .

---

From: Roman Shpount <[email-masked]>
Date: Thu, 8 Sep 2016 17:19:44 -0400

On Wed, Sep 7, 2016 at 10:01 PM, Bernard Aboba <[email-masked]>
wrote:

> discuss this. I think the draft as it stands has a serious interoperability
> problem. Systems implementing 4572 after it is updated by this draft will
> not necessarily interoperate with systems that implemented 4572 before this
> updated it.
> >
> For backward compatibility with RFC 4572, for each certificate, RFC 4572
> Update implementations need to provide an a=fingerprint line computed using
> the digest algorithm used for the certificate signature. However,
> additional fingerprints per certificate can also be provided per RFC 4572
> Update (though they will be ignored by RFC 4572 implementations).
>
> The backward compatibility requirement exists because an RFC 4572
> implementation will compute a single fingerprint from the remote cert,
> using the digest algorithm in the cert signature, and will attempt to match
> the computed value against the a=fingerprint lines.
>
>
Just to clarify this a bit more. RFC 4572 update does not actually provided
new functionality to RFC 4572. It clarified some of the ambiguity present
in RFC 4572 and relaxed the meaningless constraint that a=fingerprint line
computed using the digest algorithm used for the certificate signature. RFC
4572 does not specify that only a single a=fingerprint can be provided per
m= line. It specified that single a=fingerprint must be provided per
certificate due to the above restriction. Multiple certificates can be used
per m= line, for instance when different certificates are used for RTP and
RTCP flow and rtcp-mux is not used, or when different certificate is used
based on some other session negotiation parameters.

To see why original restriction that a=fingerprint line must be computed
using the digest algorithm used for the certificate signature is
meaningless you need to remember that RFC 4572 is primarily designed to
work with self signed certificates. You can generate multiple self-signed
certificates with the same data and sign them using multiple digest
algorithms and provide matching fingerprints in the offer. You can then
pick the certificate used during DTLS negotiation based on the digest
function in SDP answer.

Granted, there are existing RFC 4572 implementations that will not support
more then one fingerprint per m= line (Firefox), but these implementations
are not RFC 4572 compatible. The fact that they are also not compatible
with RFC 4572 update does not change anything.

Regards,
_____________
Roman Shpount

---

From: Martin Thomson <[email-masked]>
Date: Fri, 9 Sep 2016 11:46:45 +1000

> The backward compatibility requirement exists because an RFC 4572 implementation will compute a single fingerprint from the remote cert, using the digest algorithm in the cert signature, and will a…

If we don't at least recommend that the digest used in the signature
isn't in the set of hashes, then we should.  Otherwise, I don't see
much of a problem here (unless Cullen has something else...)

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Sun, 11 Sep 2016 16:43:27 +0000

> On Sep 7, 2016, at 8:01 PM, Bernard Aboba <[email-masked]> wrote:
> 

Yes, and to take this a bit further 4472 has the preferred hash as as SHA-1 but this moves it to SHA-256 which is good but needs more work to make it backwards comparable. 

Let say I have two implmnations called A which does class 4572 and B that the new  draft-ietf-mmusic-4572-update. So A uses sha-1 and B and sets up a TLS connection negotiated using certs with sha-1 signatures. Now B sends A a fingerprint using SHA-256 (which is preferred by this draft). Now A, the matching rules in 4572 computes the hash for the cert using sha-1 (cause that was what it was signed with) and at this point, the fingerprint and hash from the cert don't match and A tears down the connection. 

Mandating that B send the fingerprint used in the cert sig, as well as any additional fingerprints it wants to send such as SHA-256 would solve this.

---

From: Roman Shpount <[email-masked]>
Date: Sun, 11 Sep 2016 15:00:05 -0400

Cullen,

Am I correct that what you are proposing is that the digest function used
to sign the certificate MUST always be included as one of the fingerprints?
This is a minor editorial addition and I think it can be accommodated by
the draft. Since 4572 is mostly used with self-signed certificates, it
will, in practice mean that certificate should be signed with one of the
digest algorithms already used for fingerprints (SHA-256 seems like a good
option) and will not require any additional fingerprints.

Regards,

_____________
Roman Shpount

On Sun, Sep 11, 2016 at 12:43 PM, Cullen Jennings (fluffy) <[email-masked]

> Yes, and to take this a bit further 4472 has the preferred hash as as
> SHA-1 but this moves it to SHA-256 which is good but needs more work to
> make it backwards comparable.
>
> Let say I have two implmnations called A which does class 4572 and B that
> the new  draft-ietf-mmusic-4572-update. So A uses sha-1 and B and sets up a
> TLS connection negotiated using certs with sha-1 signatures. Now B sends A
> a fingerprint using SHA-256 (which is preferred by this draft). Now A, the
> matching rules in 4572 computes the hash for the cert using sha-1 (cause
> that was what it was signed with) and at this point, the fingerprint and
> hash from the cert don't match and A tears down the connection.
>
> Mandating that B send the fingerprint used in the cert sig, as well as any
> additional fingerprints it wants to send such as SHA-256 would solve this.
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 12 Sep 2016 06:07:18 +0000

Hi,

I have no problem with Roman’s suggestion, if that solves Cullen’s issue.

Regards,

Christer

From: Roman Shpount <[email-masked]<mailto:[email-masked]>>
Date: Sunday 11 September 2016 at 22:00
To: Cullen Jennings <[email-masked]<mailto:[email-masked]>>
Cc: Bernard Aboba <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MMUSIC] Concern with status of draft-ietf-mmusic-4572-update

Cullen,

Am I correct that what you are proposing is that the digest function used to sign the certificate MUST always be included as one of the fingerprints? This is a minor editorial addition and I think it can be accommodated by the draft. Since 4572 is mostly used with self-signed certificates, it will, in practice mean that certificate should be signed with one of the digest algorithms already used for fingerprints (SHA-256 seems like a good option) and will not require any additional fingerprints.

Regards,

_____________
Roman Shpount

On Sun, Sep 11, 2016 at 12:43 PM, Cullen Jennings (fluffy) <[email-masked]<mailto:[email-masked]>> wrote:

> On Sep 7, 2016, at 8:01 PM, Bernard Aboba <[email-masked]<mailto:[email-masked]>> wrote:
>
> On Sep 7, 2016, at 6:12 PM, Cullen Jennings (fluffy) <[email-masked]<mailto:[email-masked]>> wrote:
>>

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 15 Sep 2016 11:18:15 +0000

Cullen, are you ok with Roman’s suggestion?

Regards,

Christer

From: mmusic <[email-masked]<mailto:[email-masked]>> on behalf of Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Date: Monday 12 September 2016 at 09:07
To: Roman Shpount <[email-masked]<mailto:[email-masked]>>, Cullen Jennings <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MMUSIC] Concern with status of draft-ietf-mmusic-4572-update

Hi,

Regards,

Christer

Cullen,

Regards,

_____________
Roman Shpount

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 15 Sep 2016 20:55:34 +0000

Yah, that seems like a good suggestion

On Sep 15, 2016, at 4:18 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Regards,

Christer

Hi,

Regards,

Christer

Cullen,

Regards,

_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 15 Sep 2016 21:02:53 +0000

Thanks! :)

Regards,

Christer

From: Cullen Jennings (fluffy) [mailto:[email-masked]]
Sent: 15 September 2016 23:56
To: Christer Holmberg <[email-masked]>
Cc: mmusic WG <[email-masked]>
Subject: Re: [MMUSIC] Concern with status of draft-ietf-mmusic-4572-update

Cullen, are you ok with Roman's suggestion?

Regards,

Christer

Hi,

I have no problem with Roman's suggestion, if that solves Cullen's issue.

Regards,

Christer

Cullen,

Regards,

_____________
Roman Shpount