Re: Suggestion to end support for legacy 1024-bit RSA root CAs in Fedora stable

[Kai Engert]

On Mon, 2016-08-22 at 07:40 -0400, Stephen Gallagher wrote:
> FESCo discussed this briefly on Friday. There was no formal vote, but the
> general sense was that you should just go ahead and do this as described above
> (immediately, so it lands in updates-testing ASAP and will be available by the
> time the Alpha ships).

Thanks!

commited
http://pkgs.fedoraproject.org/cgit/rpms/ca-certificates.git/commit/?h=f25=9c4ba05bc7552c5d4163760cc997b6021ac5a606

built
http://koji.fedoraproject.org/koji/taskinfo?taskID=15337856

and update submitted
https://bodhi.fedoraproject.org/updates/ca-certificates-2016.2.9-1.1.fc25

Kai
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Suggestion to end support for legacy 1024-bit RSA root CAs in Fedora stable

[Stephen Gallagher]

On 08/19/2016 09:54 AM, Kai Engert wrote:
> On Fri, 2016-08-19 at 09:45 -0400, Stephen Gallagher wrote:
>> However, pre-release Fedora is different from released Fedoras in that the
>> updates-testing repo is enabled by default on them. This means that if you
>> push
>> the ca-certificates package to updates-testing before next week's Go/No-Go
>> meeting, it is guaranteed that it will already be available to anyone doing a
>> dnf update from the moment they install the Alpha media. This makes it 
>> exactly
>> one update from inclusion on Alpha systems. It does not need to wait for a
>> stable push to get there.
> 
> Thank you for this detail.
> 
> In other words:
> - exclude this change from alpha to avoid all risks
> - create the alpha release, and after it's done:
> - build this change into f25 updates-testing
> - all F25 alpha users doing updates will get this change
>   immediately and will participate in testing it.
> 


FESCo discussed this briefly on Friday. There was no formal vote, but the
general sense was that you should just go ahead and do this as described above
(immediately, so it lands in updates-testing ASAP and will be available by the
time the Alpha ships).



signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Suggestion to end support for legacy 1024-bit RSA root CAs in Fedora stable

[Kevin Kofler]

Kai Engert wrote:
> I've just used f24 qupzilla to access a site with a relevant
> configuration. I'm using the suggested configuration on my system, and the
> site loads fine.
> 
> So apparently QT uses one of the fixed underlying libraries.

QupZilla is a bit special in that it uses QtWebEngine, which uses a weird 
combination of Google's custom OpenSSL fork ("BoringSSL") and the system 
NSS, where the latter is used only to find and load the system certificates, 
the actual SSL implementation is BoringSSL. (Chromium used to support using 
the system NSS for everything, but that support stopped working with the 
update to NSS 3.21, and their fix was to just make BoringSSL the default.) 
So it is good to know that it does the right thing, but most other Qt 
applications will use a very different code path.

That said, Qt normally uses OpenSSL, so it should just work.

Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Suggestion to end support for legacy 1024-bit RSA root CAs in Fedora stable

[Kai Engert]

On Fri, 2016-08-19 at 09:18 -0500, Michael Catanzaro wrote:
> On Fri, 2016-08-19 at 15:20 +0200, Kai Engert wrote:
> > 
> > It won't break software that uses NSS / OpenSSl / GnuTLS / glib-
> > networking.
> 
> I have only one concern: what about Qt stuff? Do you know?

I've just used f24 qupzilla to access a site with a relevant configuration.
I'm using the suggested configuration on my system, and the site loads fine.

So apparently QT uses one of the fixed underlying libraries.


> Anyway, I agree that you should prepare an F25 update for this. Just do
> not request a freeze exception, then it will be pushed to testing
> immediately after the alpha release.
> 
> I'm not sure I agree with pushing it to F23/F24 due to the risk of
> unexpected breakage -- you were CCed in [1] which was our chance to do
> that for F24 -- but it will probably work out fine
> 
> [1] https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.or
> g/thread/FTYLBKE5MU5E2OGD43G5HA7AXAZIKM7Q/#FTYLBKE5MU5E2OGD43G5HA7AXAZIKM7Q

I'm very sorry, but I had missed that thread. I blame bad folter filtering and
the large amount of emails. I've improved my filtering, to make sure I'll see
all emails I'm cc'ed on.

Kai
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Suggestion to end support for legacy 1024-bit RSA root CAs in Fedora stable

[Michael Catanzaro]

On Fri, 2016-08-19 at 15:20 +0200, Kai Engert wrote:
> It won't break software that uses NSS / OpenSSl / GnuTLS / glib-
> networking.

I have only one concern: what about Qt stuff? Do you know?

Anyway, I agree that you should prepare an F25 update for this. Just do
not request a freeze exception, then it will be pushed to testing
immediately after the alpha release.

I'm not sure I agree with pushing it to F23/F24 due to the risk of
unexpected breakage -- you were CCed in [1] which was our chance to do
that for F24 -- but it will probably work out fine

Michael

[1] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/FTYLBKE5MU5E2OGD43G5HA7AXAZIKM7Q/#FTYLBKE5MU5E2OGD43G5HA7AXAZIKM7Q
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Suggestion to end support for legacy 1024-bit RSA root CAs in Fedora stable

[Tomas Mraz]

On Pá, 2016-08-19 at 15:54 +0200, Kai Engert wrote:
> On Fri, 2016-08-19 at 09:45 -0400, Stephen Gallagher wrote:
> > 
> > However, pre-release Fedora is different from released Fedoras in
> > that the
> > updates-testing repo is enabled by default on them. This means that
> > if you
> > push
> > the ca-certificates package to updates-testing before next week's
> > Go/No-Go
> > meeting, it is guaranteed that it will already be available to
> > anyone doing a
> > dnf update from the moment they install the Alpha media. This makes
> > it exactly
> > one update from inclusion on Alpha systems. It does not need to
> > wait for a
> > stable push to get there.
> Thank you for this detail.
> 
> In other words:
> - exclude this change from alpha to avoid all risks
> - create the alpha release, and after it's done:
> - build this change into f25 updates-testing
> - all F25 alpha users doing updates will get this change
>   immediately and will participate in testing it.

+1 to this plan, except for one thing - you do not have to wait for
alpha to be released before you build and create the testing update. It
will not be inadvertently included into the alpha anyway. 

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
(You'll never know whether the road is wrong though.)


--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Suggestion to end support for legacy 1024-bit RSA root CAs in Fedora stable

[Kai Engert]

On Fri, 2016-08-19 at 09:05 -0400, Stephen Gallagher wrote:
> Applying this to older releases would be a violation of the Stable Updates
> Policy[1] (though arguably it could be considered to fall under "The update
> fixes a security issue that would affect a large number of users.".

Although I currently assume the change is safe for stable Fedoras, 
getting it into future stable releases such as Fedora 25 has a higher priority.

Instead of a fixed schedule for updating to F23/F24, here's a more conservative
suggestion:

We start a new thread on this devel list, and ask all developers who use F23/F24
in a stable environment, to perform the configuration that is equivalent to the
suggested package change (which is, to run the "ca-legacy disable" command), and
ask them to report any regressions they notice.

We could adjust our plans based on the feedback (or lack thereof) we'll get.

If everything seems to work fine, in a second step, we could broaden our call
for testing, by sending an equivalent message to a fedora users mailing list.

> That said, I'm not saying "don't allow this in F25", personally. I'm saying
> "don't try to land it in the middle of an already-slipped Freeze". That's a
> different situation. I don't want this to potentially cause us to slip another
> week.

Understood, thanks.

Kai
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Suggestion to end support for legacy 1024-bit RSA root CAs in Fedora stable

[Kai Engert]

On Fri, 2016-08-19 at 09:45 -0400, Stephen Gallagher wrote:
> However, pre-release Fedora is different from released Fedoras in that the
> updates-testing repo is enabled by default on them. This means that if you
> push
> the ca-certificates package to updates-testing before next week's Go/No-Go
> meeting, it is guaranteed that it will already be available to anyone doing a
> dnf update from the moment they install the Alpha media. This makes it exactly
> one update from inclusion on Alpha systems. It does not need to wait for a
> stable push to get there.

Thank you for this detail.

In other words:
- exclude this change from alpha to avoid all risks
- create the alpha release, and after it's done:
- build this change into f25 updates-testing
- all F25 alpha users doing updates will get this change
  immediately and will participate in testing it.

That sounds good to me.

Thanks
Kai
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Suggestion to end support for legacy 1024-bit RSA root CAs in Fedora stable

[Stephen Gallagher]

On 08/19/2016 09:20 AM, Kai Engert wrote:
> On Fri, 2016-08-19 at 09:01 -0400, Stephen Gallagher wrote:
>> With my FESCo hat on, I'd be in favor of landing this in updates-testing
>> immediately. Then folks who install the Alpha will get it in their first
>> update
>> and we'd have ample time to work out the issues prior to Beta.
> 
> If we agree to try to include it with Fedora 25, then both before Alpha and
> after Alpha are fine with me.
> 

So, I forgot to include some useful information about Fedora pre-releases. (I
have a bad habit of forgetting that not everyone knows all the little details).

What I am concerned about is *specifically* the frozen set of packages that
becomes part of the Alpha release. As we are already late for shipping that, I'm
opposed to increasing the set of things that *might* go wrong (even if the risk
is remote).

However, pre-release Fedora is different from released Fedoras in that the
updates-testing repo is enabled by default on them. This means that if you push
the ca-certificates package to updates-testing before next week's Go/No-Go
meeting, it is guaranteed that it will already be available to anyone doing a
dnf update from the moment they install the Alpha media. This makes it exactly
one update from inclusion on Alpha systems. It does not need to wait for a
stable push to get there.




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Suggestion to end support for legacy 1024-bit RSA root CAs in Fedora stable

[Kai Engert]

On Fri, 2016-08-19 at 15:20 +0200, Kai Engert wrote:
> It's not as simple as that. The suggested change doesn't mean that our
> software
> will block any CAs with 1024 bit.

This sentence wasn't sufficiently precise.

Although for some server certificates, it's possible to find a chain of trust to
one of the old 1024 bit roots, that doesn't mean that these server certificates
will be blocked.

Instead, our software has already been fixed to find the alternative chain of
trust to the replacement root CAs.

That means, despite no longer trusting these 1024 bit root CAs, all issued
certificates that are still intended to be valid, will be treated as valid by
our software, because it can find the path to the alternative, stronger root
CAs.
                        
server          intermediate                         / old 1024-bit root CA
certificate ->  CA certificate -> points to either  -
                                                     \ new stronger root CA

Kai
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Suggestion to end support for legacy 1024-bit RSA root CAs in Fedora stable

[Kai Engert]

On Fri, 2016-08-19 at 09:01 -0400, Stephen Gallagher wrote:
> > I'm having a hard time following the argument of scale and risk here
> > when it pertains to schedule slip.  The package itself is fairly
> > self-contained and isn't likely to cause issues against the actual
> > Alpha test criteria.  Can you elaborate why you think doing this as an
> > FE would cause a slip?
> > 
> 
> Essentially, it means that anything in Fedora using 1024 RSA root CAs would
> suddenly fail.

It's not as simple as that. The suggested change doesn't mean that our software
will block any CAs with 1024 bit.

I've explained the technical background in detail in the link to the openssl
ticket that can be found in my initial message of this thread.

The issue here is that whenever a server certificate needs to be verified, there
may be more than one potential chain of certificates to find a trusted root CA.

The CA organizations had planned to phase out their roots, and had implemented
mitigations already, when this project started two years ago.

In order to still work, software must be able to find alternative chains of
trust, to the newer replacement root CAs, which we already ship in our CA list.

Two years ago, OpenSSL and GnuTLS and glib-networking weren't able to find these
alternative trust chains, which was the only reason why we had decided to keep
trusting the old root CAs.

Meanwhile our software has been fixed, and those library now can find the
required alternative trust chains, and things work.

>  I don't have a clear picture of what exact tests are run, but I'd
> not be surprised to discover some of the Workstation browser tests to suddenly
> start failing as a result of this. That's not even including anyone who just
> starts poking around with it and filing bugs because their favorite website is
> no longer available.

Based on the work we've done, I don't think this will happen.

Our group has scanned a very large number of the most popular sites (Alexa). We
identified that there are still a very small number of sites that still use the
legacy configuration that was problematic with the older software versions, but
couldn't find issues with the SSL/TLS libraries I mentioned.

We have been preparing this, and have waited for quite a bit of time, before
this is now being suggested as a reasonable thing to do.


> Put another way: with my Blocker/FE reviewer hat on, I'd be inclined to vote
> this as too risky to grant an FE to, simply because we have no real way of
> knowing what it would break. I'd rather not jeopardize the already-slipped
> alpha for a late change with an unknown risk level.

It won't break software that uses NSS / OpenSSl / GnuTLS / glib-networking.

Sites that are trusted in a fresh Firefox profile will work with these other
software libraries, too.

Only sites that aren't trusted by Firefox might fail to be verified, but that's
exactly what we want to achieve, for security reasons, following the trust
decisions that have been made by the Mozilla CA maintainers, and which we want
to follow.


> With my FESCo hat on, I'd be in favor of landing this in updates-testing
> immediately. Then folks who install the Alpha will get it in their first
> update
> and we'd have ample time to work out the issues prior to Beta.

If we agree to try to include it with Fedora 25, then both before Alpha and
after Alpha are fine with me.

Thanks
Kai
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Suggestion to end support for legacy 1024-bit RSA root CAs in Fedora stable

[Kai Engert]

On Fri, 2016-08-19 at 14:54 +0200, Florian Weimer wrote:
> The plan is to apply this change to past releases, too.
> 
> I find this discrepancy—okay for past releases, but not okay for 
> alpha—somewhat puzzling.  I don't know which direction this should go, 
> but let's be consistent, please.

Given that this:
- doesn't have the risk of breaking the operating system,
- but only the small risk that some unidentified software we ship 
  might no longer be able to connect to a very small amount of servers, 

the alpha release seems like a good opportunity to me to allow for feedback from
users in testing environments.

If we'll get any feedback of nonworking connections, I assume it will be limited
to more exotic software that does SSL/TLS connections
(because OpenSSL + GnuTLS + NSS + glib-networking are known to have been fixed).

If we get any such feedback prior to shipping stable updates for Fedora 23 + 24,
it will give us the chance to work on changes to potentially affected software
(which we currently don't know if any such software exists).

I agree with Florian, if nobody is concerned with the idea to make the change
for stable F23/F24 updates, then we should include it as part of the final F25,
too, and earlier testing is better.

If it cannot become part of F25, then this cleanup would have to be postponed
until after the release of F25, for consistency.

Kai
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Suggestion to end support for legacy 1024-bit RSA root CAs in Fedora stable

[Stephen Gallagher]

On 08/19/2016 08:54 AM, Florian Weimer wrote:
> On 08/19/2016 02:38 PM, Stephen Gallagher wrote:
>> On 08/19/2016 08:29 AM, Kai Engert wrote:
>>> On Thu, 2016-08-18 at 22:29 -0400, Yaakov Selkowitz wrote:
 Beta sounds a bit late to be introducing such a change unilaterally.
 Should this not be going through FESCo at this point?
>>>
>>> Then I suggest that we make the change immediately for Fedora 25, to allow 
>>> it to
>>> be included in the delayed alpha release.
>>>
>>
>> It will absolutely not be accepted as a Freeze Exception. Changes of this 
>> scale
>> are far too high-risk and will almost certainly result in another schedule 
>> slip.
> 
> The plan is to apply this change to past releases, too.
> 
> I find this discrepancy—okay for past releases, but not okay for 
> alpha—somewhat
> puzzling.  I don't know which direction this should go, but let's be 
> consistent,
> please.



Applying this to older releases would be a violation of the Stable Updates
Policy[1] (though arguably it could be considered to fall under "The update
fixes a security issue that would affect a large number of users.".

That said, I'm not saying "don't allow this in F25", personally. I'm saying
"don't try to land it in the middle of an already-slipped Freeze". That's a
different situation. I don't want this to potentially cause us to slip another 
week.

[1] https://fedoraproject.org/wiki/Updates_Policy



signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Suggestion to end support for legacy 1024-bit RSA root CAs in Fedora stable

[Stephen Gallagher]

On 08/19/2016 08:46 AM, Josh Boyer wrote:
> On Fri, Aug 19, 2016 at 8:38 AM, Stephen Gallagher  
> wrote:
>> On 08/19/2016 08:29 AM, Kai Engert wrote:
>>> On Thu, 2016-08-18 at 22:29 -0400, Yaakov Selkowitz wrote:
 Beta sounds a bit late to be introducing such a change unilaterally.
 Should this not be going through FESCo at this point?
>>>
>>> Then I suggest that we make the change immediately for Fedora 25, to allow 
>>> it to
>>> be included in the delayed alpha release.
>>>
>>
>> It will absolutely not be accepted as a Freeze Exception. Changes of this 
>> scale
>> are far too high-risk and will almost certainly result in another schedule 
>> slip.
> 
> I'm having a hard time following the argument of scale and risk here
> when it pertains to schedule slip.  The package itself is fairly
> self-contained and isn't likely to cause issues against the actual
> Alpha test criteria.  Can you elaborate why you think doing this as an
> FE would cause a slip?
> 

Essentially, it means that anything in Fedora using 1024 RSA root CAs would
suddenly fail. I don't have a clear picture of what exact tests are run, but I'd
not be surprised to discover some of the Workstation browser tests to suddenly
start failing as a result of this. That's not even including anyone who just
starts poking around with it and filing bugs because their favorite website is
no longer available.


Put another way: with my Blocker/FE reviewer hat on, I'd be inclined to vote
this as too risky to grant an FE to, simply because we have no real way of
knowing what it would break. I'd rather not jeopardize the already-slipped alpha
for a late change with an unknown risk level.

With my FESCo hat on, I'd be in favor of landing this in updates-testing
immediately. Then folks who install the Alpha will get it in their first update
and we'd have ample time to work out the issues prior to Beta.




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Suggestion to end support for legacy 1024-bit RSA root CAs in Fedora stable

[Kai Engert]

On Fri, 2016-08-19 at 08:46 -0400, Josh Boyer wrote:
> On Fri, Aug 19, 2016 at 8:38 AM, Stephen Gallagher 
> wrote:
> > 
> > On 08/19/2016 08:29 AM, Kai Engert wrote:
> > > 
> > > On Thu, 2016-08-18 at 22:29 -0400, Yaakov Selkowitz wrote:
> > > > 
> > > > Beta sounds a bit late to be introducing such a change unilaterally.
> > > > Should this not be going through FESCo at this point?
> > > 
> > > Then I suggest that we make the change immediately for Fedora 25, to allow
> > > it to
> > > be included in the delayed alpha release.
> > > 
> > 
> > It will absolutely not be accepted as a Freeze Exception. Changes of this
> > scale
> > are far too high-risk and will almost certainly result in another schedule
> > slip.
> 
> I'm having a hard time following the argument of scale and risk here
> when it pertains to schedule slip.  The package itself is fairly
> self-contained and isn't likely to cause issues against the actual
> Alpha test criteria.  Can you elaborate why you think doing this as an
> FE would cause a slip?


I've filed a FESCo ticket, asking for approval for this change in Fedora:
https://fedorahosted.org/fesco/ticket/1616

The suggested change is limited to modify static lists.
It will change two existing configuration choices to have identical effect.

The only risk is that potentially, we find software that can no longer connect
to a very small amount of Internet sites (because the site's certificates
requires one of the legacy CAs to be trusted).

That risk is very small, and doesn't affect the stability of the Fedora OS.

Kai
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Suggestion to end support for legacy 1024-bit RSA root CAs in Fedora stable

[Florian Weimer]

On 08/19/2016 02:38 PM, Stephen Gallagher wrote:

On 08/19/2016 08:29 AM, Kai Engert wrote:

On Thu, 2016-08-18 at 22:29 -0400, Yaakov Selkowitz wrote:

Beta sounds a bit late to be introducing such a change unilaterally.
Should this not be going through FESCo at this point?


Then I suggest that we make the change immediately for Fedora 25, to allow it to
be included in the delayed alpha release.



It will absolutely not be accepted as a Freeze Exception. Changes of this scale
are far too high-risk and will almost certainly result in another schedule slip.


The plan is to apply this change to past releases, too.

I find this discrepancy—okay for past releases, but not okay for 
alpha—somewhat puzzling.  I don't know which direction this should go, 
but let's be consistent, please.


Thanks,
Florian
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Suggestion to end support for legacy 1024-bit RSA root CAs in Fedora stable

[Josh Boyer]

On Fri, Aug 19, 2016 at 8:38 AM, Stephen Gallagher  wrote:
> On 08/19/2016 08:29 AM, Kai Engert wrote:
>> On Thu, 2016-08-18 at 22:29 -0400, Yaakov Selkowitz wrote:
>>> Beta sounds a bit late to be introducing such a change unilaterally.
>>> Should this not be going through FESCo at this point?
>>
>> Then I suggest that we make the change immediately for Fedora 25, to allow 
>> it to
>> be included in the delayed alpha release.
>>
>
> It will absolutely not be accepted as a Freeze Exception. Changes of this 
> scale
> are far too high-risk and will almost certainly result in another schedule 
> slip.

I'm having a hard time following the argument of scale and risk here
when it pertains to schedule slip.  The package itself is fairly
self-contained and isn't likely to cause issues against the actual
Alpha test criteria.  Can you elaborate why you think doing this as an
FE would cause a slip?

josh
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Suggestion to end support for legacy 1024-bit RSA root CAs in Fedora stable

[Stephen Gallagher]

On 08/19/2016 08:29 AM, Kai Engert wrote:
> On Thu, 2016-08-18 at 22:29 -0400, Yaakov Selkowitz wrote:
>> Beta sounds a bit late to be introducing such a change unilaterally.
>> Should this not be going through FESCo at this point?
> 
> Then I suggest that we make the change immediately for Fedora 25, to allow it 
> to
> be included in the delayed alpha release.
> 

It will absolutely not be accepted as a Freeze Exception. Changes of this scale
are far too high-risk and will almost certainly result in another schedule slip.

Please bring it to FESCo for consideration for it go into updates-testing and to
land once Alpha Freeze ends.




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Suggestion to end support for legacy 1024-bit RSA root CAs in Fedora stable

[Kai Engert]

On Thu, 2016-08-18 at 22:29 -0400, Yaakov Selkowitz wrote:
> Beta sounds a bit late to be introducing such a change unilaterally.
> Should this not be going through FESCo at this point?

Then I suggest that we make the change immediately for Fedora 25, to allow it to
be included in the delayed alpha release.

Kai
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Suggestion to end support for legacy 1024-bit RSA root CAs in Fedora stable

[Yaakov Selkowitz]

On Tue, 2016-08-16 at 15:23 +0200, Kai Engert wrote:
> On Mon, 2016-08-15 at 22:19 +0200, Kai Engert wrote:
> > 
> > Unless we find good reasons not to do it, I suggest to push the
> > legacy
> > removals
> > to stable around 2016-09-21.
> 
> I just noticed that the Fedora 25 beta freeze is scheduled for 2016-
> 09-20.
> 
> I think it would be good to have the change included in Fedora 25 by
> default, so
> I'd like to push it to a f25 stable update one week earlier, around
> 2016-09-14.

Beta sounds a bit late to be introducing such a change unilaterally.
 Should this not be going through FESCo at this point?

-- 
Yaakov Selkowitz
Software Engineer - Platform Enablement Group
Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Suggestion to end support for legacy 1024-bit RSA root CAs in Fedora stable

[Kai Engert]

On Mon, 2016-08-15 at 22:19 +0200, Kai Engert wrote:
> Unless we find good reasons not to do it, I suggest to push the legacy
> removals
> to stable around 2016-09-21.

I just noticed that the Fedora 25 beta freeze is scheduled for 2016-09-20.

I think it would be good to have the change included in Fedora 25 by default, so
I'd like to push it to a f25 stable update one week earlier, around 2016-09-14.

Kai
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Suggestion to end support for legacy 1024-bit RSA root CAs in Fedora stable

[Kai Engert]

You may remember Mozilla's initiative from 2014 to remove those root CAs from
the CA trust store that use RSA keys of a weaker 1024-bit size.
The topic has been previously discussed on this list [1].

Because of past limitations with both OpenSSL [2] and GnuTLS, and to ensure
their compatibility with most security SSL/TLS sites until their limitations
could be removed, we had decided to delay the removal of the root CA trust from
Fedora. We called that legacy trust, the legacy trust was set to enabled as the
default configuration, and we had introduced the ca-legacy utility [3] to allow
an administrator to configure their preference between a "default" setting
(higher compatibility) and "disable" (less compatibility, strictly following
Mozilla's decisions), and we documented our changes over time to Mozilla's list
[4].

Mozilla upstream has completed the removal of SSL/TLS trust for all such root
CAs, the last removal had happened in late 2015.

(... although some of the root CAs are still trusted for email security
certificates, this is why the legacy tool doesn't simply add or remove CAs, but
it switches between two different sets of trust flags.)

As a result, operators of web sites had time to learn about broken sites, and
it's likely that most sites have been fixed.

Therefore it's time to follow up. In the meantime, both GnuTLS and OpenSSL have
been fixed, and the versions we ship in stable Fedora can handle the problematic
scenarios correctly.

I'm not aware of SSL/TLS sites that are trusted in a fresh Firefox profile, but
which aren't trusted by openssl s_client or gnutls-cli when the system is
configured with ca-legacy disable. (Thanks a lot to Hubert Kario for performing
web scans of a large set of major web sites, that provided helpful data.)

Therefore I suggest that we attempt to remove all legacy trust flags in an
update to the ca-certificates.rpm package very soon. (More specifically, I
suggest that the legacy list is changed to be empty, with the result that both
legacy configurations "default" and "disable" will have the identical state.)

An update to the ca-certificates set version 2016.2.9 (as of NSS 3.26) is
currently pending (which adds trust for the ISRG / Let's Encrypt root CA). I'd
like to push that one to stable updates first.

Immediately afterwards, I'd like to submit a follow-up release, that removes the
legacy trust flags, and push that to testing on all currently maintained Fedora
branches.

I'd like to disable auto-karma for the legacy CA removal, and allow a few weeks
to wait for feedback.

Unless we find good reasons not to do it, I suggest to push the legacy removals
to stable around 2016-09-21.

Please let me know if you any questions or concerns.

Kai

[1] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/OCQ5LTMJFT4A366TBSPXWWROV7WCJV5J/
[2] https://rt.openssl.org/Ticket/Display.html?id=3621#txn-4
[3] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4NZLWGVXCGUROHT535R7PTRQJKHILSWW/
[4] https://fedoraproject.org/wiki/CA-Certificates
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=1156844
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org