Supporting insecure protocols in RMCP+

[Brad Bishop]

> On Apr 24, 2018, at 2:26 PM, Vernon Mauery <vernon.mauery at 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 at 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 at 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