On Tue, Dec 01, 2020 at 03:22:33PM -0000, Marco Trevisan (Treviño) wrote:
> > What if, for example, someone has an LDAP server that only supports
> > older TLS, and switching to OpenSSL causes their sssd LDAP TLS client to
> > require newer TLS because of our stronger defaults? What I describe
> > would result in a regression for that user until they reconfigure
> > things. Is this a realistic possibility?
> 
> First, are we sure that such scenario would currently work in current
> NSS?

I don't know. You tell me! I expect this to be considered and
investigated in advance of an SRU.

> I can't say whether that's a realistic scenario, we would need metrics,
> but I also think that if you're forcing a more secure behavior it's not
> to me a regression, it's making people aware that they're misbehaving.
> 
> As we do SRU a browser version that no longer accepts a deprecated
> crypto mechanisms, potentially causing an user regression, I don't see a
> problem in doing it other tools.

I agree that it may be reasonable in principle to bump up default
cryptosystem requirements during the lifetime of an LTS on security
grounds. However that decision should be made deliberately and carefully
as part of a security-driven review into the trade-offs between security
enhancement and user regression.

In the case of browsers, this review is done by upstreams and
distributions generally have no choice in the matter. In the case of
such a change being driven by Ubuntu, I'd expect the review to be driven
*by the security concern itself*, probably have input from the security
team, and for the proposed change to have a specific security-enhancing
goal.

Swapping out NSS for OpenSSL without analyzing these types changes, and
therefore possibly *accidentally* adjusting this type of configuration,
does not meet my expectations detailed above and in my opinion is
unacceptable.

You seem to be claiming that my example would enhance security, albeit
in a breaking way, and is thus acceptable. Without analyzing the
details, how do you know my example is the reality though? How do you
know it isn't regressing security in a breaking way?

> It may require an admin action? Yes, but that's acceptable IMHO when the system in use is known to be not secure.
> And IMHO we're responsible for that too, not just accept people to use unsafe methods by default.
> 
> > I think you're thinking of functional regressions here (ie. introducing
> > actual bugs), whereas I'm more bothered about regressing edge case user
> > configurations (eg. introducing a change that requires users to change
> > their local configurations to avoid a behavioural regression).
> 
> I'm thinking at those too (and especially in my scenario), but given
> there's right now no known actual and reported regression (not just in
> Ubuntu, but everywhere in the web I've searched for), so while there
> might be indeed edge cases until I don't have proofs of them I still
> thinking that the proposed change can only cause an improvement.

I disagree with your approach here. To land an SRU we are expected to
consider what regressions *might* occur, even if we don't specifically
have evidence about them. Lack of known and reported regressions does
not give us a free pass; in fact that's the exact opposite of documented
Ubuntu SRU policy.

We don't expect people to be perfect, but we do expect people to
have taken some reasonable effort to consider the potential regression
impact.

I expect the potential areas of regression I've identified to be
investigated and to be reported in this bug. I'm not saying they are
blockers; I'm saying that I don't know if they should be blockers, and I
think we should determine that with a reasonable documented
justification, and then proceed accordingly. I don't think it's
productive to be spending time arguing about about *whether*
investigation of potential regression is unnecessary.

> BTW, unrelated to this, but this request mostly is triggered by bug
> #1865226, and to support it reliably we need to use open-ssl based
> p11_child.

If, after having done a proper analysis, we decide that fixing that bug
is on balance worth the risk of regression as the least-worst option,
then we might decide to go ahead on that basis. We might even accept
some known use case regressions requiring users to reconfigure. But
without actually doing the investigation we aren't in a position to be
able to weigh it up.