Subject: [MMUSIC] 4572-update: Consensus call on how to move forward

From: Flemming Andreasen <[email-masked]>
Date: Wed, 12 Oct 2016 18:23:26 -0400

Greetings

There has been quite a bit of discussion on 
draft-ietf-mmusic-4572-update (currently -07), which had previously 
completed WGLC when a few concerns were raised. The document currently:
1. Clarifies the usage of multiple SDP 'fingerprint' attributes
2. Updates the preferred cipher-suite with a stronger cipher suite
3. Updates RFC 4572.

Item 1 seems to be generally agreeable, whereas items 2 and 3 are not. 
The chairs are hereby soliciting WG feedback on how to proceed based on 
the following choices:

a) Proceed with publication of 4572-update-07 in its current form (i.e. 
covering all 3 items above)

b) Remove item 2 from 4572-update, i.e. do not update the preferred 
cipher-suite

c) Remove item 3 from 4572-update, i.e. do not indicate that this 
document constitutes an update to RFC 4572.

Note that choice a) is mutually exclusive with b) and c), but b) and c) 
are not mutually exclusive.

Please let us know your preference wrt to the above no later than Friday 
October 14th.

Thanks

        Flemming & Bo (MMUSIC chairs)

---

From: Roman Shpount <[email-masked]>
Date: Wed, 12 Oct 2016 18:32:48 -0400

Hi All,

I would prefer *a* -- proceed with publication in its current form and
update 4572. Chrome and Firefox already do SHA-256 and that seems to cause
no issues. Multiple fingerprint language is required to create 4572
implementations which are compatible with each other. The current language
in 4572 is ambiguous enough so that you can create two implementations
which would supposedly be compatible with 4572 (establish connection when
getting SDP with multiple fingerprints or failing to do so), but will not
work with each other. Because of this I think 4572 needs to be updated.

Regards,

_____________
Roman Shpount

On Wed, Oct 12, 2016 at 6:23 PM, Flemming Andreasen <[email-masked]>
wrote:

> Greetings
>
> There has been quite a bit of discussion on draft-ietf-mmusic-4572-update
> (currently -07), which had previously completed WGLC when a few concerns
> were raised. The document currently:
> Item 1 seems to be generally agreeable, whereas items 2 and 3 are not. The
> chairs are hereby soliciting WG feedback on how to proceed based on the
> following choices:
>
> c) Remove item 3 from 4572-update, i.e. do not indicate that this document
> constitutes an update to RFC 4572.
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 13 Oct 2016 12:09:08 +1100

> covering all 3 items above)

I would prefer this option.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 12 Oct 2016 22:13:45 -0400

I prefer (a).

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 12 Oct 2016 20:36:54 -0600

I really object to this. I think there is a much better option than any of these three options and I have asked us to have a phone call to discuss it. I'd like a chance to actually consider the issue here before we take a consensus call where we hear from a bunch of people that aren't building  products that do the current 4572. 

Once again, can we please have a phone call to discuss this. 

> On Oct 12, 2016, at 4:23 PM, Flemming Andreasen <[email-masked]> wrote:
> 
> Greetings
> 
> There has been quite a bit of discussion on draft-ietf-mmusic-4572-update (currently -07), which had previously completed WGLC when a few concerns were raised. The document currently:
> Item 1 seems to be generally agreeable, whereas items 2 and 3 are not. The chairs are hereby soliciting WG feedback on how to proceed based on the following choices:
> 
> a) Proceed with publication of 4572-update-07 in its current form (i.e. covering all 3 items above)
> 
> b) Remove item 2 from 4572-update, i.e. do not update the preferred cipher-suite
> 
> c) Remove item 3 from 4572-update, i.e. do not indicate that this document constitutes an update to RFC 4572.
> 
> 
> Note that choice a) is mutually exclusive with b) and c), but b) and c) are not mutually exclusive.
> 
> Please let us know your preference wrt to the above no later than Friday October 14th.
> 
> 
> Thanks
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 13 Oct 2016 02:36:49 +0000

Hi,

I prefer a).

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Flemming Andreasen
Sent: 13 October 2016 01:23
To: mmusic <[email-masked]>
Subject: [MMUSIC] 4572-update: Consensus call on how to move forward

Greetings

There has been quite a bit of discussion on draft-ietf-mmusic-4572-update (currently -07), which had previously completed WGLC when a few concerns were raised. The document currently:
1. Clarifies the usage of multiple SDP 'fingerprint' attributes 2. Updates the preferred cipher-suite with a stronger cipher suite 3. Updates RFC 4572.

Item 1 seems to be generally agreeable, whereas items 2 and 3 are not. 
The chairs are hereby soliciting WG feedback on how to proceed based on the following choices:

Thanks

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 13 Oct 2016 02:39:50 +0000

Hi Cullen,

I build products.

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Cullen Jennings
Sent: 13 October 2016 05:37
To: Flemming Andreasen <[email-masked]>
Cc: mmusic <[email-masked]>
Subject: Re: [MMUSIC] 4572-update: Consensus call on how to move forward

> 1. Clarifies the usage of multiple SDP 'fingerprint' attributes 2. 
> Updates the preferred cipher-suite with a stronger cipher suite 3. 
> Updates RFC 4572.
>

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 12 Oct 2016 20:44:13 -0600

Yes, I'm aware you  do and other people on this thread too. I'm not sure how many stuff deployed that uses 4572 is done by too many. But ignoring all that, I would expect you of all people to be willing to have a call and see if we can come up with something that meets what everyones desires before just stuffing this though. Why wouldn't you do that? 

> On Oct 12, 2016, at 8:39 PM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi Cullen,
> 
> I build products.
> 
> Regards,
> 
> Christer
>

---

From: Roman Shpount <[email-masked]>
Date: Wed, 12 Oct 2016 22:53:21 -0400

I do build products as well. I would be happy to get on the call. Can you
at least give us a hint what product is affected or at least what is the
exact problem you are trying to prevent?

Roman Shpount

On Oct 12, 2016 10:37 PM, "Cullen Jennings" <[email-masked]> wrote:

>
> I really object to this. I think there is a much better option than any of
> these three options and I have asked us to have a phone call to discuss it.
> I'd like a chance to actually consider the issue here before we take a
> consensus call where we hear from a bunch of people that aren't building
> products that do the current 4572.
>

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 12 Oct 2016 21:03:55 -0600

I'm fine with an RFC that updates 4572 to clarify that you can have multiple fingerprints. Given I believe that 4572 already allows that I prefer it written as a clarification rather than a change. Call it RFC-A

I'm fine with an RFC that is an extension to RFC-A that mandates the use of SHA-256 as well fingerprints from RFC-A. Call RFC-B. I think it sill needs to require a fingerprint from the hash used in the cert signature to be backwards compatible with 4572. I don't think it needs to be an update to RFC-A. 

This allows things that want to do SHA-256 to reference RFC-B. WebRTC for example.

However for people that are have shipping 4572 stuff, it makes it very clear that their implementations still follow the advice in 4572, all updates to it, and any errata. It also make is clear for people building stuff that they want to interop with things that do 4572 that they can't assume it has SHA-256. Changing 4572 at this point just make it easier for all the people that would rather do SDES to just keep saying well, perhaps we will do DTLS-SRTP with fingerprint once it stabilizes but that has clearly not happened yet so lets wait. 

I'm happy to explain in more detail the issue on a call but I've tried in email before and seem to fail to communicate them so I'd like to have a call to discuss. 

> On Oct 12, 2016, at 8:47 PM, Roman Shpount <[email-masked]> wrote:
> 
> I do build products as well. I would be happy to get on the call. Can you at least give us a hint what product is affected or at least what is the exact problem you are trying to prevent?
> 
> Roman Shpount
> 
>

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 12 Oct 2016 22:50:19 -0700

I would also prefer "a".  Edge, Chrome and Firefox already do SHA-256 so
this is just recognizing reality. Updating RFC 4572 is not an issue to me.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 12 Oct 2016 23:06:35 -0700

Cullen said:

"I think it still needs to require a fingerprint from the hash used in the
cert signature to be backwards compatible with 4572."

[BA] Definitely.  I haven't heard any objection to that requirement so far.

Cullen also said:

"Changing 4572 at this point just make it easier for all the people that
would rather do SDES to just keep saying well, perhaps we will do DTLS-SRTP
with fingerprint once it stabilizes"

[BA] Given all the ongoing changes in DTLS versions (e.g. update to 1.2 and
after that, 1.3), ciphersuites and certs (e.g. ECDSA), PFS, APIs (e.g.
certificate management API), this RFC 4572 update is small potatoes,
particularly if the backward compatibility issues are addressed. So if an
potential implementer can maintain their serenity in the face of all the
other DTLS changes, it seems unlikely they will be pushed over the edge by
this proposed Update (though they might well decide it is not worth
implementing).

On Wed, Oct 12, 2016 at 8:03 PM, Cullen Jennings <[email-masked]> wrote:

>
> I'm fine with an RFC that updates 4572 to clarify that you can have
> multiple fingerprints. Given I believe that 4572 already allows that I
> prefer it written as a clarification rather than a change. Call it RFC-A
>
> I'm fine with an RFC that is an extension to RFC-A that mandates the use
> of SHA-256 as well fingerprints from RFC-A. Call RFC-B. I think it sill
> needs to require a fingerprint from the hash used in the cert signature to
> be backwards compatible with 4572. I don't think it needs to be an update
> to RFC-A.
>
> However for people that are have shipping 4572 stuff, it makes it very
> clear that their implementations still follow the advice in 4572, all
> updates to it, and any errata. It also make is clear for people building
> stuff that they want to interop with things that do 4572 that they can't
> assume it has SHA-256. Changing 4572 at this point just make it easier for
> all the people that would rather do SDES to just keep saying well, perhaps
> we will do DTLS-SRTP with fingerprint once it stabilizes but that has
> clearly not happened yet so lets wait.
>
> I'm happy to explain in more detail the issue on a call but I've tried in
> email before and seem to fail to communicate them so I'd like to have a
> call to discuss.
>
> > I do build products as well. I would be happy to get on the call. Can
> you at least give us a hint what product is affected or at least what is
> the exact problem you are trying to prevent?
> >
> > Roman Shpount
> >
> >
> > I really object to this. I think there is a much better option than any
> of these three options and I have asked us to have a phone call to discuss
> it. I'd like a chance to actually consider the issue here before we take a

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 13 Oct 2016 07:07:20 +0000

Hi,

>I think it still needs to require a fingerprint from the hash used in the cert signature to be >backwards compatible with 4572.

Version -07 contains the following text - which was added based on your comments:

    "An endpoint MUST, as a minimum, calculate a fingerprint using both the 'SHA-256'
    hash function algorithm and the hash function used to generate the
    signature on the certificate for each possible certificate."

Regards,

Christer

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 13 Oct 2016 09:40:21 -0600

> On Oct 13, 2016, at 1:07 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 

Yah, I think that is the right text for RFC-B.

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 13 Oct 2016 14:14:57 -0600

> On Oct 13, 2016, at 11:13 AM, Roman Shpount <[email-masked]> wrote:
> 
> Cullen,
> 
> Just to clarify, you want to avoid making SHA-256 a MUST. Why is this a problem? I cannot think of a single library that implements DTLS but does not implement SHA-256. Can you point me to any 4572 implementations that do not support SHA-256?
> 

note there is an difference between MTI and MTU and lots of TLS things implement ciphers that may not be configured for use but to get to your questions. 

Yes. 

4572 was published in 2006 and there were multiple implementation before it was published with some of them (including Cisco's) based on openssl. SHA256 was added to be default in openssl in 2010. Cisco's version of openssl lags the main branch due to security review and getting it to be FIPS approved. There is plenty of 4572 stuff that does not do SHA256. 

And don't get me wrong, I want to add a RFC that has SHA256 but I do not see the point in gratuitously demanding that everything support it. Thus my argument for an RFC that adds SHA256 that is merely an extension to 4572.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 13 Oct 2016 13:33:03 -0700

Cullen said:

"And don't get me wrong, I want to add an RFC that has SHA256 but I do not
see the point in gratuitously demanding that everything support it."

[BA] I can see an argument for new implementations being able to verify old
digital signatures and hashes created with SHA-1.  However, the use of
SHA-1 to generate digital signatures is being deprecated, so new
implementations do need to move to alternatives, such as SHA-256.  For
example, here is the NIST policy on hash functions as of August 5, 2015:
http://csrc.nist.gov/groups/ST/hash/policy.html

*SHA-1*: Federal agencies *should* stop using SHA-1 for generating digital
signatures, generating time stamps and for other applications that require
collision resistance. Federal agencies may use SHA-1 for the following
applications: verifying old digital signatures and time stamps, generating
and verifying hash-based message authentication codes (HMACs), key
derivation functions (KDFs), and random bit/number generation. Further
guidance on the use of SHA-1 is provided in SP 800-131A.

*SHA-2 (i.e., SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 and
SHA-512/256)*: Federal agencies may use these hash functions for all
applications that employ secure hash algorithms. NIST encourages
application and protocol designers to implement SHA-256 at a minimum for
any applications of hash functions requiring interoperability. Further
guidance on the use of SHA-2 is provided in SP 800-57 Part 1, section 5.6.2
and SP 800-131A.

On Thu, Oct 13, 2016 at 1:14 PM, Cullen Jennings <[email-masked]> wrote:

> > Just to clarify, you want to avoid making SHA-256 a MUST. Why is this a
> problem? I cannot think of a single library that implements DTLS but does
> not implement SHA-256. Can you point me to any 4572 implementations that do
> not support SHA-256?
> >
>
> note there is an difference between MTI and MTU and lots of TLS things
> implement ciphers that may not be configured for use but to get to your
> questions.
>
> Yes.
>
> 4572 was published in 2006 and there were multiple implementation before
> it was published with some of them (including Cisco's) based on openssl.
> SHA256 was added to be default in openssl in 2010. Cisco's version of
> openssl lags the main branch due to security review and getting it to be
> FIPS approved. There is plenty of 4572 stuff that does not do SHA256.
>
> And don't get me wrong, I want to add a RFC that has SHA256 but I do not
> see the point in gratuitously demanding that everything support it. Thus my
> argument for an RFC that adds SHA256 that is merely an extension to 4572.
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 13 Oct 2016 15:05:57 -0700

A few notes in no particular order on the technical side:

0. We clearly want to clean up the situation re: multiple fingerprints.
1. I think it's clear we do want to move to SHA-256.
2. It's not clear that the current attacks actually implicate the use of
SHA-1 in this setting. The reason is that those attacks are targeted at
collisions but I believe that to mount a successful attack here you would
need a preimage, though I could be wrong on this point.
3. On the compat side, it seems inevitable that allowing multiple
fingerprints is going to have the effect of breaking any agent which read
4572 as only allowing one. Not sure what we can do about that.

I take the concern Cullen to be raising that "Updates 4572" somehow
retroactively makes implementations which only supported SHA-1 to be
noncompliant?

I'm pretty much indifferent to what appears in this field. The bottom line
is that going forward we would like people to comply with this draft (RFC
XXX) and that people who don't do so are going to have a bad day, no matter
what appears in the Updates field. If it makes people more comfortable not,
I am fine with that. Would "Obsoletes" be better?

-Ekr

On Thu, Oct 13, 2016 at 1:33 PM, Bernard Aboba <[email-masked]>
wrote:

> Cullen said:
>
> "And don't get me wrong, I want to add an RFC that has SHA256 but I do
> not see the point in gratuitously demanding that everything support it."
>
> [BA] I can see an argument for new implementations being able to verify
> old digital signatures and hashes created with SHA-1.  However, the use of
> *SHA-1*: Federal agencies *should* stop using SHA-1 for generating
> digital signatures, generating time stamps and for other applications that
> require collision resistance. Federal agencies may use SHA-1 for the
> following applications: verifying old digital signatures and time stamps,
> generating and verifying hash-based message authentication codes (HMACs),
> key derivation functions (KDFs), and random bit/number generation. Further

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 19 Oct 2016 08:43:29 -0400

Hi

Following up on the consensus call, we have received 5 responses in 
favor of option a) below, one neutral, and one objection. Looking at the 
document we have noted that backwards compatibility is handled by the 
current text in the document and it also clearly states that it does not 
make current RFC 4572 implementation non-compliant with RFC 4572. Since 
we have not heard of any technical problems with proposal a), nor seen 
any tangible progress on how to address the objection, we are hereby 
declaring rough consensus on option a). We will proceed with the 
publication request for the current draft while duly noting the 
"roughness" of the consensus based on the pending objection as part of 
this.

Thanks

On 10/12/16 6:23 PM, Flemming Andreasen wrote:
> .

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 21 Oct 2016 09:21:53 -0600

I think that is a bad way to run a WG. All I asked for was a phone call to discuss this so we could get the issues on the table and discuss what is best. The chairs never even replied to my request for a WG call to discuss this. The list discussions that ensued from this resulted in people other than me sugesting possibilities that were much better than any of the three below -  none of which were considered in your consensus call. 

I don’t plan to appeal this but I am considering if it’s worth my time to participate in this WG if we are not going to be willing to actually spend a short time to discuss possible solutions before taking a consensus call.  As input to that decisions, it would be really useful to know why you refused to have a phone call on this topic and what your policy in general is going to be toward discussions of proposed solutions to problems in the future. 

> On Oct 19, 2016, at 6:43 AM, Flemming Andreasen <[email-masked]> wrote:
> 
> Hi
> 
> Following up on the consensus call, we have received 5 responses in favor of option a) below, one neutral, and one objection. Looking at the document we have noted that backwards compatibility is handled by the current text in the document and it also clearly states that it does not make current RFC 4572 implementation non-compliant with RFC 4572. Since we have not heard of any technical problems with proposal a), nor seen any tangible progress on how to address the objection, we are hereby declaring rough consensus on option a). We will proceed with the publication request for the current draft while duly noting the "roughness" of the consensus based on the pending objection as part of this.
> 
> Thanks
>

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 21 Oct 2016 11:59:53 -0400

On 10/21/16 11:21 AM, Cullen Jennings wrote:
> I think that is a bad way to run a WG. All I asked for was a phone call to discuss this so we could get the issues on the table and discuss what is best. The chairs never even replied to my request for a WG call to discuss this.
That is simply not true. You (and Christer) were explicitly asked to 
setup a phone call on 10/6/16 to discuss this issue; a request that 
(like many other others) went unanswered or required extensive prodding 
to get any attention.

> The list discussions that ensued from this resulted in people other than me sugesting possibilities that were much better than any of the three below -  none of which were considered in your consensus call.
I'm not sure what those proposals are, nor were they brought up in 
response to the consensus call.

> I don’t plan to appeal this but I am considering if it’s worth my time to participate in this WG if we are not going to be willing to actually spend a short time to discuss possible solutions befor…
My position is that we will try our very best to get to not only 
consensus but to satisfy as many concerns as we possibly can. It does 
however require people to engage in a timely manner, and even when they 
don't, we still do what we can, but at some point we need to move 
forward. As for the issue at hand, it has been discussed extensively, 
and several changes were made to the draft to try and accommodate your 
requests.

The one major remaining issue I believe you have is around whether this 
document updates RFC 4572. This has been discussed extensively on the 
wgchairs list; a discussion I initiated to try and help address your 
concern. You may disagree with how that discussion concluded, but again, 
to try and alleviate your concerns, a note was added to 4572-update to 
make it clear that the document does not make existing 4572 
implementations non-compliant with RFC 4572.

I believe the chairs, authors, and the WG at large has done everything 
that can reasonably be done to try and address your concerns, and at 
this point we need to move forward.

Thanks

-- Flemming (as MMUSIC co-chair)

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 21 Oct 2016 12:05:31 -0400

[fixing cc-list]

On 10/21/16 11:59 AM, Flemming Andreasen wrote:
>> I think that is a bad way to run a WG. All I asked for was a phone 
>> call to discuss this so we could get the issues on the table and 
>> discuss what is best. The chairs never even replied to my request for 
>> a WG call to discuss this.
> (like many other others) went unanswered or required extensive 
> prodding to get any attention.
>
>> The list discussions that ensued from this resulted in people other 
>> than me sugesting possibilities that were much better than any of the 
>> three below -  none of which were considered in your consensus call.
>> I don’t plan to appeal this but I am considering if it’s worth my 
>> time to participate in this WG if we are not going to be willing to 
>> actually spend a short time to discuss possible solutions before 
>> taking a consensus call.  As input to that decisions, it would be 
>> really useful to know why you refused to have a phone call on this 
>> topic and what your policy in general is going to be toward 
>> discussions of proposed solutions to problems in the future.
> however require people to engage in a timely manner, and even when 
> they don't, we still do what we can, but at some point we need to move 
> The one major remaining issue I believe you have is around whether 
> this document updates RFC 4572. This has been discussed extensively on 
> the wgchairs list; a discussion I initiated to try and help address 
> your concern. You may disagree with how that discussion concluded, but 
> again, to try and alleviate your concerns, a note was added to 
> 4572-update to make it clear that the document does not make existing 
> 4572 implementations non-compliant with RFC 4572.
>
>>> favor of option a) below, one neutral, and one objection. Looking at 
>>> the document we have noted that backwards compatibility is handled 
>>> by the current text in the document and it also clearly states that 
>>> it does not make current RFC 4572 implementation non-compliant with 
>>> RFC 4572. Since we have not heard of any technical problems with 
>>> proposal a), nor seen any tangible progress on how to address the 
>>> objection, we are hereby declaring rough consensus on option a). We 
>>> will proceed with the publication request for the current draft 
>>> while duly noting the "roughness" of the consensus based on the 
>>> pending objection as part of this.
>>>
>>> Thanks
>>>
>>>> Item 1 seems to be generally agreeable, whereas items 2 and 3 are 
>>>> not. The chairs are hereby soliciting WG feedback on how to proceed 
>>>> based on the following choices:
>>>>