Re: Crypto / PSM work for FF 2
Mike Beltzner
On 7-Apr-06, at 2:35 PM, Mike Beltzner wrote:
> On 7-Apr-06, at 1:57 PM, Kai Engert wrote:
>
>> Disable weak SSL (bug 236933): This is done on both trunk and 1.8
>> branch. UI has been removed. Weak ciphers and SSL 2 are now
>> disabled by default.
>
> This piece is represented in the requirements and planning
> documentation already, and is part of A2. Hurrah!
>
>> OCSP over Proxy (bug 111384): The change finally landed on the
>> trunk two days ago. So far I am not aware of regressions. Unless
>> we get problem reports, I would like to propose to check this in
>> to the 1.8 branch mid next week. The change is isolated to mozilla/
>> security/manager, no changes to Necko have been necessary.
>> (However, in addition the mailnews code needs a change, available
>> in bug 329990.)
>
> This piece seems to me to fall into the "platform uplift" piece
> which encapsulates the bits of the trunk platform which we want to
> see hit Fx2. I think Shaver's managing that right now, so I'll poke
> him about this at the next Bon Echo meeting if not before. Seems
> like it's the right sort of candidate, though.
>
>> So I think the deadline for checking everything should be either
>> "before Beta 1" or "before Alpha 2".
>> Please advise what you feel is the right one.
>> Based on the deadline you recommend, we'll either land in time, or
>> the feature will be out.
>
> As mconnor noted, if it's a new feature, we need it to land as part
> of an alpha, and the last scheduled alpha is A2 which is targeted
> at early May at this point in time. I think we need to get this
> requirement on the books as part of the SSL piece and prioritize it
> accordingly. In the meantime, please work out your estimates to see
> if you can land it for the end of the first week of May, and let us
> know if that's feasible.
>
> cheers,
> mike
Kai's replies:
> This piece seems to me to fall into the "platform uplift" piece
> which encapsulates the bits of the trunk platform which we want to
> see hit Fx2. I think Shaver's managing that right now, so I'll poke
> him about this at the next Bon Echo meeting if not before. Seems
> like it's the right sort of candidate, though.
>
Thanks!
> As mconnor noted, if it's a new feature, we need it to land as part
> of an alpha, and the last scheduled alpha is A2 which is targeted
> at early May at this point in time.
>
Understood, we'll try.
Thanks!
Kai
Mike Connor wrote:
> On 7-Apr-06, at 1:57 PM, Kai Engert wrote:
>
>> The only API addition is to a rarely used JS function.
>>
> Which function would this be?
>
http://developer.mozilla.org/en/docs/generateCRMFRequest
https://bugzilla.mozilla.org/show_bug.cgi?id=326159#c6
>> So I think the deadline for checking everything should be either
>> "before Beta 1" or "before Alpha 2".
>> Please advise what you feel is the right one.
>> Based on the deadline you recommend, we'll either land in time, or
>> the feature will be out.
>>
> We would want to see this land for alpha2 and take fixes if
> necessary. [...] Beta1 is just too late [...]
>
Ok, that's fine. We'll try to get it in in time.
Thanks!
Kai
Mike Beltzner
>> As mconnor noted, if it's a new feature, we need it to land as
>> part of an alpha, and the last scheduled alpha is A2 which is
>> targeted at early May at this point in time.
> Understood, we'll try.
OK, I've added this as a tentative requirement (pending approval at
the next Bon Echo meeting) to the security requirements, targeted as
a P3 for Alpha2.
cheers,
mike
Mike Beltzner
I know that the OSCP work has landed on the 1.8.1 branch, but was
wondering if there was any update on the ECC piece (is that being
tracked by https://bugzilla.mozilla.org/show_bug.cgi?id=326159 or are
there other bugs to be using to track this?)
cheers,
mike
On 7-Apr-06, at 1:57 PM, Kai Engert wrote:
> Mike Connor wrote:
>> Kai Engert wrote:
>>> the NSS and PSM developers would like to propose that the
>>> following items be included in the Firefox and Thunderbird 2.0
>>> releases. We are working on these topics with a high priority.
>>>
>>> *Support OCSP via Proxy*
>>> *Disable weak SSL*
>>> *Enable a new generation of crypto ciphers*
>> What is the expected timeline for these three items? OCSP via
>> Proxy seems to be gated on reviews, disable weak SSL is largely
>> done, but the new ciphers have an unspecified timeline. It's very
>> hard to add something to the list if we don't know where it
>> impacts the timeline and our testing resources.
> At the time you asked that question, I did not have an answer, but
> now I'm able to give details. I hope it's not too late.
>
> Disable weak SSL (bug 236933): This is done on both trunk and 1.8
> branch. UI has been removed. Weak ciphers and SSL 2 are now
> disabled by default.
>
> OCSP over Proxy (bug 111384): The change finally landed on the
> trunk two days ago. So far I am not aware of regressions. Unless we
> get problem reports, I would like to propose to check this in to
> the 1.8 branch mid next week. The change is isolated to mozilla/
> security/manager, no changes to Necko have been necessary.
> (However, in addition the mailnews code needs a change, available
> in bug 329990.)
>
> In the rest of this message I'd like to give more details about New
> ciphers (ECC) for SSL/TLS.
>
> Mozilla application level coding is mostly complete.
> There are some limited changes required in mozilla/security/
> manager, as available in bugs 235773 and 326159.
> The patches are less than 1000 lines in total and have been
> reviewed already.
>
> It does not involve any obvious UI changes to Firefox/Thunderbird.
> We add some status strings.
> We change the text displayed on an HTML page that contains the
> <KEYGEN> tag.
> We extend JavaScript API crypto.generateCRMFRequest to accept new
> parameter values.
>
> From my point of view, the above changes are done and nearly ready
> for checkin.
> However, I won't check in unless the crypto backend NSS is ready, too.
>
> And we won't check in / enable ECC, unless the NSS developers are
> releasing an official snapshot that is safe for client side ECC
> crypto from their perspective. Such a snapshot would be off the NSS
> 3.11 branch. (Firefox 1.8 branch is already using an earlier
> snapshot of NSS from that branch.)
>
> Independently of official Firefox development, we have been
> producing engineering builds of Firefox MOZILLA_1_8_BRANCH with
> NSS_3_11_BRANCH, the mentioned PSM patches and ECC enabled.
>
> These engineering builds are being tested by QA, as part of an
> effort between multiple software vendors that strive to verify the
> interoperability of EC crypto between browser and server software
> vendors.
>
> I'm giving this explanation, because I'd like to make it clear that
> this code will have reached a level of quality already, at the time
> we check it in, because it will have gone through a lot of QA.
>
> Based on the condition, that we won't check in unless we feel
> certain the new EC crypto meets the desired quality standard, what
> should be the deadline for checking it in?
>
> The new ECC ability will not require any IDL changes. The only API
> addition is to a rarely used JS function.
>
> So I think the deadline for checking everything should be either
> "before Beta 1" or "before Alpha 2".
> Please advise what you feel is the right one.
> Based on the deadline you recommend, we'll either land in time, or
> the feature will be out.
>
> Note that another browser vendor is working on including the ECC
> feature in its next major release, too, so it would be good to have
> parity.
>
> Thanks a lot,
> Kai
>
Kai Engert
thanks for asking.
We are optimistic and plan to check in and enable ECC for SSL/TLS either
later today or sometime Tuesday.
However, we are working through one last issue before we can land.
The check in will include an official NSS snapshot provided by the NSS
developers.
The required PSM changes are being tracked in
https://bugzilla.mozilla.org/show_bug.cgi?id=235773
After testing to make sure we have not caused any regressions, we'd like
to make the same change to the FF2.0 branch. You had initially mentioned
the deadline for landing is end of first week of May. Is that still
true? We should be able to land by then.
Thanks a lot,
Kai
PS: We want to postpone landing 326159 to a future release.
>> mozilla/security/manager, no changes to Necko have been necessary.
Mike Beltzner
> We are optimistic and plan to check in and enable ECC for SSL/TLS either
> later today or sometime Tuesday.
> However, we are working through one last issue before we can land.
Excellent. I appreciate the extra effort to ensure that you're
squashing regressions before landing it on the branch. Sounds like
this work is well in hand.
> The check in will include an official NSS snapshot provided by the NSS
> developers.
> The required PSM changes are being tracked in
> https://bugzilla.mozilla.org/show_bug.cgi?id=235773
>
> After testing to make sure we have not caused any regressions, we'd like
> to make the same change to the FF2.0 branch. You had initially mentioned
> the deadline for landing is end of first week of May. Is that still
> true? We should be able to land by then.
Code freeze is currently on schedule for Friday May 5th, yes.
cheers,
mike
--
/ mike beltzner / user experience lead / mozilla corporation /
Bob Lord
weekly interop conference calls with Microsoft and Sun since December.
That cross-company team has been working to code up the requirements of
the draft TLS/ECC RFC. Along the way, we've found numerous problems
with the draft, and with the different vendor's implementations. Those
issues have been resolved. When we release this addition to Firefox's
TLS capabilities, Firefox will interoperate with Vista servers, Red Hat
servers, and Sun servers. Other vendors are starting to participate in
this forum, and we hope we have lowered the amount of work for them to
correctly implement ECC in their servers by having produced a very clear
RFC, with several functional implementations.
-Bob
Mike Connor
is being worked on, or am I just missing random things again?) Off
the top of my head, the notificationbox widget should be called out
to developers, especially for people who may have been using
browsermessage or would use this for other content aside from
tabbrowser.
-- Mike
On 29-Apr-06, at 3:47 PM, Mike Shaver wrote:
> That's really cool to hear. If there's something that developers
> should know about how to take advantage of the new ECC features
> (esp. from the client side), let's make sure the details make it
> into our upcoming "Firefox 2 for developers" guide, too.
>
> Mike
Bob Lord
browser connects to an ECC-enabled server, and if the client and server
can negotiate a shared ciphersuite and curve, it will just work. It will
be just another TLS connection. Nothing to see here. Move along.
Interesting side note: the ECC curves we're using are authorized for
both non-classified traffic, and also for some classified traffic. See
http://www.nsa.gov/ia/industry/crypto_elliptic_curve.cfm for more
information.
*Question*: we have an ECC test server set up here at Red Hat
(http://ecc.fedora.redhat.com/). There's also one at Microsoft and
another at Sun. However each of these machines is a shared resource,
and will melt under heavy load. Is there a way Mozilla could host some
servers with this code? It's just Apache with mod_NSS instead of
OpenSSL. (see http://ecc.fedora.redhat.com/install.html)
If that's an option, please let me know who the right point of contact
would be. I'll ask Rob Crittenden from Red Hat to lead the effort from
our side.
As always, thanks for your support.
-Bob
Philip Chee
<apparently nothing>
Why do I have to use CTRL-U (view source) in order to read this message?
Does Bob have a misconfigured nntpclient?
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]What if there were no hypothetical questions?
* TagZilla 0.059
Frank Wein
> On 30/04/2006 04:21, Bob Lord wrote:
>
> <apparently nothing>
>
> Why do I have to use CTRL-U (view source) in order to read this message?
> Does Bob have a misconfigured nntpclient?
>
> Phil
Good question, maybe it has to do with this:
"This is a cryptographically signed message in MIME format."
I do not see any part of a S/MIME signature in source, maybe the filter
at the mailing list removed this "attachment" from the message and this
confuses Thunderbird/Mozilla/SeaMonkey/etc.? A evidence for this is the
"X-Content-Filtered-By: Mailman/MimeDel 2.1.5" header in his mail, this
header is not present in other mails that go through the Mail->News
gateway. news://news.mozilla.org/240420061012102082%just...@mozilla.com
says messages with attachments should get bounced so and not silently be
modified (as in removing attachments).
Frank
Mike Shaver
> I do not see any part of a S/MIME signature in source, maybe the filter
> at the mailing list removed this "attachment" from the message and this
> confuses Thunderbird/Mozilla/SeaMonkey/etc.? A evidence for this is the
> "X-Content-Filtered-By: Mailman/MimeDel 2.1.5" header in his mail, this
> header is not present in other mails that go through the Mail->News
> gateway. news://news.mozilla.org/240420061012102082%just...@mozilla.com
> says messages with attachments should get bounced so and not silently be
> modified (as in removing attachments).
Yeah, please file that (and cc: me). If we preserve the S/MIME stuff
correctly -- and we should, since our product produces it! -- then
even people using gmail and google groups can verify the signatures
and such (with the help of the clever extension).
Mike
Mike Beltzner
> We are optimistic and plan to check in and enable ECC for SSL/TLS either
> later today or sometime Tuesday.
> However, we are working through one last issue before we can land.
>
> developers.
> The required PSM changes are being tracked in
> https://bugzilla.mozilla.org/show_bug.cgi?id=235773
Taking a look at that bug, I see where the checkout got branch
approval, but see no indication of it having landed. Am I right in
thinking that this patch didn't make it onto the branch?
It will be disappointing if it wasn't able to make it. I'd really
rather see something like this get into an alpha.