Subject: [multipathtcp] Replacing SHA-1 with SHA-256

From: Alan Ford <[email-masked]>
Date: Mon, 13 Mar 2017 20:44:05 +0000

Hi all,

It’s been flagged up off-list that given SHA-1 is being deprecated, we should probably look to replace it with SHA-256 in 6824bis. Even though we use truncations of these hashes, the benefits gained from SHA-256 are maybe not significant, but does mean that legacy SHA-1 code would not be required by implementors.

Does anyone have any concerns about such a change? We do not believe it would be significant and could be a direct drop-in in the places where SHA-1 is referenced and used today.

Regards,
Alan

---

From: Greg Greenway <[email-masked]>
Date: Wed, 15 Mar 2017 14:31:17 -0700

Would this change also set a different bit in the MP_CAPABLE option for crypto algorithm negotiation (eg set bit G for SHA-256, instead of the current bit H for SHA-1)?

Thanks,
Greg

> On Mar 13, 2017, at 1:44 PM, Alan Ford <[email-masked]> wrote:
> 
> Hi all,
> 
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 15 Mar 2017 23:17:19 +0100

On 15/03/17 22:31, Greg Greenway wrote:
> Would this change also set a different bit in the MP_CAPABLE option for
> crypto algorithm negotiation (eg set bit G for SHA-256, instead of the
> current bit H for SHA-1)?

No, this idea is that SHA-256 would apply to RFC6824bis, i.e. the 
standard track version of MPTCP while SHA-1 applies to RFC6824

Olivier
>> On Mar 13, 2017, at 1:44 PM, Alan Ford <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> Hi all,
>>
>> It’s been flagged up off-list that given SHA-1 is being deprecated, we
>> should probably look to replace it with SHA-256 in 6824bis. Even
>> though we use truncations of these hashes, the benefits gained from
>> SHA-256 are maybe not significant, but does mean that legacy SHA-1
>> code would not be required by implementors.
>>
>> Does anyone have any concerns about such a change? We do not believe
>> it would be significant and could be a direct drop-in in the places
>> where SHA-1 is referenced and used today.
>>
>> Regards,
>> Alan
>>
>>
>>
>> [email-masked] <mailto:[email-masked]>

---

From: Greg Greenway <[email-masked]>
Date: Wed, 15 Mar 2017 16:09:26 -0700

> On Mar 15, 2017, at 3:17 PM, Olivier Bonaventure <[email-masked]> wrote:
> 
> No, this idea is that SHA-256 would apply to RFC6824bis, i.e. the standard track version of MPTCP while SHA-1 applies to RFC6824

Ok, but this will use MPTCP protocol version 1, whereas anything using SHA-1 will use protocol version 0, correct?  If that's the case, I have no objections.

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 15 Mar 2017 16:52:25 -0700

We probably will need to discuss this in the Chicago meeting to make sure.
We also would like to see if security experts have some opinions on using
SHA-256 or have other recommendations.
--
Yoshi

On Wed, Mar 15, 2017 at 4:09 PM, Greg Greenway <[email-masked]> wrote:

> Ok, but this will use MPTCP protocol version 1, whereas anything using
> SHA-1 will use protocol version 0, correct?  If that's the case, I have no
> objections.
>
> >
> > Olivier

---

From: Alan Ford <[email-masked]>
Date: Thu, 16 Mar 2017 07:57:53 +0000

> On 15 Mar 2017, at 23:09, Greg Greenway <[email-masked]> wrote:
> 
> 

Thanks Greg, that’s exactly what we mean. The diff would literally be s/SHA-1/SHA-256/g (subject to any security area further recommendations).

Best regards,
Alan