Supporting insecure protocols in RMCP+

Supporting insecure protocols in RMCP+

[Vernon Mauery]

> Patch Set 4:
>
>> Given that RMCP+ is already insecure, unless it is a requirement to 
>> support 1, 2, 15, and 16, you may just want to support 3 and 17.
>
> 1,2,3 are marked as mandatory in the specification. It should be a 
> community decision to revoke support for 1,2. If the community is ok, 
> it will need additional code changes.

tl;dr IPMI is old; let's drop the most insecure parts

Opening this up to a wider audience. I would like some community 
consensus on how we should deal with parts of specifications that don't 
make sense anymore.

Tables in section 13.28:
(authentication algorithm support)
00h: RAKP-none        Mandatory (recommend dropping support)
01h: RAKP-HMAC-SHA1   Mandatory (good, but not best; keep for now)
02h: RAKP-HMAC-MD5    Optional (not implemented; do not implement)
03h: RAKP-HMAC-SHA256 Optional (implemented; best available)

(integrity algorithm support)
00h: none             Mandatory (recommend dropping support)
01h: HMAC-SHA1-96     Mandatory (good, but not best; keep for now)
02h: HMAC-MD5-128     Optional (not implemented; do not implement)
03h: MD5-128          Optional (not implemented; do not implement)
04h: HMAC-SHA256-128  Optional (implemented; best available)

(confidentiality algorithm support)
00h: none             Mandatory (recommend dropping support)
01h: AES-CBC-128      Mandatory (implemented; best available)
02h: xRC4-128         Optional (not implemented; do not implement)
03h: xRC4-40          Optional (not implemented; do not implement)

The IPMI spec was written in a time when computing resources were 
minimal and before some of the real security awareness started. And as 
such, it contains some legacy stuff that should really be dropped or at 
the very least deprecated.

The IPMI spec only says that we must implement certain authentication, 
integrity, and confidentiality algorithms, it does not explicitly say 
what cipher suites must be implemented. But, if we implement every 
cipher suite that is available with the required algorithms, we would 
implement cipher suites 0, 1, 2, and 3. And if we added in sha256 
integrity and authentication, we add in 15, 16, and 17.

Just for comparison, DCMI 1.5 requires only 3, with 17 as recommended 
and 8 as optional. This is a step up from IPMI's security 
recommendations, but still not best. I would say that 3 and 17 should be 
required, with the recommendation that 3 be deprecated (or disabled at 
runtime) in favor of 17 only.

I think we can all agree that cipher suite 0 is poison. It is a gaping 
open door with bright lights saying, "Hack me!" I would argue that 
cipher suites 1 and 2 are not much better. We have the computing 
resources to perform better security, so we should do it. As web 
browsers move along, they deprecate and then disable old versions of 
SSL/TLS. We should do the same. Just because at one point in history it 
was fine to authenticate with plaintext passwords, does not mean we 
should continue to do so. If you know better, do better.

Even if end users come to us and say that they MUST have cipher suite 1 
or 2, I would argue that we should tell them to update their 
infrastructure rather than re-implement old insecure protocols.


--Vernon

Re: Supporting insecure protocols in RMCP+

[Vernon Mauery]

On 23-Apr-2018 11:47 AM, Vernon Mauery wrote:
>>Patch Set 4:
>>
>>>Given that RMCP+ is already insecure, unless it is a requirement 
>>>to support 1, 2, 15, and 16, you may just want to support 3 and 
>>>17.
>>
>>1,2,3 are marked as mandatory in the specification. It should be a 
>>community decision to revoke support for 1,2. If the community is 
>>ok, it will need additional code changes.
>
>tl;dr IPMI is old; let's drop the most insecure parts

While I am at it, can we agree that anonymous and nameless accounts are 
dangerous. I know that the IPMI spec says that having an account with no 
name is mandatory, I think this is another case of security trumps 
the standard.

I would at least like a way to disable this at build time so we CANNOT 
have this exploited.

--Vernon

>Opening this up to a wider audience. I would like some community 
>consensus on how we should deal with parts of specifications that 
>don't make sense anymore.
>
>Tables in section 13.28:
>(authentication algorithm support)
>00h: RAKP-none        Mandatory (recommend dropping support)
>01h: RAKP-HMAC-SHA1   Mandatory (good, but not best; keep for now)
>02h: RAKP-HMAC-MD5    Optional (not implemented; do not implement)
>03h: RAKP-HMAC-SHA256 Optional (implemented; best available)
>
>(integrity algorithm support)
>00h: none             Mandatory (recommend dropping support)
>01h: HMAC-SHA1-96     Mandatory (good, but not best; keep for now)
>02h: HMAC-MD5-128     Optional (not implemented; do not implement)
>03h: MD5-128          Optional (not implemented; do not implement)
>04h: HMAC-SHA256-128  Optional (implemented; best available)
>
>(confidentiality algorithm support)
>00h: none             Mandatory (recommend dropping support)
>01h: AES-CBC-128      Mandatory (implemented; best available)
>02h: xRC4-128         Optional (not implemented; do not implement)
>03h: xRC4-40          Optional (not implemented; do not implement)
>
>The IPMI spec was written in a time when computing resources were 
>minimal and before some of the real security awareness started. And as 
>such, it contains some legacy stuff that should really be dropped or 
>at the very least deprecated.
>
>The IPMI spec only says that we must implement certain authentication, 
>integrity, and confidentiality algorithms, it does not explicitly say 
>what cipher suites must be implemented. But, if we implement every 
>cipher suite that is available with the required algorithms, we would 
>implement cipher suites 0, 1, 2, and 3. And if we added in sha256 
>integrity and authentication, we add in 15, 16, and 17.
>
>Just for comparison, DCMI 1.5 requires only 3, with 17 as recommended 
>and 8 as optional. This is a step up from IPMI's security 
>recommendations, but still not best. I would say that 3 and 17 should 
>be required, with the recommendation that 3 be deprecated (or disabled 
>at runtime) in favor of 17 only.
>
>I think we can all agree that cipher suite 0 is poison. It is a gaping 
>open door with bright lights saying, "Hack me!" I would argue that 
>cipher suites 1 and 2 are not much better. We have the computing 
>resources to perform better security, so we should do it. As web 
>browsers move along, they deprecate and then disable old versions of 
>SSL/TLS. We should do the same. Just because at one point in history 
>it was fine to authenticate with plaintext passwords, does not mean we 
>should continue to do so. If you know better, do better.
>
>Even if end users come to us and say that they MUST have cipher suite 
>1 or 2, I would argue that we should tell them to update their 
>infrastructure rather than re-implement old insecure protocols.
>
>
>--Vernon

Re: Supporting insecure protocols in RMCP+

[Brad Bishop]

> On Apr 23, 2018, at 3:30 PM, Vernon Mauery <vernon.mauery@linux.intel.com> wrote:
> 
> On 23-Apr-2018 11:47 AM, Vernon Mauery wrote:
>>> Patch Set 4:
>>> 
>>>> Given that RMCP+ is already insecure, unless it is a requirement to support 1, 2, 15, and 16, you may just want to support 3 and 17.
>>> 
>>> 1,2,3 are marked as mandatory in the specification. It should be a community decision to revoke support for 1,2. If the community is ok, it will need additional code changes.
>> 
>> tl;dr IPMI is old; let's drop the most insecure parts
> 
> While I am at it, can we agree

I agree with all your points.  But why is consensus necessary?

> that anonymous and nameless accounts are dangerous. I know that the IPMI spec says that having an account with no name is mandatory, I think this is another case of security trumps the standard.
> 
> I would at least like a way to disable this at build time so we CANNOT have this exploited.

That sounds like a reasonable way to make the code do what you need.

> 
> --Vernon

Re: Supporting insecure protocols in RMCP+

[Brad Bishop]

> On Apr 23, 2018, at 2:47 PM, Vernon Mauery <vernon.mauery@linux.intel.com> wrote:
> 
>> Patch Set 4:
>> 
>>> Given that RMCP+ is already insecure, unless it is a requirement to support 1, 2, 15, and 16, you may just want to support 3 and 17.
>> 
>> 1,2,3 are marked as mandatory in the specification. It should be a community decision to revoke support for 1,2. If the community is ok, it will need additional code changes.
> 
> tl;dr IPMI is old; let's drop the most insecure parts
> 
> Opening this up to a wider audience. I would like some community consensus on how we should deal with parts of specifications that don't make sense anymore.
> 

I agree.

However, if someone came along and tried to add this back in
(proving that there is at least one user in the world),
I would let them (provided its opt-in behavior).

> Tables in section 13.28:
> (authentication algorithm support)
> 00h: RAKP-none        Mandatory (recommend dropping support)
> 01h: RAKP-HMAC-SHA1   Mandatory (good, but not best; keep for now)
> 02h: RAKP-HMAC-MD5    Optional (not implemented; do not implement)
> 03h: RAKP-HMAC-SHA256 Optional (implemented; best available)
> 
> (integrity algorithm support)
> 00h: none             Mandatory (recommend dropping support)
> 01h: HMAC-SHA1-96     Mandatory (good, but not best; keep for now)
> 02h: HMAC-MD5-128     Optional (not implemented; do not implement)
> 03h: MD5-128          Optional (not implemented; do not implement)
> 04h: HMAC-SHA256-128  Optional (implemented; best available)
> 
> (confidentiality algorithm support)
> 00h: none             Mandatory (recommend dropping support)
> 01h: AES-CBC-128      Mandatory (implemented; best available)
> 02h: xRC4-128         Optional (not implemented; do not implement)
> 03h: xRC4-40          Optional (not implemented; do not implement)
> 
> The IPMI spec was written in a time when computing resources were minimal and before some of the real security awareness started. And as such, it contains some legacy stuff that should really be dropped or at the very least deprecated.
> 
> The IPMI spec only says that we must implement certain authentication, integrity, and confidentiality algorithms, it does not explicitly say what cipher suites must be implemented. But, if we implement every cipher suite that is available with the required algorithms, we would implement cipher suites 0, 1, 2, and 3. And if we added in sha256 integrity and authentication, we add in 15, 16, and 17.
> 
> Just for comparison, DCMI 1.5 requires only 3, with 17 as recommended and 8 as optional. This is a step up from IPMI's security recommendations, but still not best. I would say that 3 and 17 should be required, with the recommendation that 3 be deprecated (or disabled at runtime) in favor of 17 only.
> 
> I think we can all agree that cipher suite 0 is poison. It is a gaping open door with bright lights saying, "Hack me!" I would argue that cipher suites 1 and 2 are not much better. We have the computing resources to perform better security, so we should do it. As web browsers move along, they deprecate and then disable old versions of SSL/TLS. We should do the same. Just because at one point in history it was fine to authenticate with plaintext passwords, does not mean we should continue to do so. If you know better, do better.
> 
> Even if end users come to us and say that they MUST have cipher suite 1 or 2, I would argue that we should tell them to update their infrastructure rather than re-implement old insecure protocols.
> 
> 
> --Vernon

Re: Supporting insecure protocols in RMCP+

[Vernon Mauery]

On 24-Apr-2018 09:17 AM, Brad Bishop wrote:
>
>> On Apr 23, 2018, at 3:30 PM, Vernon Mauery <vernon.mauery@linux.intel.com> wrote:
>>
>> On 23-Apr-2018 11:47 AM, Vernon Mauery wrote:
>>>> Patch Set 4:
>>>>
>>>>> Given that RMCP+ is already insecure, unless it is a requirement to support 1, 2, 15, and 16, you may just want to support 3 and 17.
>>>>
>>>> 1,2,3 are marked as mandatory in the specification. It should be a community decision to revoke support for 1,2. If the community is ok, it will need additional code changes.
>>>
>>> tl;dr IPMI is old; let's drop the most insecure parts
>>
>> While I am at it, can we agree
>
>I agree with all your points.  But why is consensus necessary?

Consensus is best when we are intentionally going against the IPMI 
standard. With IPMI, there may be several of these things where we might 
want to break the standard in order to provide better security. But I 
don't think we can do that unilaterally.

--Vernon

>> that anonymous and nameless accounts are dangerous. I know that the IPMI spec says that having an account with no name is mandatory, I think this is another case of security trumps the standard.
>>
>> I would at least like a way to disable this at build time so we CANNOT have this exploited.
>
>That sounds like a reasonable way to make the code do what you need.
>
>>
>> --Vernon

Re: Supporting insecure protocols in RMCP+

[Vernon Mauery]

On 24-Apr-2018 09:39 AM, Brad Bishop wrote:
>
>> On Apr 23, 2018, at 2:47 PM, Vernon Mauery <vernon.mauery@linux.intel.com> wrote:
>>
>>> Patch Set 4:
>>>
>>>> Given that RMCP+ is already insecure, unless it is a requirement to support 1, 2, 15, and 16, you may just want to support 3 and 17.
>>>
>>> 1,2,3 are marked as mandatory in the specification. It should be a community decision to revoke support for 1,2. If the community is ok, it will need additional code changes.
>>
>> tl;dr IPMI is old; let's drop the most insecure parts
>>
>> Opening this up to a wider audience. I would like some community consensus on how we should deal with parts of specifications that don't make sense anymore.
>>
>
>I agree.
>
>However, if someone came along and tried to add this back in
>(proving that there is at least one user in the world),
>I would let them (provided its opt-in behavior).

I would push back. Education is the fix, not less security. Call me an 
idealist. Even then, if they just could not live without it, it would 
have to be done in a way that it can be compiled out by default.

--Vernon

>> Tables in section 13.28:
>> (authentication algorithm support)
>> 00h: RAKP-none        Mandatory (recommend dropping support)
>> 01h: RAKP-HMAC-SHA1   Mandatory (good, but not best; keep for now)
>> 02h: RAKP-HMAC-MD5    Optional (not implemented; do not implement)
>> 03h: RAKP-HMAC-SHA256 Optional (implemented; best available)
>>
>> (integrity algorithm support)
>> 00h: none             Mandatory (recommend dropping support)
>> 01h: HMAC-SHA1-96     Mandatory (good, but not best; keep for now)
>> 02h: HMAC-MD5-128     Optional (not implemented; do not implement)
>> 03h: MD5-128          Optional (not implemented; do not implement)
>> 04h: HMAC-SHA256-128  Optional (implemented; best available)
>>
>> (confidentiality algorithm support)
>> 00h: none             Mandatory (recommend dropping support)
>> 01h: AES-CBC-128      Mandatory (implemented; best available)
>> 02h: xRC4-128         Optional (not implemented; do not implement)
>> 03h: xRC4-40          Optional (not implemented; do not implement)
>>
>> The IPMI spec was written in a time when computing resources were minimal and before some of the real security awareness started. And as such, it contains some legacy stuff that should really be dropped or at the very least deprecated.
>>
>> The IPMI spec only says that we must implement certain authentication, integrity, and confidentiality algorithms, it does not explicitly say what cipher suites must be implemented. But, if we implement every cipher suite that is available with the required algorithms, we would implement cipher suites 0, 1, 2, and 3. And if we added in sha256 integrity and authentication, we add in 15, 16, and 17.
>>
>> Just for comparison, DCMI 1.5 requires only 3, with 17 as recommended and 8 as optional. This is a step up from IPMI's security recommendations, but still not best. I would say that 3 and 17 should be required, with the recommendation that 3 be deprecated (or disabled at runtime) in favor of 17 only.
>>
>> I think we can all agree that cipher suite 0 is poison. It is a gaping open door with bright lights saying, "Hack me!" I would argue that cipher suites 1 and 2 are not much better. We have the computing resources to perform better security, so we should do it. As web browsers move along, they deprecate and then disable old versions of SSL/TLS. We should do the same. Just because at one point in history it was fine to authenticate with plaintext passwords, does not mean we should continue to do so. If you know better, do better.
>>
>> Even if end users come to us and say that they MUST have cipher suite 1 or 2, I would argue that we should tell them to update their infrastructure rather than re-implement old insecure protocols.
>>
>>
>> --Vernon

Re: Supporting insecure protocols in RMCP+

[Brad Bishop]

> On Apr 24, 2018, at 11:37 AM, Vernon Mauery <vernon.mauery@linux.intel.com> wrote:
> 
> On 24-Apr-2018 09:39 AM, Brad Bishop wrote:
>> 
>>> On Apr 23, 2018, at 2:47 PM, Vernon Mauery <vernon.mauery@linux.intel.com> wrote:
>>> 
>>>> Patch Set 4:
>>>> 
>>>>> Given that RMCP+ is already insecure, unless it is a requirement to support 1, 2, 15, and 16, you may just want to support 3 and 17.
>>>> 
>>>> 1,2,3 are marked as mandatory in the specification. It should be a community decision to revoke support for 1,2. If the community is ok, it will need additional code changes.
>>> 
>>> tl;dr IPMI is old; let's drop the most insecure parts
>>> 
>>> Opening this up to a wider audience. I would like some community consensus on how we should deal with parts of specifications that don't make sense anymore.
>>> 
>> 
>> I agree.
>> 
>> However, if someone came along and tried to add this back in
>> (proving that there is at least one user in the world),
>> I would let them (provided its opt-in behavior).
> 
> I would push back. 

Why?  What does the project (or anyone) have to gain by making it harder
for someone to use OpenBMC to meet their needs by requiring them to have
out-of-tree patches or forks?

> Education is the fix, not less security. 

The fix to what exactly?  Customer requirements?  Not everyone is willing
to say no to their customers.  I don’t think it is always (or even usually)
ignorance that leads to these kind of shortcuts.

> Call me an idealist.

And call me a pragmatic.  I think if you apply this mode of thinking too
often, there won’t be anyone left working on your code with you.  But hey,
at least it will be _impossible_ for anyone to ever use it in an insecure
manner.

> Even then, if they just could not live without it, it would have to be done in a way that it can be compiled out by default.

Of course this is reasonable.  There is a _huge_ difference between default
behavior and no choice in behavior.

> 
> --Vernon
> 
>>> Tables in section 13.28:
>>> (authentication algorithm support)
>>> 00h: RAKP-none        Mandatory (recommend dropping support)
>>> 01h: RAKP-HMAC-SHA1   Mandatory (good, but not best; keep for now)
>>> 02h: RAKP-HMAC-MD5    Optional (not implemented; do not implement)
>>> 03h: RAKP-HMAC-SHA256 Optional (implemented; best available)
>>> 
>>> (integrity algorithm support)
>>> 00h: none             Mandatory (recommend dropping support)
>>> 01h: HMAC-SHA1-96     Mandatory (good, but not best; keep for now)
>>> 02h: HMAC-MD5-128     Optional (not implemented; do not implement)
>>> 03h: MD5-128          Optional (not implemented; do not implement)
>>> 04h: HMAC-SHA256-128  Optional (implemented; best available)
>>> 
>>> (confidentiality algorithm support)
>>> 00h: none             Mandatory (recommend dropping support)
>>> 01h: AES-CBC-128      Mandatory (implemented; best available)
>>> 02h: xRC4-128         Optional (not implemented; do not implement)
>>> 03h: xRC4-40          Optional (not implemented; do not implement)
>>> 
>>> The IPMI spec was written in a time when computing resources were minimal and before some of the real security awareness started. And as such, it contains some legacy stuff that should really be dropped or at the very least deprecated.
>>> 
>>> The IPMI spec only says that we must implement certain authentication, integrity, and confidentiality algorithms, it does not explicitly say what cipher suites must be implemented. But, if we implement every cipher suite that is available with the required algorithms, we would implement cipher suites 0, 1, 2, and 3. And if we added in sha256 integrity and authentication, we add in 15, 16, and 17.
>>> 
>>> Just for comparison, DCMI 1.5 requires only 3, with 17 as recommended and 8 as optional. This is a step up from IPMI's security recommendations, but still not best. I would say that 3 and 17 should be required, with the recommendation that 3 be deprecated (or disabled at runtime) in favor of 17 only.
>>> 
>>> I think we can all agree that cipher suite 0 is poison. It is a gaping open door with bright lights saying, "Hack me!" I would argue that cipher suites 1 and 2 are not much better. We have the computing resources to perform better security, so we should do it. As web browsers move along, they deprecate and then disable old versions of SSL/TLS. We should do the same. Just because at one point in history it was fine to authenticate with plaintext passwords, does not mean we should continue to do so. If you know better, do better.
>>> 
>>> Even if end users come to us and say that they MUST have cipher suite 1 or 2, I would argue that we should tell them to update their infrastructure rather than re-implement old insecure protocols.
>>> 
>>> 
>>> --Vernon

Re: Supporting insecure protocols in RMCP+

[Brad Bishop]

> On Apr 24, 2018, at 11:34 AM, Vernon Mauery <vernon.mauery@linux.intel.com> wrote:
> 
> On 24-Apr-2018 09:17 AM, Brad Bishop wrote:
>> 
>>> On Apr 23, 2018, at 3:30 PM, Vernon Mauery <vernon.mauery@linux.intel.com> wrote:
>>> 
>>> On 23-Apr-2018 11:47 AM, Vernon Mauery wrote:
>>>>> Patch Set 4:
>>>>> 
>>>>>> Given that RMCP+ is already insecure, unless it is a requirement to support 1, 2, 15, and 16, you may just want to support 3 and 17.
>>>>> 
>>>>> 1,2,3 are marked as mandatory in the specification. It should be a community decision to revoke support for 1,2. If the community is ok, it will need additional code changes.
>>>> 
>>>> tl;dr IPMI is old; let's drop the most insecure parts
>>> 
>>> While I am at it, can we agree
>> 
>> I agree with all your points.  But why is consensus necessary?
> 
> Consensus is best when we are intentionally going against the IPMI standard.

This was a trick question.  I don’t think we should be limiting behaviors
in OpenBMC.  As in, if someone wants to comply to this part of the spec,
they should be able to do that.  If someone wants to skip this part of the
spec, they should also be able to do that.

If you accept that world-view, there isn’t anything left to find consensus
on other than which behavior is the default.

> With IPMI, there may be several of these things where we might want to break the standard in order to provide better security. But I don't think we can do that unilaterally.
> 
> --Vernon
> 
>>> that anonymous and nameless accounts are dangerous. I know that the IPMI spec says that having an account with no name is mandatory, I think this is another case of security trumps the standard.
>>> 
>>> I would at least like a way to disable this at build time so we CANNOT have this exploited.
>> 
>> That sounds like a reasonable way to make the code do what you need.
>> 
>>> 
>>> --Vernon

Re: Supporting insecure protocols in RMCP+

[Vernon Mauery]

On 24-Apr-2018 01:41 PM, Brad Bishop wrote:
>
>> On Apr 24, 2018, at 11:37 AM, Vernon Mauery <vernon.mauery@linux.intel.com> wrote:
>>
>> On 24-Apr-2018 09:39 AM, Brad Bishop wrote:
>>>
>>>> On Apr 23, 2018, at 2:47 PM, Vernon Mauery <vernon.mauery@linux.intel.com> wrote:
>>>>
>>>>> Patch Set 4:
>>>>>
>>>>>> Given that RMCP+ is already insecure, unless it is a requirement to support 1, 2, 15, and 16, you may just want to support 3 and 17.
>>>>>
>>>>> 1,2,3 are marked as mandatory in the specification. It should be a community decision to revoke support for 1,2. If the community is ok, it will need additional code changes.
>>>>
>>>> tl;dr IPMI is old; let's drop the most insecure parts
>>>>
>>>> Opening this up to a wider audience. I would like some community consensus on how we should deal with parts of specifications that don't make sense anymore.
>>>>
>>>
>>> I agree.
>>>
>>> However, if someone came along and tried to add this back in
>>> (proving that there is at least one user in the world),
>>> I would let them (provided its opt-in behavior).
>>
>> I would push back.
>
>Why?  What does the project (or anyone) have to gain by making it harder
>for someone to use OpenBMC to meet their needs by requiring them to have
>out-of-tree patches or forks?

Why would we want to support insecure protocols? This doesn't make any 
sense. We happily move on to the next version of web browser or openssl 
when a new vulnerability is found. Nobody would insist that we must 
support ROT13 as a symmetric cipher because they know it is nonsense.  
And thus my next point.

>> Education is the fix, not less security.
>
>The fix to what exactly?  Customer requirements?  Not everyone is willing
>to say no to their customers.  I don’t think it is always (or even usually)
>ignorance that leads to these kind of shortcuts.

Sometimes customers do need to understand that their requirements are 
unsafe. It is up to the engineers who understand the security 
implications that may not be obvious to the people who write the 
requirements.

>> Call me an idealist.
>
>And call me a pragmatic.  I think if you apply this mode of thinking too
>often, there won’t be anyone left working on your code with you.  But hey,
>at least it will be _impossible_ for anyone to ever use it in an insecure
>manner.

No, I don't believe that is true. People want quality and security. Now 
more than ever. No company wants their name in the headlines saying they 
suffered a security breach. The BMC is in that fray and OpenBMC needs to 
be at the front of the drive for secure coding and security standards. I 
want people to use OpenBMC because they can trust it.

>> Even then, if they just could not live without it, it would have to be done in a way that it can be compiled out by default.
>
>Of course this is reasonable.  There is a _huge_ difference between default
>behavior and no choice in behavior.

And yes, I would accept code that was compiled out by default if someone 
really needed it. But first, I would take the time to talk them off the 
edge first.

--Vernon

Re: Supporting insecure protocols in RMCP+

[Brad Bishop]

> On Apr 24, 2018, at 2:26 PM, Vernon Mauery <vernon.mauery@linux.intel.com> wrote:
> 
> On 24-Apr-2018 01:41 PM, Brad Bishop wrote:
>> 
>>> On Apr 24, 2018, at 11:37 AM, Vernon Mauery <vernon.mauery@linux.intel.com> wrote:
>>> 
>>> On 24-Apr-2018 09:39 AM, Brad Bishop wrote:
>>>> 
>>>>> On Apr 23, 2018, at 2:47 PM, Vernon Mauery <vernon.mauery@linux.intel.com> wrote:
>>>>> 
>>>>>> Patch Set 4:
>>>>>> 
>>>>>>> Given that RMCP+ is already insecure, unless it is a requirement to support 1, 2, 15, and 16, you may just want to support 3 and 17.
>>>>>> 
>>>>>> 1,2,3 are marked as mandatory in the specification. It should be a community decision to revoke support for 1,2. If the community is ok, it will need additional code changes.
>>>>> 
>>>>> tl;dr IPMI is old; let's drop the most insecure parts
>>>>> 
>>>>> Opening this up to a wider audience. I would like some community consensus on how we should deal with parts of specifications that don't make sense anymore.
>>>>> 
>>>> 
>>>> I agree.
>>>> 
>>>> However, if someone came along and tried to add this back in
>>>> (proving that there is at least one user in the world),
>>>> I would let them (provided its opt-in behavior).
>>> 
>>> I would push back.
>> 
>> Why?  What does the project (or anyone) have to gain by making it harder
>> for someone to use OpenBMC to meet their needs by requiring them to have
>> out-of-tree patches or forks?
> 
> Why would we want to support insecure protocols?

We wouldn’t.  I was trying to make a more general point.  Besides…whoever
wrote the code to enable those protocols would have to support it.  If they
didn’t, then it would get dropped from the tree by the maintainer, who is not
interested in maintaining or supporting those protocols.

> This doesn't make any sense. We happily move on to the next version of web browser or openssl when a new vulnerability is found. Nobody would insist that we must support ROT13 as a symmetric cipher because they know it is nonsense.  And thus my next point.
> 
>>> Education is the fix, not less security.
>> 
>> The fix to what exactly?  Customer requirements?  Not everyone is willing
>> to say no to their customers.  I don’t think it is always (or even usually)
>> ignorance that leads to these kind of shortcuts.
> 
> Sometimes customers do need to understand that their requirements are unsafe. It is up to the engineers who understand the security implications that may not be obvious to the people who write the requirements.
> 
>>> Call me an idealist.
>> 
>> And call me a pragmatic.  I think if you apply this mode of thinking too
>> often, there won’t be anyone left working on your code with you.  But hey,
>> at least it will be _impossible_ for anyone to ever use it in an insecure
>> manner.
> 
> No, I don't believe that is true. People want quality and security. Now more than ever. No company wants their name in the headlines saying they suffered a security breach.  The BMC is in that fray and OpenBMC needs to be at the front of the drive for secure coding and security standards.  I want people to use OpenBMC because they can trust it.
> 
>>> Even then, if they just could not live without it, it would have to be done in a way that it can be compiled out by default.
>> 
>> Of course this is reasonable.  There is a _huge_ difference between default
>> behavior and no choice in behavior.
> 
> And yes, I would accept code that was compiled out by default if someone really needed it. But first, I would take the time to talk them off the edge first.

Good!  This erases my fears.  Whenever there is talk about unilaterally not
allowing code to be upstreamed I get nervous.

> 
> --Vernon