Subject: [MMUSIC] Alissa Cooper's No Objection on draft-ietf-mmusic-4572-update-12: (with COMMENT)

From: "Alissa Cooper" <[email-masked]>
Date: Wed, 01 Feb 2017 10:23:54 -0800

Alissa Cooper has entered the following ballot position for
draft-ietf-mmusic-4572-update-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-4572-update/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 5.1 says:

"An endpoint MAY, in addition to its more preferred hash function,
   also verify that each certificate used matches fingerprints
   calculated using other hash functions.  Unless there is a matching
   fingerprint for each tested hash function, the endpoint MUST NOT
   establish the TLS connection."

This seems a little weird to me. It's up to the endpoint to decide
whether to check for errors, and then if it does find an error it can't
setup the connection, whereas if it just hadn't checked it would be able
to setup the connection. I think it would help to explain why an endpoint
would be motivated to check multiple fingerprints.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 1 Feb 2017 20:04:39 +0000

Hi Alissa,

Thank you for your review! See below.

> This seems a little weird to me. It's up to the endpoint to decide whether to check for errors, and then if it 
> does find an error it can't setup the connection, whereas if it just hadn't checked it would be able to setup 
> the connection. I think it would help to explain why an endpoint would be motivated to check multiple fingerprints.

I think the only use-case that came up was a situation where the receiver is not sure which hash function is the "strongest", and therefor checks multiple. However, it was also realized that with the multiple set of hash functions such situation is very unlikely to occur.

So, I could add the following note:

"NOTE: An endpoint might choose to match each used certificate against fingerprints calculated using multiple
hash functions e.g, if the endpoint is unsure which hash function is the strongest."

...or we could simply delete the text. I personally would go for that, but in case others want to keep it I have no problem with that.

Regards,

Christer

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 1 Feb 2017 15:14:47 -0500

> On Feb 1, 2017, at 3:04 PM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi Alissa,
> 

It would make more sense to me to delete it but either solution would be an improvement I think.

Thanks,
Alissa

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 1 Feb 2017 20:18:56 +0000

Does anyone object to deleting the text? Martin? Ekr? Roman? Cullen?

Regards,

Christer

-----Original Message-----
From: Alissa Cooper [mailto:[email-masked]] 
Sent: 01 February 2017 22:15
To: Christer Holmberg <[email-masked]>
Cc: IESG <[email-masked]>; [email-masked]; Flemming Andreasen <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: Alissa Cooper's No Objection on draft-ietf-mmusic-4572-update-12: (with COMMENT)

>> whether to check for errors, and then if it does find an error it 
>> can't setup the connection, whereas if it just hadn't checked it would be able to setup the connection. I think it would help to explain why an endpoint would be motivated to check multiple fingerprints.
> 
> "NOTE: An endpoint might choose to match each used certificate against 
> fingerprints calculated using multiple hash functions e.g, if the endpoint is unsure which hash function is the strongest."
> 

Thanks,
Alissa

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 01 Feb 2017 14:24:58 -0600

On 1 Feb 2017, at 14:04, Christer Holmberg wrote:

>> whether to check for errors, and then if it
>> the connection. I think it would help to explain why an endpoint 
> I think the only use-case that came up was a situation where the 
> receiver is not sure which hash function is the "strongest", and 
> therefor checks multiple. However, it was also realized that with the 
> multiple set of hash functions such situation is very unlikely to 
> occur.
>
> fingerprints calculated using multiple

In retrospect, I have to question that motivation. Is it that hard to 
figure out? It seems like if you have two hash functions that are 
reasonably equal, an implementation could just pick one.

>
> ...or we could simply delete the text. I personally would go for that, 
> but in case others want to keep it I have no problem with that.

Given that this has caused confusion at every step, I support removing 
the text.

Thanks!

Ben.

---

From: Roman Shpount <[email-masked]>
Date: Wed, 1 Feb 2017 15:34:27 -0500

I am for removing the text.

_____________
Roman Shpount

On Wed, Feb 1, 2017 at 3:18 PM, Christer Holmberg <
[email-masked]> wrote:

> Cc: IESG <[email-masked]>; [email-masked];
> Flemming Andreasen <[email-masked]>; [email-masked];
> [email-masked]
> >> can't setup the connection, whereas if it just hadn't checked it would
> be able to setup the connection. I think it would help to explain why an
> endpoint would be motivated to check multiple fingerprints.
> >
> receiver is not sure which hash function is the "strongest", and therefor
> checks multiple. However, it was also realized that with the multiple set
> of hash functions such situation is very unlikely to occur.
> >
> > fingerprints calculated using multiple hash functions e.g, if the
> endpoint is unsure which hash function is the strongest."
> >
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 1 Feb 2017 15:35:34 -0500

On 2/1/17 3:24 PM, Ben Campbell wrote:
>> multiple set of hash functions such situation is very unlikely to occur.
>>

ISTM that the main point here is: *if* the recipient happens to check 
more than one hash, a failure of any one of them is to be considered an 
overall failure, rather than a success of one and a failure of another 
being considered a success.

Perhaps that ought to be obvious, but I have long since given up giving 
the benefit of the doubt on obviousness.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 2 Feb 2017 08:28:17 +0000

Hi Paul,

>being considered a success.

The question was WHY an endpoint would check more than one hash function
to begin with, and the only reason we have came up with is if the endpoint
doesn¹t ³know" which is the strongest hash - which sounds a little weird.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 2 Feb 2017 11:43:17 +0000

Hi,

Ok, it seems like there is stronger preference for removing the text, and nobody has objected.

So, I will remove the text in the next version of the document.

Regards,

Christer

From: Roman Shpount <[email-masked]<mailto:[email-masked]>>
Date: Wednesday 1 February 2017 at 22:34
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Flemming Andreasen <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MMUSIC] Alissa Cooper's No Objection on draft-ietf-mmusic-4572-update-12: (with COMMENT)

_____________
Roman Shpount

On Wed, Feb 1, 2017 at 3:18 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Does anyone object to deleting the text? Martin? Ekr? Roman? Cullen?

Regards,

Christer

-----Original Message-----
From: Alissa Cooper [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 01 February 2017 22:15
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Cc: IESG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Flemming Andreasen <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: Alissa Cooper's No Objection on draft-ietf-mmusic-4572-update-12: (with COMMENT)

> On Feb 1, 2017, at 3:04 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hi Alissa,
>

Thanks,
Alissa

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

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 2 Feb 2017 12:49:24 +0000

Pull request: https://github.com/fluffy/4572bis/pull/14

Regards,

Christer

From: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Date: Thursday 2 February 2017 at 13:43
To: Roman Shpount <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Flemming Andreasen <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MMUSIC] Alissa Cooper's No Objection on draft-ietf-mmusic-4572-update-12: (with COMMENT)
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>, Jonathan Lennox <[email-masked]<mailto:[email-masked]>>
Resent-Date: Thursday 2 February 2017 at 13:43

Hi,

Regards,

Christer

_____________
Roman Shpount

Regards,

Christer

-----Original Message-----
From: Alissa Cooper [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 01 February 2017 22:15
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Cc: IESG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Flemming Andreasen <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: Alissa Cooper's No Objection on draft-ietf-mmusic-4572-update-12: (with COMMENT)

Thanks,
Alissa

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 2 Feb 2017 12:15:42 -0500

> doesn¹t ³know" which is the strongest hash - which sounds a little weird.

I don't see why we need to know why. Maybe they intend to try them all, 
just for completeness.

But if there is ever a question about the validity of an implementation, 
I don't want to be arguing with somebody who says:

"I tried them all, and several failed but one succeeded so I decided it 
must be ok."

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Thu, 2 Feb 2017 12:48:00 -0500

On Thu, Feb 2, 2017 at 12:15 PM, Paul Kyzivat <[email-masked]>
wrote:

> But if there is ever a question about the validity of an implementation, I
> don't want to be arguing with somebody who says:
>

What we are trying to say is:

There MUST be a fingerprint matching the used certificate for each hash
algorithm present. End point SHOULD pick a set of one or more preferred
hash functions that should be checked to satisfy end point's security
requirements. Unless there is a matching fingerprint for each tested hash
function, the endpoint MUST NOT establish the TLS connection. It is
recommended that a single matching SHA-256 fingerprint should be sufficient
to verify the certificate.

Think of this as personal ID. You need one photo ID to get on the plain,
but bank will ask for two forms of ID before giving you money.
_____________
Roman Shpount

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 02 Feb 2017 12:00:35 -0600

That looks good to me. Please submit a new revision when you are ready.

Thanks!

Ben.

On 2 Feb 2017, at 6:49, Christer Holmberg wrote:

> From: Christer Holmberg 
> <[email-masked]<mailto:[email-masked]>>
> Cc: "[email-masked]<mailto:[email-masked]>" 
> <[email-masked]<mailto:[email-masked]>>, Flemming Andreasen 
> <[email-masked]<mailto:[email-masked]>>, 
> "[email-masked]<mailto:[email-masked]>" 
> <[email-masked]<mailto:[email-masked]>>, 
> "[email-masked]<mailto:[email-masked]>" 
> <[email-masked]<mailto:[email-masked]>>, 
> "[email-masked]<mailto:[email-masked]>" 
> <[email-masked]<mailto:[email-masked]>>, 
> "[email-masked]<mailto:[email-masked]>" 
> <[email-masked]<mailto:[email-masked]>>
> Subject: Re: [MMUSIC] Alissa Cooper's No Objection on 
> draft-ietf-mmusic-4572-update-12: (with COMMENT)
> Resent-To: Christer Holmberg 
> <[email-masked]<mailto:[email-masked]>>, 
> Jonathan Lennox <[email-masked]<mailto:[email-masked]>>
> To: Christer Holmberg 
> <[email-masked]<mailto:[email-masked]>>
> Cc: "[email-masked]<mailto:[email-masked]>" 
> <[email-masked]<mailto:[email-masked]>>, Flemming Andreasen 
> <[email-masked]<mailto:[email-masked]>>, 
> "[email-masked]<mailto:[email-masked]>" 
> <[email-masked]<mailto:[email-masked]>>, 
> "[email-masked]<mailto:[email-masked]>" 
> <[email-masked]<mailto:[email-masked]>>, 
> "[email-masked]<mailto:[email-masked]>" 
> <[email-masked]<mailto:[email-masked]>>, 
> "[email-masked]<mailto:[email-masked]>" 
> <[email-masked]<mailto:[email-masked]>>
> Subject: Re: [MMUSIC] Alissa Cooper's No Objection on 
> draft-ietf-mmusic-4572-update-12: (with COMMENT)
>
> On Wed, Feb 1, 2017 at 3:18 PM, Christer Holmberg 
> <[email-masked]<mailto:[email-masked]>> 
> wrote:
> From: Alissa Cooper 
> [mailto:[email-masked]<mailto:[email-masked]>]
> To: Christer Holmberg 
> <[email-masked]<mailto:[email-masked]>>
> Cc: IESG <[email-masked]<mailto:[email-masked]>>; 
> [email-masked]<mailto:[email-masked]>; 
> Flemming Andreasen <[email-masked]<mailto:[email-masked]>>; 
> [email-masked]<mailto:[email-masked]>; 
> Subject: Re: Alissa Cooper's No Objection on 
> draft-ietf-mmusic-4572-update-12: (with COMMENT)
>
>
>> On Feb 1, 2017, at 3:04 PM, Christer Holmberg 
>> <[email-masked]<mailto:[email-masked]>> 
>> wrote:
>>
>> Hi Alissa,
>>
>>> can't setup the connection, whereas if it just hadn't checked it 
>>> would be able to setup the connection. I think it would help to 
>>> explain why an endpoint would be motivated to check multiple 
>>> fingerprints.
>>
>> ...or we could simply delete the text. I personally would go for 
>> that, but in case others want to keep it I have no problem with that.
>