Re: Supporting insecure protocols in RMCP+

[Vernon Mauery <vernon.mauery@linux.intel.com>]

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