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

From: Christer Holmberg <[email-masked]>
Date: Fri, 6 May 2016 06:57:14 +0000

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 9 May 2016 09:55:21 +1000

Aside from a bunch of grammatical errors (below), my concern is that
this design ends up relying on the weakest mutually supported hash
function.  If SHA-1 is bad (hint: it is), but we have to support it, I
would prefer an algorithm that matched ALL mutually supported hashes.
That is, if a peer supports SHA-256 it either includes SHA-256 for
every certificate or checks that there is a match for SHA-256 if any
SHA-256 hash is present.

Detailed nits and comments:

s1p2

However,
   RFC 4572 is currently unclear on whether multiple 'fingerprint'
[attributes] can
   be associated

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.

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.

s6
<delete the 'p' please>

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.
>
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 9 May 2016 12:14:02 -0400

> every certificate or checks that there is a match for SHA-256 if any

This is complicated by the need to support fingerprints for multiple 
certificates, without any indication of which certificate a given 
fingerprint is intended to match.

IIUC you want it to work so that if there are only SHA-1 fingerprints 
then matching one of them is ok, but if there are any SHA-256 
fingerprints, and the receiver supports those, then there should be 
failure if none of the SHA-256 fingerprints match even if an SHA-1 
fingerprint does match.

I'm not sure how to write a matching rule that works that way, 
especially one that is clear.

What are existing implementations doing? Are there any that support 
multiple certificates?

	Thanks,
	Paul

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 9 May 2016 16:29:21 +0000

On May 6, 2016, at 2:57 AM, Christer Holmberg <[email-masked]<mailto:[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.

An editorial question — 4572 isn’t a very long document, so would it make more sense to structure this as a 4572bis than as updates to 4572?  I think it’d be clearer for implementors.  (Of course, it also means that all of 4572’s text goes through security review again; which has its good sides and its bad sides.)

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 9 May 2016 19:20:44 +0000

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 certificate.
>> 
> An editorial question — 4572 isn’t a very long document, so would it make more sense to structure this as a 
> 4572bis than as updates to 4572?  I think it’d be clearer for implementors.  (Of course, it also means that all 
> of 4572’s text goes through security review again; which has its good sides and its bad sides.)

Assuming we (read: the MMUSIC WG) wouldn't make any other change, the length of the document isn't that relevant. 

But, do you think such security review would cause lots of work?

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 May 2016 09:52:57 +1000

On 10 May 2016 at 02:14, Paul Kyzivat <[email-masked]> wrote:
> IIUC you want it to work so that if there are only SHA-1 fingerprints then
> matching one of them is ok, but if there are any SHA-256 fingerprints, and
> the receiver supports those, then there should be failure if none of the
> SHA-256 fingerprints match even if an SHA-1 fingerprint does match.
>
> I'm not sure how to write a matching rule that works that way, especially
> one that is clear.

How about this:

anyMatched := false
for (hashName : supportedHashes) {
  found := false
  match := false
  for (fingerprint : fingerprintAttributes) {
    if (fingerprint.hashName == hashName) {
      found = true
      match = fingerprint.value == hash(hashName, certificate)
    }
  }
  if (match) {
    anyMatched = true
  } else if (found) {
    throw 'no matches for ' + hashName
  }
}
if (!anyMatched) {
  throw 'no matches at all'
}

Or you can go with the more succinct version:

For every hash function that is both supported AND present, check that
there is at least one matching value.  If there are no matching
values, abort.

> What are existing implementations doing? Are there any that support

Firefox has done for a while (though it didn't for even longer due to
a bug).  I'm sure that's not much help though :)

---

From: Roman Shpount <[email-masked]>
Date: Mon, 9 May 2016 20:16:03 -0400

> a bug).  I'm sure that's not much help though :)
Does current Firefox implementation matches any one fingerprint or one
fingerprint per each hash algorithm?

Regards,
_____________
Roman Shpount

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 May 2016 10:17:35 +1000

> fingerprint per each hash algorithm?

Just one.

---

From: Roman Shpount <[email-masked]>
Date: Mon, 9 May 2016 20:35:42 -0400

> > fingerprint per each hash algorithm?

This is what I thought, but I was afraid I was missing something. I think
Chrome, Asterisk, and Freeswitch do the same.
_____________
Roman Shpount

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 May 2016 11:03:29 +1000

> Chrome, Asterisk, and Freeswitch do the same.

I think that this is OK.  My point with the multiple hashes thing is
that we have the opportunity to fix this without breaking backward
compatibility.

OLD:

implementations generate exactly one hash per certificate
implementations validate at most one hash

NEW:

implementations generate one hash per hash function per certificate
implementations validate one hash per hash function (if that function
is present)

If you draw up the possible combinations, everything works.

---

From: Roman Shpount <[email-masked]>
Date: Mon, 9 May 2016 22:25:52 -0400

> that we have the opportunity to fix this without breaking backward
I understand you are trying to fix something but you never explained what
was broken with the old way.
_____________
Roman Shpount

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 May 2016 12:44:49 +1000

> was broken with the old way.

See upthread, where I said "my concern is that this design ends up
relying on the weakest mutually supported hash function".

---

From: Roman Shpount <[email-masked]>
Date: Mon, 9 May 2016 23:24:54 -0400

> relying on the weakest mutually supported hash function".

I read this, but if SHA-1 is bad it should not be used (or trusted). You
make a PSA that your network will no longer accept SHA-1 past certain date
and ignore SHA-1 fingerprints from that date forward. Based on your
suggestion, you would still need to check SHA-1 past the date it was phased
out. So, my question is why SHA-1 + SHA-256 is better then SHA-256? Also,
if I trust SHA-256, why do I need to test SHA-512?

>From my experience it is better to always accept hash if you accept it
sometimes, or never accept it, if you don't.
_____________
Roman Shpount

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 May 2016 13:28:14 +1000

On 10 May 2016 at 13:24, Roman Shpount <[email-masked]> wrote:
> out. So, my question is why SHA-1 + SHA-256 is better then SHA-256? Also, if
> I trust SHA-256, why do I need to test SHA-512?

Flag days on the Internet don't work.  Unless you have complete
autocratic control over everyone you are talking to.  See how well
that worked for us when we disabled SHA-1 in certificates.  And we
concurrently supported SHA-256 there for ages.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 10 May 2016 07:23:52 +0000

Hi,

>If you draw up the possible combinations, everything works.

Again, if you provide hashes for multiple certificates, this assumes you
generate the same set of hashes for each certificate.

Assume you generate SHA-1 for cert1 and SHA-1 and SHA-256 for cert2.
During the DTLS handshake, cert1 is chosen. Now, the endpoint will try to
match the SHA-256 hash, and it will fail (as there is no reference to the
cert in the fingerprint).

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 10 May 2016 09:32:04 -0400

>   throw 'no matches at all'

I wasn't looking for code. (I understood how to do that.) My concern was 
for clear yet unambiguous text.

> there is at least one matching value.  If there are no matching

That is clear though incomplete. It at least needs to be qualified that 
it must be applied to each certificate.

But it does require that all supported hashes be tested against every 
certificate. While that isn't particularly expensive, it may be more 
than some want to do.

It could be adjusted, so that fingerprints were tested in descending 
order of strength, stopping when one succeeds. I wouldn't want to 
express doing that as a mandatory requirement, but it would be good if 
the requirements allowed such an approach to be conforming.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 10 May 2016 13:50:48 +0000

Hi,

...

>That is clear though incomplete. It at least needs to be qualified that it must be applied to each certificate.
>
>But it does require that all supported hashes be tested against every certificate. While that isn't particularly expensive, it may be more than some want to do.

Question 1: How often will we end up using multiple certificates to begin with? We have the RTP-and-RTCP-on-different-servers use-case, which I assume will never be used on TLS/DTLS connections between two user endpoints, and not on all endpoint-to-server connections either.

Question 2: How many fingerprints, per certificate, will endpoints provide? My guess is 1-2 (one for backward compatibility, and one new 'n fancy).

So, in reality it may  not be so expensive. 

Whether it provides more security by matching all hashes is a separate issue.

>It could be adjusted, so that fingerprints were tested in descending order of strength, stopping when one succeeds. 
>I wouldn't want to express doing that as a mandatory requirement, but it would be good if the requirements allowed 
>such an approach to be conforming.

Currently the draft says that an endpoint shall test a "secure enough" hash. That doesn't mean it shall be the strongest, but it doesn't forbid using the strongest.

But, if we want to say something regarding order of strength, I guess that order would have to be an implementation issue? 

Regards,

Christer

	Thanks,
	Paul

---

From: Martin Thomson <[email-masked]>
Date: Wed, 11 May 2016 10:02:16 +1000

> must be applied to each certificate.

There is only one certificate that you need to test [1].  The one that
your peer offered.

[1].  ... per media section.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 11 May 2016 10:04:23 +1000

> But, if we want to say something regarding order of strength, I guess that order would have to be an implementation issue?

That would only work if you required that if the strongest is present,
then it has to match.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 10 May 2016 22:14:22 -0400

> [1].  ... per media section.

For RTP and SRTP on separate ports there will be two certificates.

	Thanks,
	Paul

---

From: Martin Thomson <[email-masked]>
Date: Wed, 11 May 2016 13:58:24 +1000

> For RTP and SRTP on separate ports there will be two certificates.

You mean RTP and RTCP, yes. that too.  A reasonable implementation
will use the same certificate most times, so the checking can use a
shortcut.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 11 May 2016 06:32:45 +0000

Hi,

...

> will use the same certificate most times, so the checking can use a

But, if we still want to allow multiple certificates, the procedures need
to support that.

So, do we require the same set of hash functions to be provide for each
certificate? If not, we cannot mandate that each hash function must match
each certificate.

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Wed, 11 May 2016 19:20:11 +1000

> certificate? If not, we cannot mandate that each hash function must match

Without a way to identify which fingerprint goes with which (and that
fails if a=fingerprint is at the session level), we are reduced to the
same rules for every certificate: either match just one, or (as I have
been advocating) match one for every hash function you care about.

Note that you could decide that you don't care about a weaker hash
function if a strong one matches.  That reduces the number of checks.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 11 May 2016 10:00:10 +0000

Hi,

>fails if a=fingerprint is at the session level),

Even if it¹s on the media level, as RTP and RTCP use the same m- line.

>we are reduced to the

Isn¹t that what the current text more or less says:

"An endpoint MUST be able to match at least one of the received
     fingerprints, calculated using a hash algorithm that the endpoint
     considers secure enough,²

I could change ³at least one² to ³one or more² if you think that would be
more clear.

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Wed, 11 May 2016 20:53:01 +1000

> I could change ³at least one² to ³one or more² if you think that would be

No, that implies that if it considers SHA-1 is good enough to talk to
Paul, then it should be OK with using that with Christer, even if
Christer has SHA-256.

I would not put text to the effect of what I said above in the draft.
Simply say that all hashes that it supports need to match.  It's too
hard to explain that you can give up after hash A, but not after hash
B.

I'm wondering if all this is worry about the cost of hashing the
certificate a few times.  That's so little work that we no longer
worry about it in the crypto world.  Take a look at the current TLS
1.3 handshake and work out how many times we run a hash function.
It's well into double digits.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 11 May 2016 11:17:55 +0000

Hi,

>hard to explain that you can give up after hash A, but not after hash

Again, if you receive hash function SHA-XXX only for the RTP certificate,
but not for the RTCP certificate, it will fail, because the receiver will
not be able to match any SHA-XXX hash with the RTCP certificate.

The only way to prevent that is by mandating the same set of hash
functions for each certificate - which people have claimed may not be
possible if RTP and RTCP are provide by different entities.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 11 May 2016 09:51:13 -0400

>      considers secure enough,²

The part we are not talking about here is what the sender must do. With 
the sort of algorithm Martin is talking about, if the intent is to cover 
multiple certificates then every hash function used must be used for 
every certificate. Whether that is a burden is debatable. If the 
matching algorithm requires that, then it must be a stated requirement 
on the sender.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 11 May 2016 14:06:08 +0000

Hi,

...
>every certificate.

Correct.

>Whether that is a burden is debatable. If the

Correct.

The question is whether such requirement would be harmful to the
RTP-and-RTCP-on-different-servers use-case.

Regards,

Christer

---

From: Kevin Dempsey <[email-masked]>
Date: Thu, 12 May 2016 09:19:14 +0100

An alternative would be to provide some way to associate the fingerprints
of each certificate with each other. For example, replace multiple
a=fingerprint attributes with something like:
a=fingerprints: hash1 AAAA, hash2 BBBBBBBB, hash3 CCCCCCCCCCCC
Then the requirement on the receiving side would be that the certificate
must match at least one 'fingerprints' line. Which, and how many, of the
hashes that are checked would depend on the receivers preferences.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 12 May 2016 08:57:51 +0000

Hi,

>An alternative would be to provide some way to associate the fingerprints of each certificate with each other. For example, replace multiple a=fingerprint attributes with something like:
>Then the requirement on the receiving side would be that the certificate must match at least one 'fingerprints' line. Which, and how many, of the hashes that are checked would depend on the receivers preferences.

Correct.

However, as that solution would not be backward compatible, the question is whether existing deployments today support multiple certificates. If not, then this could be an option.

In cases where only a single certificate is offered, we could continue using the existing fingerprint attribute.

Regards,

Christer

On 11 May 2016 at 15:06, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

...

Correct.

Correct.

Regards,

Christer

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

---

From: Kevin Dempsey <[email-masked]>
Date: Thu, 12 May 2016 10:18:37 +0100

For backwards compatibility you could still use the a=fingerprint attribute
as well. If there are a=fingerprints and you understand them, then you'd
ignore a=fingerprint lines.

On 12 May 2016 at 09:57, Christer Holmberg <[email-masked]>
wrote:

> However, as that solution would not be backward compatible, the question
> is whether existing deployments today support multiple certificates. If
> not, then this could be an option.
>
> In cases where only a single certificate is offered, we could continue
> using the existing fingerprint attribute.
>
> Regards,
>
> Christer
>
>
>
>
> On 11 May 2016 at 15:06, Christer Holmberg <[email-masked]
> > wrote:
>
>> Hi,
>>
>> ...
>> >>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 12 May 2016 09:21:13 +0000

Hi,

>For backwards compatibility you could still use the a=fingerprint attribute as well. If there are a=fingerprints and you understand them, then you'd ignore a=fingerprint lines.

Sure. But, as the sender doesn’t know whether the receiver will support the new attribute, we’d still need rules associated with the usage of the existing fingerprint.

Regards,

Christer

On 12 May 2016 at 09:57, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Correct.

Regards,

Christer

...

Correct.

Correct.

Regards,

Christer

---

From: Kevin Dempsey <[email-masked]>
Date: Thu, 12 May 2016 10:44:30 +0100

The existing fingerprint attribute would keep the original requirement of
using the same hash as the certificate. So there would be only one
fingerprint line per certificate.

For hash agility, you'd use the new attribute. I think that makes it much
simpler.

On 12 May 2016 at 10:21, Christer Holmberg <[email-masked]>
wrote:

> Hi,
>
> >For backwards compatibility you could still use the a=fingerprint
> attribute as well. If there are a=fingerprints and you understand them,
> then you'd ignore a=fingerprint lines.
>
> Sure. But, as the sender doesn’t know whether the receiver will support
> the new attribute, we’d still need rules associated with the usage of the
> existing fingerprint.
>
> Regards,
>
> Christer
>
>
> On 12 May 2016 at 09:57, Christer Holmberg <[email-masked]
> > wrote:
>
>> Hi,
>>
>> >An alternative would be to provide some way to associate the
>> fingerprints of each certificate with each other. For example, replace
>> multiple a=fingerprint attributes with something like:
>> On 11 May 2016 at 15:06, Christer Holmberg <
>> [email-masked]> wrote:
>>
>>> Hi,
>>>
>>> ...
>>> >>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 12 May 2016 20:25:15 +1000

> For hash agility, you'd use the new attribute. I think that makes it much

We could fix the stupid syntax at the same time.  Backwards
compatibility is for the weak:

a=fp:<name>=<base64url-value>;<name>=<base64>

Each line is a single certificate with as many hash functions as you please.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 12 May 2016 11:24:17 +0000

Hi,

Within the attribute, what value would you use to reference the
certificate?

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 12 May 2016 15:01:02 +0000

Hi,

One thing to remember, if we define a new attribute, and clarify that only one instance of the existing fingerprint attribute is allowed, is that it may have impact on other specifications.

At least rtcweb-security-overview talks about usage of multiple fingerprint attributes. So, that text should be modified and talk about multiple new-fingerprint attributes.

Regards,

Christer

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: 12 May 2016 13:25
To: Kevin Dempsey <[email-masked]>
Cc: Christer Holmberg <[email-masked]>; Paul Kyzivat <[email-masked]>; [email-masked]
Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-4572-update-01

On 12 May 2016 at 19:44, Kevin Dempsey <[email-masked]> wrote:
> For hash agility, you'd use the new attribute. I think that makes it 
> much simpler.

We could fix the stupid syntax at the same time.  Backwards compatibility is for the weak:

---

From: Roman Shpount <[email-masked]>
Date: Thu, 12 May 2016 19:56:17 -0400

Hi All,

Well, we can define new attribute as set of name value pairs, and define
specific names for currently supported hashes, such as "a=fp:
sha1=base64val;sha256=base64val". New names can be added in the future to
extend the attribute and add new hash function support or other extensions.

Single attribute will refer to the single certificate, so all hashes in an
attribute must match the currently used certificate for the new attribute
to match.

New attribute can be used in parallel with old fingerprint attribute for
backwards compatibility. Matching fingerprint attribute will follow
existing rules (any one match of currently used certificate is sufficient).
New implementations MUST provide a new style attributes for each
certificate used and MAY provide old style fingerprint attributes for
backwards compatibility. If new attribute is present, new implementations
MUST only match new attributes and ignore the old fingerprint attribute.
They MAY match old fingerprint attributes if new attributes are not present.

I think this will give us the best of both worlds, backwards compatibility
and security. Since only things that I know off that currently implement
fingerprint attribute are WebRTC implementations, we can expect old
fingerprint attributes to be retired within a reasonable time.

One unrelated editor note would be that I would prefer the new draft to
overwrite RFC 4572 instead of updating a portion of it. I would also like
to rename it since the new draft covers not only connection oriented media
(TLS) but also DTLS.

Regards,

_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Thu, 12 May 2016 20:00:30 -0400

On Thu, May 12, 2016 at 5:44 AM, Kevin Dempsey <[email-masked]>
wrote:

> I do not think any implementation is actually following the original
requirement of using the same hash as the certificate. This particular
requirement was simply misguided since there is not a single reason why
self signing hash algorithm should have any impact on the SDP fingerprint
attribute. The procedure to sign the certificate is completely different
from calculating certificate hash.
______________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 12 May 2016 21:28:50 -0400

On 5/12/16 7:56 PM, Roman Shpount wrote:
> sha1=base64val;sha256=base64val". New names can be added in the future
> to extend the attribute and add new hash function support or other
> extensions.
>
> Single attribute will refer to the single certificate, so all hashes in
> an attribute must match the currently used certificate for the new
> attribute to match.
>
> existing rules (any one match of currently used certificate is
> sufficient). New implementations MUST provide a new style attributes for
> each certificate used and MAY provide old style fingerprint attributes
> for backwards compatibility. If new attribute is present, new
> implementations MUST only match new attributes and ignore the old
> fingerprint attribute. They MAY match old fingerprint attributes if new
> attributes are not present.
>
> I think this will give us the best of both worlds, backwards
> compatibility and security. Since only things that I know off that
> currently implement fingerprint attribute are WebRTC implementations, we
> can expect old fingerprint attributes to be retired within a reasonable
> time.

Make sure to define O/A rules so that the offerer *knows* if the new 
attribute was understood.

Also, should the fingerprint in a=fingerprint be repeated in the new 
attribute? Or should the new attribute just be used for additional 
fingerprints?

	Thanks,
	Paul

> overwrite RFC 4572 instead of updating a portion of it. I would also
> like to rename it since the new draft covers not only connection
> oriented media (TLS) but also DTLS.
>
> Regards,
>
> _____________
> Roman Shpount
>
> On Thu, May 12, 2016 at 6:25 AM, Martin Thomson
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     On 12 May 2016 at 19:44, Kevin Dempsey <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     [email-masked] <mailto:[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 13 May 2016 13:35:55 +0000

Hi,

>Well, we can define new attribute as set of name value pairs, and define specific names for currently supported
>hashes, such as "a=fp: sha1=base64val;sha256=base64val". New names can be added in the future to extend the
>attribute and add new hash function support or other extensions.

I think we can use the same values that are used for the current fingerprint attribute.

hash-func              =  "sha-1" / "sha-224" / "sha-256" /
                          "sha-384" / "sha-512" /
                          "md5" / "md2" / token
                          ; Additional hash functions can only come
                          ; from updates to RFC 3279

>Single attribute will refer to the single certificate, so all hashes in an attribute must match the currently used certificate for the new attribute to match.

How do we associate an attribute with a certificate, so that the receiver can match the attribute (and the hashes) with the associated certificate?

>New attribute can be used in parallel with old fingerprint attribute for backwards compatibility. Matching fingerprint attribute will follow existing rules (any one match of currently used >certificate is sufficient). New implementations MUST provide a new style attributes for each certificate used and MAY provide old style fingerprint attributes for backwards compatibility. >If new attribute is present, new implementations MUST only match new attributes and ignore the old fingerprint attribute. They MAY match old fingerprint attributes if new attributes are >not present.

I think there are still different opinions on whether one match is enough, or whether all supported hashes should be tested.

I think this will give us the best of both worlds, backwards compatibility and security. Since only things that I know off that currently implement fingerprint attribute are WebRTC implementations, we can expect old fingerprint attributes to be retired within a reasonable time.

>One unrelated editor note would be that I would prefer the new draft to overwrite RFC 4572 instead of updating a portion of it. I would also
>like to rename it since the new draft covers not only connection oriented media (TLS) but also DTLS.

Note that very little of the existing 4572 text would be modified. We would only clarify the restrictions associated with the fingerprint attribute.

Anyway, my suggestion is to get the mechanism correct first, and then we see what’s the best way of documenting everything.

Regards,

Christer

---

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

Hi,

>> Well, we can define new attribute as set of name value pairs, and 
>> define specific names for currently supported hashes, such as "a=fp:
>> Single attribute will refer to the single certificate, so all hashes 
>> in an attribute must match the currently used certificate for the new 
>> attribute to match.
>>
>> New attribute can be used in parallel with old fingerprint attribute 
>> for backwards compatibility. Matching fingerprint attribute will 
>> follow existing rules (any one match of currently used certificate is 
>> sufficient). New implementations MUST provide a new style attributes 
>> for each certificate used and MAY provide old style fingerprint 
>> attributes for backwards compatibility. If new attribute is present, 
>> new implementations MUST only match new attributes and ignore the old 
>> fingerprint attribute. They MAY match old fingerprint attributes if 
>> new attributes are not present.
>>
>> currently implement fingerprint attribute are WebRTC implementations, 
>> we can expect old fingerprint attributes to be retired within a 
>> reasonable time.
>
> Make sure to define O/A rules so that the offerer *knows* if the new attribute was understood.

If the answerer supports the attribute, it MUST include it in the answer.

>Also, should the fingerprint in a=fingerprint be repeated in the new attribute? Or should the new attribute just be used for additional fingerprints?

I see no reason to not allow a hash to be included in both attributes.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 13 May 2016 10:55:40 -0400

> If the answerer supports the attribute, it MUST include it in the answer.

That is what I was thinking.

What about the case where the answerer is the one that will be sending 
the certificate, and hence needs to send the fingerprints? That might 
not be common, but it might be possible.

> I see no reason to not allow a hash to be included in both attributes.

Nor do I. But it is worth considering how best to migrate. If you need 
to include a=fingerprint anyway, for backward compatibility, then it 
might make sense to simply use the new attribute for *additional* 
fingerprints.

I don't feel strongly about this. But it is good to be clear what the 
expectation is. If both attributes are present, and the fingerprint in 
a=fingerprint is *not* present in the new attribute, must it still match 
to *some* certificate?

	Thanks,
	Paul

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Fri, 13 May 2016 14:04:44 -0400

On Fri, May 13, 2016 at 9:35 AM, Christer Holmberg <
[email-masked]> wrote:

> specific names for currently supported
>

The difference that current fingerprint attribute contains one hash value.
New attribute would be able to contain multiple hash values for a single
certificate. It can also be extended to provide other attributes for the
certificate, such as certificate common name, for which we can define new
matching rules. For instance in order to match the new attribute,
certificate must match all the hash values and the specified common name.

> How do we associate an attribute with a certificate, so that the receiver
> can match the attribute (and the hashes) with the associated certificate?
>

We do not associate the new attribute with the certificate. All new
attribute does is specifies that all hashes within the single attribute
refer to the single certificate and should match at the same for the
specific certificate to match this attribute.

> existing rules (any one match of currently used >certificate is
> each certificate used and MAY provide old style fingerprint attributes for
> backwards compatibility. >If new attribute is present, new implementations
> They MAY match old fingerprint attributes if new attributes are >not
> present.
>
>
>
> I think there are still different opinions on whether one match is enough,
> or whether all supported hashes should be tested.
>

If you want more secure match, you would need to use the new attribute. If
you use existing attribute you will use the match algorithm in existing
implementations, which currently allow a single fingerprint match. I have
mentioned earlier that Chrome, Firefox, Asterisk and Freeswitch currently
are looking for a single match. The algorithm that Martin proposed has, as
far as I know, no existing implementations.

> Note that very little of the existing 4572 text would be modified. We
> would only clarify the restrictions associated with the fingerprint
> attribute.
>
>
>
4572 is a very small document. It mostly talks about fingerprints.

If we define the new attribute then it should definitely be a new document.

_____________
Roman Shpount

---

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

> That is what I was thinking.

Agreed. This is what I was thinking as well.

> What about the case where the answerer is the one that will be sending the
> certificate, and hence needs to send the fingerprints? That might not be
> common, but it might be possible.
>

I am not sure what you mean. Both sides send their certificate when
connection is established, so both sides must send fingerprints.

> Nor do I. But it is worth considering how best to migrate. If you need to
> include a=fingerprint anyway, for backward compatibility, then it might
> make sense to simply use the new attribute for *additional* fingerprints.
>

If we use new attribute for additional fingerprints we will need to figure
out which a=fingerprint attribute contains the "primary". If everything is
in one attribute, a=fingerprint attributes can be simply ignored if new
attributes are present.

> a=fingerprint is *not* present in the new attribute, must it still match to
> *some* certificate?

What I proposed was that if new attributes are present in the offer and
implementation supports new attribute, one new attribute must match the
certificate and a=fingerprint attributes must be ignored. Answer must
contain only new attributes. If new attributes are not present in the
offer, this will mean that the offer came from the legacy implementation,
or if new attribute is not supported, one a=fingerprint attribute must
match the certificate. New attributes must not be present in the answer and
answer should contain a=fingerprint attributes.

Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 13 May 2016 16:43:51 -0400

On 5/13/16 2:12 PM, Roman Shpount wrote:
> On Fri, May 13, 2016 at 10:55 AM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     What about the case where the answerer is the one that will be
>     sending the certificate, and hence needs to send the fingerprints?
>     That might not be common, but it might be possible.
>
>

Oh, ok.

>             Also, should the fingerprint in a=fingerprint be repeated in
>             the new attribute? Or should the new attribute just be used
>             for additional fingerprints?
>
>
>     Nor do I. But it is worth considering how best to migrate. If you
>     need to include a=fingerprint anyway, for backward compatibility,
>     then it might make sense to simply use the new attribute for
>     *additional* fingerprints.
>
>
> If we use new attribute for additional fingerprints we will need to
> figure out which a=fingerprint attribute contains the "primary". If
> everything is in one attribute, a=fingerprint attributes can be simply
> ignored if new attributes are present.

That can work. We just need to be clear about it.

>     I don't feel strongly about this. But it is good to be clear what
>     the expectation is. If both attributes are present, and the
>     fingerprint in a=fingerprint is *not* present in the new attribute,
>     must it still match to *some* certificate?
>
>
> offer, this will mean that the offer came from the legacy
> implementation, or if new attribute is not supported, one a=fingerprint
> attribute must match the certificate. New attributes must not be present
> in the answer and answer should contain a=fingerprint attributes.

That language seems to work.

	Thanks,
	Paul

---

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

Hi,

>The difference that current fingerprint attribute contains one hash value. New attribute would be able to contain multiple hash values for a single certificate.

Yes, but I was only talking about the value of the hash function. 

>It can also be extended to provide other attributes for the certificate, such as certificate common name, for which we
>can define new matching rules. For instance in order to match the new attribute, certificate must match all the hash values 
>and the specified common name.

We can for sure allow for extendibility, but such extensions are outside the scope of the current work IMO.

> We do not associate the new attribute with the certificate. All new attribute does is specifies that all hashes within the 
> single attribute refer to the single certificate and should match at the same for the specific certificate to match this attribute.

Yes. But, my idea was to indicate in the attribute with which certificate the attribute hash(es) are associated with, so that the receiver does not need to check the hashes within all attributes.

Example:

a=fp:certX;sha-1:<hash>;sha-256:<hash>
a=fp:certY:sha-1:<hash>;sha-256:<hash>

In this case, if certX ends up being selected, the endpoint knows which hashes it should check, and does not need to try the others in order to find the match.

>>> New attribute can be used in parallel with old fingerprint attribute for backwards compatibility. Matching fingerprint attribute will follow 
>>> existing rules (any one match of currently used certificate is sufficient). New implementations MUST provide a new style attributes for 
>>> each certificate used and MAY provide old style fingerprint attributes for backwards compatibility. If new attribute is present, new 
>>> implementations MUST only match new attributes and ignore the old fingerprint attribute. They MAY match old fingerprint attributes if 
> If you want more secure match, you would need to use the new attribute. If you use existing attribute you will use the match 
> algorithm in existing implementations, which currently allow a single fingerprint match. I have mentioned earlier that 
> Chrome, Firefox, Asterisk and Freeswitch currently are looking for a single match. The algorithm that Martin proposed 
> has, as far as I know, no existing implementations.

My point was: if the new attribute is used, do we require all hashes within the attribute to match, or is it enough if the receiver checks one of the hashes within the attribute.

Example:

a=fp:certX;sha-1:<hash>;sha-256:<hash>

If certX is selected, is the receiver required to check both the sha-1 and sha-256 hashes?

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Sat, 14 May 2016 04:23:54 -0400

On Sat, May 14, 2016 at 3:38 AM, Christer Holmberg <
[email-masked]> wrote:

> >It can also be extended to provide other attributes for the certificate,
> such as certificate common name, for which we
> >can define new matching rules. For instance in order to match the new
> attribute, certificate must match all the hash values

Agreed. All I am saying we have a framework to extend in the future if
needed.

> >> How do we associate an attribute with a certificate, so that the
> receiver can match the attribute (and the hashes) with the associated
> certificate?
> >
> attribute does is specifies that all hashes within the
> > single attribute refer to the single certificate and should match at the
> same for the specific certificate to match this attribute.
>
> Yes. But, my idea was to indicate in the attribute with which certificate
> the attribute hash(es) are associated with, so that the receiver does not
> need to check the hashes within all attributes.
>
> Example:
>
> In this case, if certX ends up being selected, the endpoint knows which
> hashes it should check, and does not need to try the others in order to
> find the match.
>

What are certX and certY values? What do you use to identify the
certificate? Common Name? Something else? Whatever it is, it can be just
one more named parameter.

What I expected was that hash value itself is the certificate identifier.
There are various ways to optimize the match process, if you cash the
calculated hash values for the certificate, so I do not think it will use a
lot of resources.

Also, I would prefer if we keep the format
"a=fp:sha-1=<base64hash>;sha-256=<base64hash>". This is the standard URL
parameter format so it would require one less parser to support.

> for backwards compatibility. Matching fingerprint attribute will follow
> >> I think there are still different opinions on whether one match is
> enough, or whether all supported hashes should be tested.
> >
> > If you want more secure match, you would need to use the new attribute.
> If you use existing attribute you will use the match
> > algorithm in existing implementations, which currently allow a single
> fingerprint match. I have mentioned earlier that
> > Chrome, Firefox, Asterisk and Freeswitch currently are looking for a
> single match. The algorithm that Martin proposed
> My point was: if the new attribute is used, do we require all hashes
> within the attribute to match, or is it enough if the receiver checks one
> of the hashes within the attribute.
>
> Example:
>

Checking all hashes would be more secure, so I would make it a "SHOULD".
Implementations can decide to check the subset of all the hashes if they
decided it provides sufficient security, as in checking the most secure
hash only.

Regards,
______________
Roman Shpount

---

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

Hi,

…

> What are certX and certY values? What do you use to identify the certificate? Common Name? Something else?

That is exactly the question I have been asking :)

When people have been talking about this new attribute, I have been asking whether the attribute should contain *A* reference to the associated certificate, and if so, what should that value be (Common Name etc)?

> Also, I would prefer if we keep the format "a=fp:sha-1=<base64hash>;sha-256=<base64hash>". This is the standard URL parameter format so it would require one less parser to support.

Note that RFC 4572 does not use "=" between the hash function name and the value, is uses space (SP). Now, that doesn't mean we can't use "=" for the new attribute, but just to keep in mind :)

	a=fingerprint:SHA-1 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB

...

> Checking all hashes would be more secure, so I would make it a "SHOULD". Implementations can decide to check the subset of all the hashes if they decided 
> it provides sufficient security, as in checking the most secure hash only.

Works for me.

Regards,

Christer

---

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

On Sat, May 14, 2016 at 5:00 AM, Christer Holmberg <
[email-masked]> wrote:

> certificate? Common Name? Something else?
>
> When people have been talking about this new attribute, I have been asking
> whether the attribute should contain *A* reference to the associated
> certificate, and if so, what should that value be (Common Name etc)?
>

If anybody wants to add some new way to identify the certificate in
addition to hash, they can propose a new name value pair for this purpose.
The proposed format can already accommodate this.

This being said, I do not think it is necessary to provide certificate ID
in the new attribute. Right now there is no requirement for the common name
to be unique for the certificates. Most implementations simply put server
IP in common name for self signed certificates, so common name is not
unique. I do not think we need to invent a new unique certificate ID when
hash value is already sufficiently unique for this purpose. I think the
problem with the old fingerprint attribute was that it was unclear which
fingerprints referred to the same certificate.  It is solved with the new
attribute by putting all the related fingerprints in the same attribute.
Unless someone thinks of the problem which is needed to be solved by the
certificate id, hash values alone should be enough.

> Note that RFC 4572 does not use "=" between the hash function name and the
> value, is uses space (SP). Now, that doesn't mean we can't use "=" for the
> new attribute, but just to keep in mind :)
>
>         a=fingerprint:SHA-1
> 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
>

I am also suggesting to use base64 encoding for hash value instead of hex.
Makes the whole thing a bit shorter.

Regards,
_____________
Roman Shpount

---

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

Hi,

>> When people have been talking about this new attribute, I have been asking whether the attribute should 
>> contain *A* reference to the associated certificate, and if so, what should that value be (Common Name etc)?
>
> If anybody wants to add some new way to identify the certificate in addition to hash, they can propose a new name value pair for this purpose. The proposed format can already accommodate this.

If people don't think it's needed now, fine - I merely wanted to clarify whether people were assuming we'd have some kind of reference.

...

> I am also suggesting to use base64 encoding for hash value instead of hex. Makes the whole thing a bit shorter.

Works for me.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 14 May 2016 10:42:05 -0400

> My point was: if the new attribute is used, do we require all hashes within the attribute to match, or is it enough if the receiver checks one of the hashes within the attribute.

ISTM that this should be entirely up to the receiver. It should be 
allowed to check them all, and fail if they don't all match. That means 
the sender must ensure that all those sent are valid. But the receiver 
MAY only check one or a few that it trusts. Probably a receiver SHOULD 
check at least the strongest one it understands.

In the extreme, a very trusting receiver might not check any, thought 
that certainly should not be recommended.

	Thanks,
	Paul

---

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

On 14 May 2016 at 07:42, Paul Kyzivat <[email-masked]> wrote:
> ISTM that this should be entirely up to the receiver. It should be allowed
> to check them all, and fail if they don't all match. That means the sender
> must ensure that all those sent are valid. But the receiver MAY only check
> one or a few that it trusts. Probably a receiver SHOULD check at least the
> strongest one it understands.

This is right, though I would add that if that strongest one is
present in any way, but NOT matched, then it MUST fail the match.

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 14 May 2016 16:18:48 -0400

> present in any way, but NOT matched, then it MUST fail the match.

The failure of *any* checked fingerprint to match must cause the 
connection to fail.

If you don't check them all, you are implicitly assuming that the 
unchecked ones match.

When a cert is received on a potential connection the general matching 
algorithm could be:

1) first, discover which fpl attribute applies to this certificate:

For each fpl attribute, pick one of the hashes and test it against the 
certificate. If it matches, then this is the right fpl attribute.

2) Do further verification:

Optionally check other hashes from this fpl attribute against the 
certificate.

The connection must fail if (1) finds no matching fpl, or if any check 
from (2) fails.

One could save a bit of work in step 1 by choosing a hash function that 
is common across all the fpl attributes. Then it only needs to be 
computed once.

Or one could, for each fpl attribute, choose the strongest hash you 
support for step 1. Then you could skip step 2.

But these are implementation strategies, and shouldn't be normative.

	Thanks,
	Paul

---

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

On 14 May 2016 at 13:18, Paul Kyzivat <[email-masked]> wrote:
> The failure of *any* checked fingerprint to match must cause the connection
> to fail.

OK, yes, unless you find another line that matches on every hash, sure.

I agree with the rest, though a=fpl doesn't really address the
backwards compatibility concerns that well.

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 15 May 2016 19:27:20 +0000

Hi,

> I agree with the rest, though a=fpl doesn't really address the backwards compatibility concerns that well.

My intention was not to break backwards compatibility.

Another way would be to say that every 'fingerprint' attribute carries a fingerprint for the SAME certificate. But, that would of course not work with existing(?) implementations that use 'fingerprint' to provide fingerprints associated with different certificates...

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 16 May 2016 16:48:04 +0000

Hi,

I put a new version on GitHub:

https://github.com/cdh4u/draft-4572-update

The main difference is that it now updates 4572 by saying that multiple fingerprint attributes are associated with the SAME certificate, and in order to provide fingerprints for multiple certificates the new attribute is needed. I think that should solve Martin's backwards compatibility issue.

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 15 May 2016 22:27
To: Martin Thomson <[email-masked]>; Paul Kyzivat <[email-masked]>
Cc: [email-masked]
Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-4572-update-01

Hi,

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Mon, 16 May 2016 12:59:24 -0400

Hi,

First of all, I would prefer for hash function values to be encoded using
base64 instead of hex.

Second, it would be better that the separator between the name-value pairs
would be semicolon instead of comma. This keeps it within the normal
name-value pair parser for URL parameters.

Finally, I still have a major problem with Martin's proposal. This is a
change comparatively to every current implementation of fingerprint
matching which I have seen. Furthermore, this is a potentially breaking
change with no indication to the remote party that a different matching
algorithm is used. I would strongly prefer that any updates to anything SDP
fingerprint related would be a clarification of how multiple fingerprints
are handled when received by the end point. This is a clarification of RFC
4572, not a new authentication framework. It should not impose any new
restrictions on fingerprint generation for RFC 4572, such as that only
single certificate is used with connection or that same sets of hash
functions must be used for each certificate, since this will not be
backwards compatible with RFC 4572, which had no such restrictions.

Regards,

_____________
Roman Shpount

On Mon, May 16, 2016 at 12:48 PM, Christer Holmberg <
[email-masked]> wrote:

> The main difference is that it now updates 4572 by saying that multiple
> fingerprint attributes are associated with the SAME certificate, and in
> order to provide fingerprints for multiple certificates the new attribute
> is needed. I think that should solve Martin's backwards compatibility issue.
>
> Regards,
>
> Christer
>
> Another way would be to say that every 'fingerprint' attribute carries a
> fingerprint for the SAME certificate. But, that would of course not work
> with existing(?) implementations that use 'fingerprint' to provide
> fingerprints associated with different certificates...
>
> Regards,
>
> Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 16 May 2016 17:34:24 +0000

Hi,

>First of all, I would prefer for hash function values to be encoded using base64 instead of hex.
>
>Second, it would be better that the separator between the name-value pairs would be semicolon instead of comma. This keeps it within the normal name-value pair parser for URL >parameters.

Sure, but then you need another separator between the hash function name-value pairs and the extensions.

Anyway, I don’t think we need to focus on that at this point. We need to find a way to move forward with this whole issue.

>Finally, I still have a major problem with Martin's proposal. This is a change comparatively to every current implementation of fingerprint matching which I have seen. Furthermore, this is >a potentially breaking change with no indication to the remote party that a different matching algorithm is used. I would strongly prefer that any updates to anything SDP fingerprint related >would be a clarification of how multiple fingerprints are handled when received by the end point. This is a clarification of RFC 4572, not a new authentication framework. It should not >impose any new restrictions on fingerprint generation for RFC 4572, such as that only single certificate is used with connection or that same sets of hash functions must be used for each >certificate, since this will not be backwards compatible with RFC 4572, which had no such restrictions.

To be fair, there is not a single word about multiple fingerprints in 4572 :)

Regards,

Christer

On Mon, May 16, 2016 at 12:48 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Christer Holmberg
Sent: 15 May 2016 22:27
To: Martin Thomson <[email-masked]<mailto:[email-masked]>>; Paul Kyzivat <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-4572-update-01
Hi,

Regards,

Christer

---

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

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

> matching which I have seen. Furthermore, this is >a potentially breaking
> fingerprint related >would be a clarification of how multiple fingerprints
> 4572, not a new authentication framework. It should not >impose any new
> functions must be used for each >certificate, since this will not be
To be fair there is not a single word about how many fingerprints are
allowed in 4572. It can be interpreted either way. If anything, it can be
interpreted that it supports multiple certificates with one fingerprint per
certificate. This is why we wanted to update the document :)

In any case, there are multiple existing implementations out there which
support multiple fingerprints. None of them implement what Martin proposes.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 16 May 2016 17:55:20 +0000

Hi,

>>> Finally, I still have a major problem with Martin's proposal. This is a change comparatively to every current implementation 
>>> of fingerprint matching which I have seen. Furthermore, this is a potentially breaking change with no indication to the 
>>> remote party that a different matching algorithm is used. I would strongly prefer that any updates to anything SDP fingerprint 
>>> related would be a clarification of how multiple fingerprints are handled when received by the end point. This is a clarification 
>>> of RFC 4572, not a new authentication framework. It should not impose any new restrictions on fingerprint generation
>>> for RFC 4572, such as that only single certificate is used with connection or that same sets of hash functions must be used 
>>> for each certificate, since this will not be backwards compatible with RFC 4572, which had no such restrictions.
>>
> To be fair there is not a single word about how many fingerprints are allowed in 4572. It can be interpreted either way. 
> If anything, it can be interpreted that it supports multiple certificates with one fingerprint per certificate. This is why we wanted to update the document :)
>
> In any case, there are multiple existing implementations out there which support multiple fingerprints. None of them implement what Martin proposes.

So, in your experience, when existing implementations provide multiple fingerprints then each fingerprint is associated with a different certificate?

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Mon, 16 May 2016 14:21:37 -0400

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

> >>> Finally, I still have a major problem with Martin's proposal. This is
> a change comparatively to every current implementation
> >>> of fingerprint matching which I have seen. Furthermore, this is a
> potentially breaking change with no indication to the
> >>> remote party that a different matching algorithm is used. I would
> strongly prefer that any updates to anything SDP fingerprint
> >>> related would be a clarification of how multiple fingerprints are
> handled when received by the end point. This is a clarification
> >>> of RFC 4572, not a new authentication framework. It should not impose
> any new restrictions on fingerprint generation
> >>> for RFC 4572, such as that only single certificate is used with
> connection or that same sets of hash functions must be used
> >>> for each certificate, since this will not be backwards compatible with
> RFC 4572, which had no such restrictions.
> >>
> allowed in 4572. It can be interpreted either way.
> > If anything, it can be interpreted that it supports multiple
> certificates with one fingerprint per certificate. This is why we wanted to
> update the document :)
> >
> So, in your experience, when existing implementations provide multiple
> fingerprints then each fingerprint is associated with a different
> certificate?
>

Current open source implementations that I've seen provide a single
certificate, but accept the connection on any single fingerprint match.
Implementations that would provide more then one certificate would be
unusual and would typically be associated with service provider
deployments, such as conference providers. These implementations are often
not based on open source and I cannot easily examine them. This being said,
such implementations can potentially rely on current certificate match
rules in the browsers, so changing such rules can potentially break these
implementations.

Cullen was another person who advocated single fingerprint match and he has
access to one of the larger conferencing implementations. It would be
interesting to see his opinion on this topic.
_____________
Roman Shpount

---

From: Martin Thomson <[email-masked]>
Date: Tue, 17 May 2016 06:44:48 -0400

> The main difference is that it now updates 4572 by saying that multiple fingerprint attributes are associated with the SAME certificate, and in order to provide fingerprints for multiple certificat…

That wasn't the issue at all, so I think that the change is a regression.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 17 May 2016 06:47:27 -0400

This is the issue I think we need to address...

On 16 May 2016 at 12:59, Roman Shpount <[email-masked]> wrote:
> change comparatively to every current implementation of fingerprint matching
> which I have seen.

I'm not proposing that we change existing implementations.  On the
contrary, this relies on them doing exactly what they do today.

> Furthermore, this is a potentially breaking change with
> no indication to the remote party that a different matching algorithm is
> used. I would strongly prefer that any updates to anything SDP fingerprint
> related would be a clarification of how multiple fingerprints are handled
> when received by the end point. This is a clarification of RFC 4572, not a
> new authentication framework. It should not impose any new restrictions on
> fingerprint generation for RFC 4572, such as that only single certificate is
> used with connection

I agree with this.

> or that same sets of hash functions must be used for
> each certificate, since this will not be backwards compatible with RFC 4572,

But disagree with this.  How is providing a different hash going to be
incompatible with existing implementations of 4572?

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 17 May 2016 12:44:40 +0000

>>fingerprint attributes are associated with the SAME
>>certificate, and in order to provide fingerprints for multiple
>>certificates the new attribute is needed. I think that should solve
>>Martin's backwards compatibility issue.
>

Ok, so you think that it should be allowed to use fingerprint attributes
BOTH for multiple hashes (for a single certificate) AND multiple
certificates, and the issue is the matching on receiving side?

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Tue, 17 May 2016 09:29:28 -0400

> certificates, and the issue is the matching on receiving side?

Yes, and it appears that Roman has an issue with what I had proposed,
but I'm sure that I don't understand it.

---

From: Kevin Dempsey <[email-masked]>
Date: Tue, 17 May 2016 15:10:07 +0100

If I understand correctly, your proposal requires senders to include the
same set of hashes for each certificate.

The propose new attribute does not make that a requirement and is also
makes it clear which set of hashes belong to the same certificate.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 17 May 2016 10:19:28 -0400

> same set of hashes for each certificate.

Yes.

> The propose new attribute does not make that a requirement and is also makes
> it clear which set of hashes belong to the same certificate.

I haven't seen any evidence that the either is necessary.  The latter
especially.  Happy to change my mind if someone has real problems with
the former other than the purely academic.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 17 May 2016 14:41:34 +0000

Hi,

The problem people seem to have is mandating the same set of hashes, in case they are calculated by different entities.

I think the question is whether we could mandate the operators of such entities to make sure that the same hashes are used. After all, the different-entity use-case will be relatively uncommon, in my opinion.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Martin Thomson<mailto:[email-masked]>
Sent: ‎17/‎05/‎2016 17:19
To: Kevin Dempsey<mailto:[email-masked]>
Cc: Christer Holmberg<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Paul Kyzivat<mailto:[email-masked]>
Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-4572-update-01

Yes.

---

From: Roman Shpount <[email-masked]>
Date: Tue, 17 May 2016 10:45:43 -0400

> but I'm sure that I don't understand it.
Martin,

I understand that you perceive this issue as academic. I see this as bad
design.

Let me try to explain this again:

1. There are multiple deployed current implementations that match multiple
fingerprints (Firefox and Chrome come to mind)
2. Your proposed a matching algorithm which is different and considerably
stricter then existing implementations
3. You proposed solution provides no indication if your new matching
algorithm is used or a clear migration path. If someone implements it,
connections which worked yesterday will stop working tomorrow with no
indication of the reason.

Your proposed solution should work with offers generated by Firefox and
Chrome, but there are quite a few other implementations which are currently
designed to work with WebRTC end points. Without substantial testing it is
impossible to say if any of them will be affected. They can be affected if
they support multiple certificates or if they insert incorrectly calculated
sha-512 fingerprint together with sha-256.

Considering that a=fingerprint has other design issues (non-extensible,
uses HEX encoding), I am in favor of documenting what current
implementations already do in regard to a=fingerprint and addressing your
security concerns using a new attribute. Since most, if not all DTLS
related implementations are WebRTC related, it should be possible to
migrate to a new attribute within a reasonable time period, provided we
have a migration path. New attribute provides such a path by including both
old and new style fingerprints.

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Tue, 17 May 2016 10:48:32 -0400

On Tue, May 17, 2016 at 10:41 AM, Christer Holmberg <
[email-masked]> wrote:

> The problem people seem to have is mandating the same set of hashes, in
> case they are calculated by different entities.
>
> I think the question is whether we could mandate the operators of such
> entities to make sure that the same hashes are used. After all, the
> different-entity use-case will be relatively uncommon, in my opinion.
>

The problem that I see is that there are already wide spread
implementations of multiple fingerprint matching. I have an issue with
proposing substantialy different and stricter fingerprint matching
algorithm which can break connections that are working with current
implementation without providing a safe migration path.

Regards,
_____________
Roman Shpount

---

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

Hi,

How would making stricter rules make existing implementations to fail? They would match whatever they match, and things should work :)

And, we can never mandate the receiver to match all hashes, because there may be hash functions that the receiver doesn't support to begin with.

Regards,

Christer

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

On Tue, May 17, 2016 at 10:41 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
The problem people seem to have is mandating the same set of hashes, in case they are calculated by different entities.

The problem that I see is that there are already wide spread implementations of multiple fingerprint matching. I have an issue with proposing substantialy different and stricter fingerprint matching algorithm which can break connections that are working with current implementation without providing a safe migration path.

Regards,
_____________
Roman Shpount

---

From: Martin Thomson <[email-masked]>
Date: Tue, 17 May 2016 11:26:29 -0400

> Let me try to explain this again:

It's not working.

> fingerprints (Firefox and Chrome come to mind)

No, we each only match one.

> stricter then existing implementations

Stricter and different aren't a problem unless you can say "in the
following legitimate scenario, things break"

> indication of the reason.

Again, I'm not seeing a situation where this is a problem.  Can you
give me a specific example?

---

From: Roman Shpount <[email-masked]>
Date: Tue, 17 May 2016 12:18:55 -0400

I have double checked the code in Chromium and Firefox.

Chromium code is hard coded to only allow one fingerprint.

Firefox is going through the motions of supporting multiple fingerprints
but it does not look completely implemented.

At this point, since WebRTC browsers do not have a working multiple
fingerprint implementation, we can define whatever we want.

You have me convinced. Let's define that each certificate must provide the
same set of hash functions.

Do we still want to define the new attribute to address HEX encoding and
extensibility issues of a=fingerprint?

Regards,
_____________
Roman Shpount

---

From: Martin Thomson <[email-masked]>
Date: Tue, 17 May 2016 13:45:48 -0400

> extensibility issues of a=fingerprint?

I've basically given up on those as not having high enough return on
investment.  Since you have to duplicate them in a=fingerprint for old
stuff, you don't save space half the time, and extensibility is a
feature you don't need until you have a concrete need.