Re: Security Working Group meeting - this Wednesday February 19 - summary results

[Michael Richardson <mcr@sandelman.ca>]

[-- Attachment #1.1: Type: text/plain, Size: 3755 bytes --]


Alexander Tereschenko <aleksandr.v.tereschenko@linux.intel.com> wrote:
    >> James Feist <james.feist@linux.intel.com> wrote: > I think the
    >> original motivation of 10 years was something above the average >
    >> support cycle of a server, so on first boot the user has something
    >> they can > use to login to the server with.
    >>
    mcr> That's not a crazy consideration to me.

    > James, do you imply that the certificate would be generated during
    > server manufacturing, not at the first boot at the "end owner's"
    > premise?  If so, that indeed changes the perspective, I personally and
    > I think everyone in our discussion during the meeting thought of the
    > generation as happening at the latter moment, not the former.

Looking at the mechanism, it would seem that the certificate would be
generated upon first power on after the BMC was flashed.  If the VAR receives
the machine (or the shipping dock receiver), powers it on to make sure it's
not a dud, and ships it/puts-it-into-inventory, then the  30-day timer starts
then.

That's why 30 days is too short.
(If the manufacturer can put a proper IDevID into the BMC, that would be
better all around)

    mcr> 1) it would be good to clarify what browsers are really going to do.

    > Indeed - especially given that the recommendation mentioned [1] is a
    > CA-side one (used for _issuing_ certs) and the respective RFC section
    > for X.509 [2] is unchanged - so I'd expect browsers to continue
    > sticking to that. Unless, of course, someone decides to go the "let's
    > make it more secure for people based on that CA/Browser forum
    > recommendation" way and adds some logic that would do
    > otherwise...

I believe that the browsers will do this, because the CAFORUM rules would be
meaningless of nobody checked :-)

    > However imagine how would that look like - the browser is
    > at the receiving end (i.e. browser's user typically has no control over
    > the cert), what does it do when getting such a cert? Throw a warning
    > like "this server's certificate is valid for more than two years,
    > beware" or something? That's bad UX, [very likely] can't be acted upon
    > by the user anyway and actually FUD - the certificate is perfectly
    > valid.

The warning boxes are going away as fast the browser people can convince
people like us to do something different.

I have sent some emails to some contacts at Chrome and Firefox that deal with
CAForum questions, and I hope to get some guidance.

    > I was more concerned with the general fact that the self-signed cert we
    > generate doesn't provide full protection and what _gentle_ nudges could
    > be used for them to change that. In that context those 30 days looked
    > ok (don't break anything, but provide additional warning for an admin).

    > BTW, that MiTM may not only be happening at the network level -
    > e.g. admin's computer may be compromised and some process there could
    > MitM the connections without tapping the network infra proper.

Sure, there are about a hundred other issues that could occur.
The admin's out-of-warantee windows-XP desktop can be removed from the
equation if the enterprise has some automation, so let's just assume that
the other end is secure, okay?

    > All in all, it actually sounds to me like we may as well be not doing
    > anything here :) If admin's threat model allows for using the
    > self-generated self-signed cert, early expiration may be worse UX than
    > today - and if the threat model doesn't allow for that, the cert will
    > be replaced anyway.

+1
Changing from 10 years to 825 days is probably an acceptable move.
Maybe it should be a yocto-build-time configuration option.


[-- Attachment #1.2: Signature --]
[-- Type: text/plain, Size: 243 bytes --]

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [




[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]