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

[Alexander Tereschenko]

> James Feist <james.feist at 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.
>
> 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.

>      > That being said, if the browser wont let you
>      > in, that is obviously more important. 30 days seems a bit too strict
>      > considering shipping / unpacking times make it likely you'll have an expired
>      > certificate upon arrival. But if we can't come to an agreement, we can always
>      > make this configurable.
>
> 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... 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.

So if you want my guess, I think browsers won't do a thing about that 
and that recommendation will be enforced at the CA level only, so it is 
unlikely to affect OpenBMC users at the end of the day.

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.

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] https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.7.pdf

[2] https://tools.ietf.org/html/rfc5280#section-4.1.2.5