Subject: [MMUSIC] draft-4572-update: Pull request to remove update of preferred cipher

From: Christer Holmberg <[email-masked]>
Date: Sun, 9 Oct 2016 10:20:09 +0000

Hi,

I've created a PR that removes all text regarding updating the preferred cipher suite of RFC 4572. The text now only contains the multiple fingerprint clarifications.

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

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 09 October 2016 11:47
To: Paul Kyzivat <[email-masked]>; Cullen Jennings <[email-masked]>
Cc: [email-masked]
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-4572-update-07.txt

Hi,

>>> I know you were following the wgchairs thread on '"Updates: RFC xxx" 
>>> - what does it actually mean ?' because you replied in that thread. 
>>> If you agree with the conclusion there th
>>
>> The conclusion of that thread - after it expanded beyond the chairs 
>> list
>> - was AFAIC, that this was unclear and someone should write a RFC to 
>> clarify it. If you think there was consensus on what update means, 
>> then I strongly agree and invite you to go look at number of people 
>> that put out position on each side. Until a new RFC gets issues, I 
>> will use the meaning in the only published RFC that defined this even 
>> though it was deprecated by a later RFC that did not provide any 
>> definition one way or the other.
>
> My understanding was that it is unclear and people were happy to leave 
> it unclear. Instead of clarifying it, individual drafts are expected 
> to add prominent text that explains what it means in the context of that draft.

...which is exactly what we have done in the latest version of draft-4572-update.

But, again, if that's enough, I'm personally ok to remove the cipher update.

> I don't *like* that conclusion, but I don't consider it worthwhile to pursue it further.
>
>> And to be clear, what I am proposing here is a simple way for this WG 
>> to move forward without having to resolve that debate or wait for 
>> consensus on what update means.
>
> If splitting this into two drafts will satisfy you, then I'm ok with that.
>
> But it also seems like it ought to be adequate to leave it one document, with Updates, and a clear statement of what Updates does and doesn't mean in this case.

In my opinion, the most time critical is to get the multiple fingerprint clarification done, so I'll start working on a pull request that removes all the SHA-256 stuff.

I do think it's sad that issues like this are raised in the last minute - especially by people that for sure have been aware of the work - e.g., when others have spent lots of time in order to come up with agreeable text. But, at the end of the day what matters is to finalize the work...

Regards,

Christer

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 10 Oct 2016 10:33:25 +1100

I think that this is a step backwards.  I wholeheartedly disagree with
Cullen's view that using "Updates" forces us to be constrained by the
document we are updating.  The whole point of "Updates" is to update
things.

Yes, that means that implementations that are 4572-compliant will now
be 4572-plus-update non-compliant.  But those are two different
things, we don't render a 4572-compliant implementation non-compliant
by publishing another document.

If we were to write yet another trivial draft to update to SHA-256, I
would argue that it update RFC 4572.  SHA-1 collision resistance is so
far gone at this point we'd be irresponsible to do otherwise.  So I
don't see what the paper-shuffling gains us.

---

From: Roman Shpount <[email-masked]>
Date: Mon, 10 Oct 2016 17:48:44 -0400

Just to add an observation regarding current implementations:

1. Most implementations already use SHA-256 or will accept it.
2. A lot of implementations will fail to establish a connection if they
receive an SDP with multiple fingerprints
3. Hash function match between certificate and fingerprint is irrelevant. I
am not aware of anybody checking this.

Based on this, a lot, if not most of the implementations will need to be
updated to be compatible with 4572 with multiple fingerprints.  This new
draft simply clarifies this point, since it is not a new requirement. It
also clarifies how multiple fingerprints should be generated and matched.
Additional code required to support SHA-256 is typically already present in
the existing implementations so will require trivial amount of effort to
implement.

Bottom line, we have a lot of theoretical problems with backwards
compatibility related to which hashes are used to create the fingerprint
which actually do not exist in practice. On the other hand we have one real
problem: will remote end point accept multiple fingerprints or not? While
we are are spinning our wheels about solving problems that are not there,
the only way to make sure multiple fingerprints are supported is to do a
version check on remote end point. Since I am doing version checks anyway,
and since I consider not supporting multiple fingerprints a bug, I can live
with the new draft with or without SHA-256.

If you consider version checks evil, then draft needs to be updated to
indicate that multiple fingerprints are supported or to use different
attribute to provide multiple fingerprints. Since this is very late in the
process I prefer to release the current document.

Regards,
_____________
Roman Shpount