Re: Announcing Mozilla::PKIX, a New Certificate Verification Library

2014-04-25 Thread Zack Weinberg
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/25/2014 09:59 AM, Erwann Abalea wrote: Le vendredi 25 avril 2014 13:46:51 UTC+2, Martin Paljak a écrit : What is the rationale for this: 4. Mozilla::pkix performs chaining based on issuer name alone, and does not require that issuer's

Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers

2013-08-21 Thread Zack Weinberg
On 2013-08-19 2:06 PM, Kurt Roeckx wrote: I understand that GCM is faster, but the implementations might have side channel attacks. So I'm not sure if GCM or CBC is better, but we should probably prefer GCM or CBC. GCM is (AIUI) preferred because it's immune to BEAST. I share concern about

Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers

2013-08-21 Thread Zack Weinberg
On 2013-08-20 2:33 PM, Tom Ritter wrote: On 20 August 2013 14:26, Gervase Markham g...@mozilla.org wrote: On 19/08/13 04:07, Brian Smith wrote: When risk is there to a user of having a network eavesdropper able to tell that they are using a particular browser? If I had an exploit for a

IETF standardization of SSL authentication via DNS nearing completion -- please critique

2012-02-29 Thread Zack Weinberg
The IETF has a working group developing a standard for new DNS records that let a zone admin declare the public key(s) belonging to SSL servers in that zone; this can be used as a complement to the existing CA infrastructure, or instead of that infrastructure. The specification is in WG Last

Re: Proposal: implement a MITM report addon

2011-06-28 Thread Zack Weinberg
On 2011-06-28 4:00 AM, Kai Engert wrote: Hi Ralph, if you have resources to work on this or to coordinate this, please go ahead. I haven't yet. If I should, I would contact you to coordinate. Regarding traceroute, you could look at the existing WorldIP Add-On, which claims to support it, and

Re: Proposal: implement a MITM report addon

2011-06-28 Thread Zack Weinberg
On 2011-06-28 7:45 AM, Zack Weinberg wrote: On 2011-06-28 4:00 AM, Kai Engert wrote: Hi Ralph, if you have resources to work on this or to coordinate this, please go ahead. I haven't yet. If I should, I would contact you to coordinate. Regarding traceroute, you could look at the existing

Re: TLS server keys in DNS: client policy proposal

2011-02-06 Thread Zack Weinberg
On 02/05/2011 02:55 PM, Eddy Nigg wrote: However probably the optimal approach will be CA issued certs in DNS that also make use of DNSSEC to validate the former (DV). Eventually I believe that this will emerge as the real improvement and most useful approach for software vendors and CAs alike

Re: TLS server keys in DNS: client policy proposal

2011-02-05 Thread Zack Weinberg
On 2011-02-05 1:13 PM, Nelson B Bolyard wrote: Zack, thanks for bringing this to this list/group. I think many of us were caught by surprise by it, because it is a browser policy proposal rather than a technical discussion of the protocols. Personally, I was a little surprised to be asked to

Re: TLS server keys in DNS: client policy proposal

2011-02-05 Thread Zack Weinberg
On 2011-02-05 2:02 PM, Nelson B Bolyard wrote: On 2011-02-05 13:28 PDT, Zack Weinberg wrote: ... There is a list/newsgroup focused specifically on the browser policy governing the admittance of CAs to mozilla's root CA list. That probably seems like the more obvious place, but it's where all

TLS server keys in DNS: client policy proposal

2011-02-01 Thread Zack Weinberg
[Some of you may have seen an earlier draft of this proposal before. I originally sent it to secur...@mozilla.org and was asked to bring it here.] I've been following the mailing list for the IETF's keyassure working group, which plans to standardize a mechanism for putting application-layer

TLS server keys in DNS: client policy proposal

2011-02-01 Thread Zack Weinberg
[Some of you may have seen an earlier draft of this proposal before. I originally sent it to secur...@mozilla.org and was asked to bring it here.] I've been following the mailing list for the IETF's keyassure working group, which plans to standardize a mechanism for putting application-layer