Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-4572-update-01 - Light at the end of the tunnel?

From: Christer Holmberg <[email-masked]>
Date: Tue, 17 May 2016 18:32:50 +0000

Hi,

...

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

Awesome!

So, for the SENDER, we would say that it MUST provide the same set of hash functions for each certificate.

Now, what do we say for the RECEIVER and the matching? 

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

My suggestion would be to leave it for now, if we can agree on a solution without it. If needed, we can do it later, in a separate draft.

Regards,

Christer

On Tue, May 17, 2016 at 11:26 AM, Martin Thomson <[email-masked]> wrote:
On 17 May 2016 at 10:45, Roman Shpount <[email-masked]> wrote:
> Let me try to explain this again:

It's not working.

> 1. There are multiple deployed current implementations that match multiple
> fingerprints (Firefox and Chrome come to mind)

No, we each only match one.

> 2. Your proposed a matching algorithm which is different and considerably
> stricter then existing implementations

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

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

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 14:47:10 -0400

> Now, what do we say for the RECEIVER and the matching?
Should match either all fingerprints or the most secure hash function
present and in SDP and supported by the end point.
_____________
Roman Shpount

---

From: Martin Thomson <[email-masked]>
Date: Tue, 17 May 2016 15:43:57 -0400

> present and in SDP and supported by the end point.

WFM, we might add "MAY additionally check other hash functions", but
one match is the ideal

---

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

Hi,

> WFM, we might add "MAY additionally check other hash functions", but one match is the ideal

I guess we would say "considered most secure by the endpoint", because I don't think we want to define what hash functions are more secure than others?

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Tue, 17 May 2016 15:54:00 -0400

> I guess we would say "considered most secure by the endpoint", because I don't think we want to define what hash functions are more secure than others?

Sure.

---

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

On Tue, May 17, 2016 at 3:52 PM, Christer Holmberg <
[email-masked]> wrote:

> I guess we would say "considered most secure by the endpoint", because I
> don't think we want to define what hash functions are more secure than
> others?
>
>
I gust wanted to suggest the same thing since we do not want another
academic discussion.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 17 May 2016 20:05:26 +0000

Hi,

> I gust wanted to suggest the same thing since we do not want another academic discussion.

The security folks may want to have such discussion, but we'll see when we get there :)

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 17 May 2016 20:47:06 +0000

Hi,

Based on the discussions, below is a suggestion for the new text:

--------------

NEW TEXT:

    Multiple SDP fingerprint attributes can be associated with an m-
    line. This can occur if multiple fingerprints have been calculated
    for a certificate, using different hash functions. It can also
    occur if one or more fingerprints associated with multiple
    certificates have been calculated, e.g. for cases where multiple
    certificates will be used for media associated with an m- line
    (e.g. separate certificates for RTP and RTCP), or where it is not
    known which certificate will be used when the fingerprints are
    exchanged. In such cases, one or more fingerprints MUST be
    calculated for each possible certificate.

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

    An endpoint MUST be able to match at least one fingerprint,
    calculated using the hash function that the endpoint supports and
    considers most secure, with the used certificate. If there is no
    match, the endpoint MUST NOT establish the TLS connection. In
    addition, the endpoint MAY also test other fingerprints for a match
    , in which case each tested fingerprints MUST match the used
    certificate.

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

--------------

Regards,

Christer

From: Roman Shpount [mailto:[email-masked]]
Sent: 17 May 2016 22:58
To: Christer Holmberg <[email-masked]>
Cc: Martin Thomson <[email-masked]>; [email-masked]; Paul Kyzivat <[email-masked]>
Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-4572-update-01 - Light at the end of the tunnel?

---

From: Roman Shpount <[email-masked]>
Date: Tue, 17 May 2016 16:49:03 -0400

LGTM

_____________
Roman Shpount

On Tue, May 17, 2016 at 4:47 PM, Christer Holmberg <
[email-masked]> wrote:

> *From:* Roman Shpount [mailto:[email-masked]]
> *Sent:* 17 May 2016 22:58
> *To:* Christer Holmberg <[email-masked]>
> *Cc:* Martin Thomson <[email-masked]>; [email-masked]; Paul
> Kyzivat <[email-masked]>
> *Subject:* Re: [MMUSIC] Draft new version:
> draft-ietf-mmusic-4572-update-01 - Light at the end of the tunnel?
>
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 17 May 2016 17:07:53 -0400

> Based on the discussions, below is a suggestion for the new text:

This looks good except for a couple of points below.

>     An endpoint MUST be able to match at least one fingerprint,

Prefix the above with "For each received certificate".

>     , in which case each tested fingerprints MUST match the used

That sentence isn't true when there are fingerprints for multiple 
certificates. How about:

"In addition, the endpoint may check other hash functions present in the 
fingerprints against the certificate. For each hash function checked, 
one of the fingerprints MUST match the certificate."

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 18 May 2016 07:02:42 +0000

Hi Paul,

...

> Prefix the above with "For each received certificate".

What about "For each used certificate"? 

I used "used" elsewhere, so...

> In addition, the endpoint MAY also test other fingerprints for a 
> match, in which case each tested fingerprints MUST match the used
> certificate.
>
> That sentence isn't true when there are fingerprints for multiple certificates. How about:
>
> "In addition, the endpoint may check other hash functions present in the fingerprints against the 
> certificate. For each hash function checked, one of the fingerprints MUST match the certificate."

In order to align the text with the other terminology/writing style, what about:

	"In addition, the endpoint MAY also test 
    	fingerprints calculated using other hash functions for a match.
    	For each hash function checked, one of the fingerprints MUST match 
    	the used certificate."

Thanks!

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 18 May 2016 07:18:01 +0000

Hi,

New version on github, based on latest discussions, and without a new attribute:

https://github.com/cdh4u/draft-4572-update/blob/master/draft-ietf-mmusic-4572-update.txt

If people are ok with the text I'll submit the new version to IETF.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 May 2016 10:02:03 -0400

> I used "used" elsewhere, so...

Fine.

>     	For each hash function checked, one of the fingerprints MUST match

The nuance I was trying to capture is that one should not decide to test 
a hash function that isn't present in the received fingerprints. If one 
did that then of course you would find no matching fingerprint. You 
wouldn't want to reject based on that.

(Well, I guess you might, if none of the fingerprints offered are 
sufficiently trustworthy for you. But that case would be caught earlier, 
not during this "In addition" phase of checking.)

I don't think your text covers that.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 18 May 2016 15:09:16 +0000

Hi,

...

>>> "In addition, the endpoint may check other hash functions present in 
>>> the fingerprints against the certificate. For each hash function checked, one of the fingerprints MUST match the certificate."
>>
> The nuance I was trying to capture is that one should not decide to test a hash function that isn't present
> in the received fingerprints. If one did that then of course you would find no matching fingerprint. You wouldn't
> want to reject based on that.
>
> (Well, I guess you might, if none of the fingerprints offered are sufficiently trustworthy for you. But that case would be caught earlier, not during this "In addition" phase of checking.)
>

I assumed that people will test using the hash functions that have been used to calculate the associated fingerprints.

Perhaps:

"In addition, the endpoint MAY also other fingerprints (calculated using other hash functions) that it has received for a match.
For each hash function checked, one of the received fingerprints MUST match the used certificate."

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 May 2016 13:08:27 -0400

> I assumed that people will test using the hash functions that have been used to calculate the associated fingerprints.

Safest never to assume.

> For each hash function checked, one of the received fingerprints MUST match the used certificate."

Missing word above. s/also/also check/

Otherwise this seems good.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 18 May 2016 17:24:36 +0000

Hi,

>>>>> "In addition, the endpoint may check other hash functions present 
>>>>> in the fingerprints against the certificate. For each hash function checked, one of the fingerprints MUST match the certificate."
>>>>
>>> The nuance I was trying to capture is that one should not decide to 
>>> test a hash function that isn't present in the received fingerprints. 
>>> If one did that then of course you would find no matching fingerprint. You wouldn't want to reject based on that.
>>>
>>> sufficiently trustworthy for you. But that case would be caught 
>>> earlier, not during this "In addition" phase of checking.)
>>>

Correct.

> Otherwise this seems good.

Thanks! I'll update the text and submit the -02 version.

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Thu, 19 May 2016 09:46:22 -0400

https://avatars3.githubusercontent.com/u/67641?v=3&s=460

On 17 May 2016 at 16:47, Christer Holmberg
<[email-masked]> wrote:
> In

This could be a little clearer; because it could be interpreted as
meaning that all fingerprints have to match.  How about.  ... in which
case, matching MUST fail unless a match is found for every hash
function that is tested.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 19 May 2016 09:47:18 -0400

> case, matching MUST fail unless a match is found for every hash

I should read the thread before replying.  Paul caught this too and
his text is probably better than mine.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 19 May 2016 19:32:58 +0000

> I should read the thread before replying.  Paul caught this too 
> and his text is probably better than mine.

Please also check the text that ended up in the draft :)

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Fri, 20 May 2016 14:36:58 -0400

> Please also check the text that ended up in the draft :)

I think that the text is good.

Nits and grammar suggestions follow:

Drop the comma

You have two nested "e.g." statements.  I would split the first e.g.
into a new sentence starting: This might be needed if multiple
certificates...

"the same set of hash functions MUST be used to calculate fingerprints
for every certificate associated"

     with the m- line.

     For each used certificate, an endpoint MUST be able to match at
     least one fingerprint, calculated using the hash function that the
     endpoint supports and considers most secure, with the used
     certificate. If there is no match, the endpoint MUST NOT establish
     the TLS connection. In addition, the endpoint MAY also check other
     fingerprints (calculated using other hash functions) that it has

"MAY also check fingerprints calculated using other hash functions that it has"

     received for a match. For each hash function checked, one of the
     received fingerprints MUST match the used certificate.

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 21 May 2016 08:37:05 +0000

Hi Martin,

Thanks for your comments! I'll modify the text as  suggested, with a couple of really minor modifications (see below).

> into a new sentence starting: This might be needed if multiple certificates...

Fixed as suggested, and I modified the remaining "e.g." statement to:

	"(e.g. if separate certificates are used for RTP and RTCP)"

> "the same set of hash functions MUST be used to calculate fingerprints for every certificate associated"

Fixed as suggested, but I used "each certificate" instead of "every certificate", in order to be consistent with the rest of the text.

> "MAY also check fingerprints calculated using other hash functions that it has"

Fixed as suggested.

Thanks!

Regards,

Christer