Subject: [MMUSIC] draft-4572-update: New attribute [was: Draft new version: draft-ietf-mmusic-4572-update-01]

From: Christer Holmberg <[email-masked]>
Date: Sat, 14 May 2016 09:07:40 +0000

Hi,

I’ve put together a new version of the draft, which defines a new attribute, “fpl” (we can discuss the name later).

I have not submitted it to IETF yet, because I first want to make sure we agree on moving forward with a new attribute. However, it’s available on GitHub.

https://github.com/cdh4u/draft-4572-update   (NOTE: Individual repo)

NOTE the following:

-          The new attribute is not defined as an update to 4572.

-          4572 is updated to clarify that multiple SDP ‘fingerprints’ attributes are allowed, but each must be associated with a different certificate. If you want multiple hashes for a single certificate, you need the new attribute

-          Paul, I know I use the old syntax format – will be fixed later :)

Yes, there are things missing, but at this point I want comments on whether people think this is the correct approach. If so, I’ll submit the draft to IETF.

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Sun, 15 May 2016 01:33:28 +1000

> https://github.com/cdh4u/draft-4572-update   (NOTE: Individual repo)

Where are the matching rules for the new attribute?  Maybe it's my
jetlag, but I couldn't see them.  They are the most important part.

After seeing this, I think that this is worse than what I've been
proposing.  At least what I proposed was backward compatible, but now
you have no way of specifying multiple hash algorithms for
compatibility with a wide range of peers...unless they support this
spec, which they won't for ages.

The restriction to one a=fingerprint per certificate is an unnecessary
stipulation.  You have to be able to a) ignore fingerprints for
certificates that aren't used, and b) ignore certificates for hashes
that you don't know or support.

I offered this option without really thinking through the
consequences, but having now seen it manifest, I don't like it very
much.

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 14 May 2016 11:43:04 -0400

Some comments on the new draft:

The listed syntax for the new attribute:

   fingerprint-list =  "fpl" ":" hash-func SP fingerprint
                       *(":" hash-func SP fingerprint)

This isn't consistent with the example. I think you meant:

   fingerprint-list =  "fpl" ":" hash-func SP fingerprint
                       *(":" hash-func SP fingerprint)

Even then, I think I like Roman's proposed syntax better.

Later, in 4.2, is:

    If the offerer associates both 'fpl' attributes and 'fingerprint'
    attributes with the "m=" line in the offer, the fingerprint value
    included in any 'fingerprint' attribute MUST also be included in the
    'fpl' attribute associated with the same certificate.

Why is this MUST? Certainly it should be allowed. But it may be that the 
sender doesn't trust that hash. If not, why include it.

I think the key thing to note is that if that hash is to be considered 
when processing this attribute then it needs to be included. If it isn't 
included then it will only be used by recipients that don't support fpl.

Section 4.3:

    If the offer does not contain any 'fpl' attribute, the answerer
    SHOULD NOT associate any 'fpl' attribute with the corresponding "m="
    line in the answer.

Why not MUST NOT?

Then:

    If the offer contains one or more SDP 'fingerprint' attributes, the
    answerer follows the procedures in [RFC4572] for generating the
    answer.

I think this needs to be further qualified - this applies if 
'fingerprint' *is* present and 'fpl' *is not* present.

Then:

    If the answerer associates both 'fpl' attributes and 'fingerprint'
    attributes with the "m=" line in the answer, the fingerprint value
    included in any 'fingerprint' attribute MUST also be included in the
    'fpl' attribute associated with the same certificate.

I think if both are present in the offer, then 'fingerprint' should be 
ignored, and not included in the answer.

Update to 4572:

Why is the text change made? I thought this is now for backward 
compatibility only, so the restriction on the hash function used should 
remain. I think it should be dropped, keeping only the new text on 
multiple fingerprints.

	Thanks,
	Paul

On 5/14/16 5:07 AM, Christer Holmberg wrote:
> Hi,
>
>
>
> I’ve put together a new version of the draft, which defines a new
> attribute, “fpl” (we can discuss the name later).
>
>
>
> I have not submitted it to IETF yet, because I first want to make sure
> we agree on moving forward with a new attribute. However, it’s available
> on GitHub.
>
>
>
> -          4572 is updated to clarify that multiple SDP ‘fingerprints’
> attributes are allowed, but each must be associated with a different
> certificate. If you want multiple hashes for a single certificate, you
> need the new attribute
>
> Yes, there are things missing, but at this point I want comments on
> whether people think this is the correct approach. If so, I’ll submit
> the draft to IETF.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 14 May 2016 15:43:34 +0000

Hi,

> Where are the matching rules for the new attribute?  Maybe it's my jetlag, but I couldn't see them.  
> They are the most important part.

I am working on text, but the suggestions so far (unless I've missed/misunderstood something) has been that at least one (but not all) of the provided fingerprints must match certificate.

>After seeing this, I think that this is worse than what I've been proposing.  At least what I proposed >was backward compatible, but now you have no way of specifying multiple hash algorithms for >compatibility with a wide range of peers...unless they support this spec, which they won't for ages.
>
>The restriction to one a=fingerprint per certificate is an unnecessary stipulation.  You have to be able >to a) ignore fingerprints for certificates that aren't used, and b) ignore certificates for hashes that you >don't know or support.
>
>I offered this option without really thinking through the consequences, but having now seen it >manifest, I don't like it very much.

So, you don't like the new attribute, you don't like the one-fingerprint-per-certificate restriction on the existing 'fingerprint' attribute or you don't like any of it?

We could of course remove the restriction, but then I wonder how much sense the new attribute would make. Sure, it would allow endpoints to group the fingerprints with the associated fingerprint, but is that worth the effort? 

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Sun, 15 May 2016 01:48:46 +1000

What do you think the matching rule should be.  That's the crux of all
of this, all the shiny new syntax in the world won't help unless you
are sure what you want.

> We could of course remove the restriction, but then I wonder how much sense the new attribute would make. Sure, it would allow endpoints to group the fingerprints with the associated fingerprint, b…

Yes, now you are getting to the core of the issue.  The restriction
doesn't make sense because it's a restriction you can't enforce in any
meaningful way.  And once you accept that, the only problems we really
have to solve are:

 - whether we care about saying that a particular set of hashes belong
to the same certificate (me, I don't care)

 - whether we care about the weakest-link algorithm (me, I do care: we
are still shipping code with SHA-1)

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 14 May 2016 15:51:13 +0000

Hi,

>                       *(":" hash-func SP fingerprint)

I see no difference :)

But, I agree the example is not aligned with the syntax.

> Why is this MUST? Certainly it should be allowed. But it may be that the sender doesn't trust that hash. If not, why include it.

You want a MAY?

>    SHOULD NOT associate any 'fpl' attribute with the corresponding "m="

I can do that.

> I think this needs to be further qualified - this applies if 'fingerprint' *is* present and 'fpl' *is not* present.

Well, I was thinking that it should be allowed to include both attributes also in the answer. But, if we don't want that, I agree with you.

> I think if both are present in the offer, then 'fingerprint' should be ignored, and not included in the answer.

See above.

> Update to 4572:
>
> Why is the text change made? I thought this is now for backward compatibility only, so the restriction on the hash function 
> used should remain. I think it should be dropped, keeping only the new text on multiple fingerprints.

Are you talking about the restriction of using the same hash function for the fingerprint and the certificate signature?

Even if we'd remove that part, the text change still updates the preferred hash function, and clarifies the semantics of multiple 'fingerprint' attributes.

(When it comes to the preferred hash function etc, I'd like the new draft to reference 4572, so we don't have to re-write everything.)

Regards,

Christer

On 5/14/16 5:07 AM, Christer Holmberg wrote:
> we agree on moving forward with a new attribute. However, it’s 
> available on GitHub.
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 14 May 2016 16:03:20 +0000

Hi,

>What do you think the matching rule should be.  That's the crux of all of this, all the shiny new syntax in the world won't help unless you are sure what you want.

Personally, for a given certificate, I think it's enough if one of the provided fingerprint matches the certificate. But, if people think all fingerprints (that the receiver support) must match the certificate I will not argue against that.

>> We could of course remove the restriction, but then I wonder how much sense the new attribute would make. Sure, 
>> it would allow endpoints to group the fingerprints with the associated fingerprint, but is that worth the effort?
>
> Yes, now you are getting to the core of the issue.  The restriction doesn't make sense because it's a restriction you can't enforce 
> in any meaningful way.  And once you accept that, the only problems we really have to solve are:
>
> - whether we care about saying that a particular set of hashes belong to the same certificate (me, I don't care)
>
> - whether we care about the weakest-link algorithm (me, I do care: we are still shipping code with SHA-1)

So, eventhough you have probably said it many times already: what do you think the matching algorithm should be? When answering, please consider the RTP/RTCP use-case where multiple certificates may be used.

Regards,

Christer

---

From: Kevin Dempsey <[email-masked]>
Date: Sat, 14 May 2016 17:05:36 +0100

If an offer has two a=fingerprint lines with different hashes for a single
certificate, by only requiring one a=fingerprint line to match, an attacker
would only need to produce a certificate that matches the weakest hash to
be accepted.

The problem is that there is no way of knowing if two a=fingerprint lines
with different hashes are for the same certificate or different ones. The
new attribute makes it clear which fingerprints are derived from the same
certificate.

---

From: Martin Thomson <[email-masked]>
Date: Sat, 14 May 2016 09:09:31 -0700

> So, eventhough you have probably said it many times already: what do you think the matching algorithm should be? When answering, please consider the RTP/RTCP use-case where multiple certificates ma…

For each certificate:
 For each hash you support, there are three options:
   A fingerprint is present and matches: count these
   A fingerprint is present but there are no matches: ABORT AND FAIL
   No fingerprint is present
  If the count for a certificate is zero: ABORT AND FAIL

It's not difficult, but it allows for multiple certificates, multiple
hash algorithms, and it avoids the case where an attack can exploit
the presence of weak hashes.

---

From: Roman Shpount <[email-masked]>
Date: Sat, 14 May 2016 15:05:20 -0400

On Sat, May 14, 2016 at 12:09 PM, Martin Thomson <[email-masked]>
wrote:

> > So, eventhough you have probably said it many times already: what do you
> think the matching algorithm should be? When answering, please consider the
> RTP/RTCP use-case where multiple certificates may be used.
>
>
> For each certificate:

This match algorithm is also something that none of the current
implementation do right now and has a potential to fail in interesting and
hard to detect ways if different sets of hashes are present for different
certificates.

The main problem I have with your proposal is that a lot of current
implementations match one of multiple fingerprints right now. With the
matching algorithm that you propose, things which are working with current
implementations might stop working.

Also, as far as I know, most of the fingerprint matching implementations
are part of DTLS-SRTP and in some way related to WebRTC. They tend to be
updated quickly as can be shown by the change in required cipher suits
which recently occurred in Firefox and Chrome. So, I think, it would be
better to fix the current fingerprint attribute problems (matching multiple
hashes against the selected certificate, hex encoding for hash value,
non-extensibility of the attribute) at the same time and provide the
backwards compatible way to migrate. Old fingerprint attribute can then be
killed when new attribute is widely adopted.

Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 14 May 2016 15:59:11 -0400

> But, I agree the example is not aligned with the syntax.

Oops. s/":"/SP/

>> Why is this MUST? Certainly it should be allowed. But it may be that the sender doesn't trust that hash. If not, why include it.

That seems right.

> Are you talking about the restriction of using the same hash function for the fingerprint and the certificate signature?

Sorry, there were more changes in there than I realized. The part I was 
objecting to removing is the first part about using the same hash 
function as the certificate. That is fixed by the new attribute, but 
ought to remain for the old one for backward compatibility purposes.

Given that restriction, I don't understand the preferred part. (In 
either the old or updated text.) ISTM the only place this would apply is 
with self signed certificates. It would make more sense to put the 
recommendation in the last sentence on self signed certificates, which 
you removed.

	Thanks,
	Paul

---

From: Martin Thomson <[email-masked]>
Date: Sat, 14 May 2016 19:52:33 -0700

> implementations might stop working.

No, that's not a problem at all.  The existing implementations will
match on one fingerprint.  They might match on a weak hash, but that's
not a problem we can fix without pixie dust.

The advantage of this is that it is completely compatible with
existing implementations.  Unless you have an implementation that has
two different certificates for RTP and RTCP AND those have different
hash algorithms for their fingerprint.  Then a new implementation will
fail one or other component.  I consider that a very low risk failure
mode.