Removind dead code from NSS
Hi, AFAIK NSS still contains code for SSL2 , but no product uses it. SSL2 has been turned off at least 2 years ago. By removing SSL2 code we get : Smaller librarie faster compile time + test time What do you guys think ? Ludo -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removind dead code from NSS
On 10/04/2013 06:52 PM, Ludovic Hirlimann wrote: Hi, AFAIK NSS still contains code for SSL2 , but no product uses it. SSL2 has been turned off at least 2 years ago. By removing SSL2 code we get : Smaller librarie faster compile time + test time What do you guys think ? Ludo That's something we would like to do, but we do have downstreams that can't remove it yet. We could make it a compile option so it can be compiled out (which will get most of the benefits most of the time). bob smime.p7s Description: S/MIME Cryptographic Signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Removing SSL 2.0 from NSS (was Re: Removing dead code from NSS)
On Fri, Oct 4, 2013 at 6:52 PM, Ludovic Hirlimann ludovic+n...@mozilla.com wrote: Hi, AFAIK NSS still contains code for SSL2 , but no product uses it. SSL2 has been turned off at least 2 years ago. By removing SSL2 code we get : Smaller librarie faster compile time + test time What do you guys think ? Hi Ludovic, I do think it is time to remove SSL 2.0 support from libssl. The size of libssl won't be much different and it won't compile much faster. However, removing SSL 2.0 code from libssl will enable us to make the code much easier to understand in ways that I am 100% sure will positively impact the security of our SSL3/TLS code. So, I propose that libssl remove SSL 2.0 support in NSS 3.16. I will be happy to write the patch for it; I actually have it partially done already. I can think of at least one serious bug in libssl that likely would have been avoided if not for the additional complexity of needing to deal with SSL 2.0. Plus, not having to deal with the SSL 2.0 code will definitely enable us to improve the SSL3/TLS code easier in the future. I can think of multiple times where the need to deal with the SSL 2.0 code has slowed down the implementation of improvements to the newer protocols. This is an unreasonable cost for us to have to incur for a feature that we know nobody should be using. When the NSS team discussed this topic previously, we had agreed that we wouldn't remove the SSL 2.0 code before TLS 1.2 was implemented, so that Red Hat could have a version of NSS with both SSL 2.0 and TLS 1.2 for their long-term release. Now TLS 1.2 is implemented and we should move forward with the removal. I think it is likely that some vendors of NSS-based products with very conservative backward-compatibility guarantees, like Oracle and maybe Red Hat, may need to continue supporting SSL 2.0 in their products due to promises that they've made. If so, either we should create a branch for these organizations to maintain, or we should create a branch of libssl without SSL 2.0. I am OK with doing things either way, though I prefer to have the NSS trunk be the SSL-2.0-less branch that Mozilla contributes to. Cheers, Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
Mountie Lee moun...@paygate.net wrote: SEED was adopted to encourage escaping ActiveX dependency in Korea e-commerce environment. Many people at Mozilla, including us platform engineers, want this too. Our goal is to get rid of plugins on the internet completely. And, also, personally I think it is a great idea for Mozilla to do more to get Firefox working in South Korea. So, I think we all agree on the goals. at last year, adding SEED to WebCrypto API adopted as Action Item. the editor sent question any user agent plan to implement SEED I can not say discussing terminating SEED support in mozilla Whether SEED gets implemented to the WebCrypto API is a separate issue from whether we continue to support SEED in TLS. If we want to add SEED support to WebCrypto then we can do that even if we don't have SEED in TLS. I am not going to promise that we will implement SEED as part of the WebCrypto effort, but I do promise to give it serious consideration. minor algorithm itself has the meaning. it will be helpful for neutralizing or keeping possibilities. I agree that this is a concern. This is one of the reasons we are looking into the Salsa/ChaCha algorithms, as a backup or replacement for AES. Finally, software vendors, including Mozilla, need to work with the Korean government to agree on what to do about the Korean crypto regulations. Mozilla has been supporting SEED for TLS for a long time and it seems to have had no positive impact. If in the future the software industry and the Korean government decide that SEED in TLS is the way forward, then we can add SEED back if we remove it now. However, I am skeptical that the software industry is going to agree that SEED in TLS is the right path forward. Cheers, Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: set default on for SHA2 for TLS1.1+ on firefox
On Wed, Oct 2, 2013 at 2:28 AM, Mountie Lee moun...@paygate.net wrote: Hi. currently SHA2 hash algorithm is used in TLS1.1 and 1.2 mozilla firefox is supporting it now. Hi, Are you referring to the TLS_*_SHA256 cipher suites, or something else? I believe that we support SHA256-based signatures everywhere already. If you are referring to the TLS_*_SHA256 cipher suites, then the current plan is to never enable them in Firefox. It seems Chrome has decided on something similar, as they disabled those cipher suites after they added AES-GCM support. If you are referring to something other than the TLS_*_SHA256 cipher suites, please be more specific as to what you are referring to. Cheers, Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removing SSL 2.0 from NSS (was Re: Removing dead code from NSS)
On Mon, Oct 07, 2013 at 11:17:46AM -0700, Brian Smith wrote: On Fri, Oct 4, 2013 at 6:52 PM, Ludovic Hirlimann ludovic+n...@mozilla.com wrote: Hi, AFAIK NSS still contains code for SSL2 , but no product uses it. SSL2 has been turned off at least 2 years ago. By removing SSL2 code we get : Smaller librarie faster compile time + test time What do you guys think ? Hi Ludovic, I do think it is time to remove SSL 2.0 support from libssl. I'm all for removing SSL 2.0 support. OpenSSL still supports SSL 2.0, but the default cipher list doesn't include any ciphers that can be used with SSL 2.0 and so thus disabling the use of SSL 2.0 by default. I assume the same goes for NSS. In Debian I decided to build openssl since 1.0.0 without SSL 2.0 support, I didn't receive any negative feedback from that. At that point it didn't support TLS 1.1 or 1.2 yet since that only got added in 1.0.1. But the 1.0.0 version wasn't part of any release. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
On Fri, Aug 30, 2013 at 01:10:08AM +0200, Kurt Roeckx wrote: So what needs to happen so that we can move on with this? I still have the same question. Nothing seems to be happening. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removing SSL 2.0 from NSS (was Re: Removing dead code from NSS)
On Mon, Oct 7, 2013 at 11:17 AM, Brian Smith br...@briansmith.org wrote: I think it is likely that some vendors of NSS-based products with very conservative backward-compatibility guarantees, like Oracle and maybe Red Hat, may need to continue supporting SSL 2.0 in their products due to promises that they've made. If so, either we should create a branch for these organizations to maintain, or we should create a branch of libssl without SSL 2.0. The burden of maintaining the branch should fall on the people who still need SSL 2.0, so we should remove SSL 2.0 from the trunk. It is not that hard for a competent NSS developer to support an NSS 3.15 branch for another three years. Note: we will keep the ability on the server side to handle a ClientHello in the SSL 2.0 format. Removing SSL 2.0 is an important step to clean up the SSL library because it blocks some other cleanups, such as the handling of handshakes and receive (gather) buffers. Wan-Teh -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: set default on for SHA2 for TLS1.1+ on firefox
On Mon, Oct 7, 2013 at 12:02 PM, Brian Smith br...@briansmith.org wrote: If you are referring to something other than the TLS_*_SHA256 cipher suites, please be more specific as to what you are referring to. Brian, If you can enable TLS 1.2 by default in Firefox, that should make Mountie happy. Besides the HMAC-SHA256 cipher suites, the AES-GCM cipher suites also make it possible to do TLS without using SHA-1 at all. TLS 1.1 still contains hardcoded use of MD5 and SHA1 in the protocol. Wan-Teh -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Still possible to sign a certificate request with NSS tools?
Hallo, Thanks in advance for any help. I've builded NSS 3.15.2 in order to run a demo including certificate path validation. Looking at NSS docs https://developer.mozilla.org/en-US/docs/NSS/tools/NSS_Tools_certutil this should be possible. But it seems the code I eventually achieved has different parameters now. Is this function still supported and if so is there an up to date documentation? Other question ... What is the process of docs editing? For instance, I noticed a discrepancy in https://developer.mozilla.org/en-US/docs/NSS_reference/Building_and_installing_NSS/Build_instructions and would like to fix. Would someone review the change? I wouldn't like my ignorance or good luck to confuse other people. The issue in particular ... Step 5 in Build Instructions For Recent Versions (Mercurial) says gmake nss_build_all. On Windows it should be make instead of gmake; at least this is what worked for me. Cheers, Ivo Kolev -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removind dead code from NSS
On 10/07/2013 11:19 AM, Ryan Sleevi wrote: On Mon, October 7, 2013 11:07 am, Robert Relyea wrote: On 10/04/2013 06:52 PM, Ludovic Hirlimann wrote: Hi, AFAIK NSS still contains code for SSL2 , but no product uses it. SSL2 has been turned off at least 2 years ago. By removing SSL2 code we get : Smaller librarie faster compile time + test time What do you guys think ? Ludo That's something we would like to do, but we do have downstreams that can't remove it yet. We could make it a compile option so it can be compiled out (which will get most of the benefits most of the time). bob -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto Adding compile-time flags (and the accompanying #define soup) can almost end up worse - it prevents graceful cleanup/refactoring work that would also come with dead code removal. refactoring isn't one of the features we could support until the code is removed (at least easily)... nor was it one of the things Ludo was looking for (at least in the mail). Though the SSL 2 code is not as intertwined as some of the other features. I think it's basically the gather and caching code that is really the only code that is affected by ssl2. There doesn't seem to be any code in ssl3con.c and sslcon.c is strictly SSL2 (well there's some code that calls ssl3 if you are using the compatible hello, but you don't need that code if you are strictly ssl3/tls). Bob, could you provide more information about these downstreams using it? 1) Are they staying up to date with NSS? eg: If they're stuck on NSS 3.12.x, what should it matter about removing it in 3.16? It's Red Hat. We are staying up to date with NSS. Unfortunately I also have to support features in that version of the OS. So when we change defaults upstream, the don't necessarily get changed in NSS itself. 2) If so, is the reason for doing so security patches/updates? Mozilla requires NSS rebases as new version of Mozilla are released. 3) If so, why would they have SSL 2.0 enabled and yet still be following security updates? They're at odds with eachother. This is the way enterprise support works. Enterprise customers work on decade long support cycles. We've had these discussions before, which is why we have started working on making sure that we aren't locked in for another 10 years at Red Hat. Our customers are really sensitive to these kinds of changes 'mid release'. It's the fact the NSS upstream has supported these that even allows us to do things like update the browser. I'd like to see us be able to come up with clear exit criteria for removing this feature. I can appreciate It's being used, but can you provide more details about why and how, so that we can have a more productive discussion about what it would mean and take to remove this code? We understand that we want to remove several pieces of code from NSS. That is why we have disabled the ability to even enable SSL2 in RHEL-7. Actually the bar is quite a bit lower than in the past. In the past we could never really rip any code out. bob Cheers, Ryan smime.p7s Description: S/MIME Cryptographic Signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removing SSL 2.0 from NSS (was Re: Removing dead code from NSS)
On 10/07/2013 12:01 PM, Kurt Roeckx wrote: On Mon, Oct 07, 2013 at 11:17:46AM -0700, Brian Smith wrote: On Fri, Oct 4, 2013 at 6:52 PM, Ludovic Hirlimann ludovic+n...@mozilla.com wrote: Hi, AFAIK NSS still contains code for SSL2 , but no product uses it. SSL2 has been turned off at least 2 years ago. By removing SSL2 code we get : Smaller librarie faster compile time + test time What do you guys think ? Hi Ludovic, I do think it is time to remove SSL 2.0 support from libssl. I'm all for removing SSL 2.0 support. OpenSSL still supports SSL 2.0, but the default cipher list doesn't include any ciphers that can be used with SSL 2.0 and so thus disabling the use of SSL 2.0 by default. I assume the same goes for NSS. SSL2 has been turned off by default for a while. You can't support SSL 3/TLS extensions with it on. In Debian I decided to build openssl since 1.0.0 without SSL 2.0 support, I didn't receive any negative feedback from that. At that point it didn't support TLS 1.1 or 1.2 yet since that only got added in 1.0.1. But the 1.0.0 version wasn't part of any release. Kurt smime.p7s Description: S/MIME Cryptographic Signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removing SSL 2.0 from NSS (was Re: Removing dead code from NSS)
On 10/07/2013 12:44 PM, Wan-Teh Chang wrote: On Mon, Oct 7, 2013 at 11:17 AM, Brian Smith br...@briansmith.org wrote: I think it is likely that some vendors of NSS-based products with very conservative backward-compatibility guarantees, like Oracle and maybe Red Hat, may need to continue supporting SSL 2.0 in their products due to promises that they've made. If so, either we should create a branch for these organizations to maintain, or we should create a branch of libssl without SSL 2.0. The burden of maintaining the branch should fall on the people who still need SSL 2.0, so we should remove SSL 2.0 from the trunk. It is not that hard for a competent NSS developer to support an NSS 3.15 branch for another three years. Please don't completely screw us over here. I would prefer to be able to track NSS updates, particularly since they are pulled in by mozilla. (we completely rebase nss whenever we have to pick up new mozilla releases that need it). That being said, I think we could split the ssl 2.0 code out stand along. The only issue is ssl2 hello-ssl3, which would probably mean figuring out some why to make that transition that puts the burden on the ssl2 code. Note: we will keep the ability on the server side to handle a ClientHello in the SSL 2.0 format. Removing SSL 2.0 is an important step to clean up the SSL library because it blocks some other cleanups, such as the handling of handshakes and receive (gather) buffers. Ideally so ideally we could completely fork the SSL2 code to use it's own gather buffers. Right now I'm trying to see if I can get management to let us drop SSL2 support in some upcoming RHEL 6 release. I've already dropped it in RHEL7, and I think we may be at the point in RHEL-5 where we may not be updating NSS except for some extreme fixes. One thing that could help is to make sure the next mozilla CSB release supports SSL2 that will give RHEL 6 some more runway... Bob Wan-Teh smime.p7s Description: S/MIME Cryptographic Signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removing SSL 2.0 from NSS (was Re: Removing dead code from NSS)
On Mon, Oct 7, 2013 at 3:20 PM, Robert Relyea rrel...@redhat.com wrote: On 10/07/2013 12:44 PM, Wan-Teh Chang wrote: On Mon, Oct 7, 2013 at 11:17 AM, Brian Smith br...@briansmith.org wrote: I think it is likely that some vendors of NSS-based products with very conservative backward-compatibility guarantees, like Oracle and maybe Red Hat, may need to continue supporting SSL 2.0 in their products due to promises that they've made. If so, either we should create a branch for these organizations to maintain, or we should create a branch of libssl without SSL 2.0. The burden of maintaining the branch should fall on the people who still need SSL 2.0, so we should remove SSL 2.0 from the trunk. It is not that hard for a competent NSS developer to support an NSS 3.15 branch for another three years. Please don't completely screw us over here. I would prefer to be able to track NSS updates, particularly since they are pulled in by mozilla. (we completely rebase nss whenever we have to pick up new mozilla releases that need it). I think if some Linux distributors would continue to use the code that contains SSL 2.0 support, then it would be better for Firefox to link libssl statically to avoid using that variant of libssl. That being said, I think we could split the ssl 2.0 code out stand along. The only issue is ssl2 hello-ssl3, which would probably mean figuring out some why to make that transition that puts the burden on the ssl2 code. Ideally so ideally we could completely fork the SSL2 code to use it's own gather buffers. This is much easier said than done, because many bits of data are shared between the implementation of SSL 2.0 and the later versions. The point of removing SSL 2.0 would be to make the code simpler so that we can be confident that it is correct, and to make it easier to improve. Refactoring the SSL 2.0 code in the manner you suggest is counterproductive to both of those aims, and recent experience gives clear evidence of that. Right now I'm trying to see if I can get management to let us drop SSL2 support in some upcoming RHEL 6 release. I've already dropped it in RHEL7, and I think we may be at the point in RHEL-5 where we may not be updating NSS except for some extreme fixes. That is a Red Hat problem, not a Mozilla problem. The Mozilla project is bigger than just Firefox and Gecko-based products, but I don't think the Mozilla project's interests extend so far as to be concerned about Red Hat backward compatibility guarantee to its customers. We are willing to help Red Hat when it is reasonable, but I think this issue has reached the point there it is now unreasonable to carry on as before. One thing that could help is to make sure the next mozilla CSB release supports SSL2 that will give RHEL 6 some more runway... For a long time, Gecko-based products hard-code SSL 2.0 to be disabled and there is no option for enabling SSL 2.0 support in Gecko products. I would not accept the addition of such an option either. If there is some server that is SSL 2.0 only then I will be glad to have Firefox stop working with that server, so that the server admin feels pressure to improve the security of the server. Cheers, Brian -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
On Thu, Sep 12, 2013 at 7:06 AM, Julien Vehent jul...@linuxwall.info wrote: It seems that AES-256 is always 25% to 30% slower than AES-128, regardless of AES-NI, or the CPU family. The slowest implementation of AES-256 has a bandwidth of 21MBytes/s, which is probably fast enough for any browser If performance was the only reason to prefer AES-128, I would disagree with the proposal. But your other arguments regarding AES-256 not provided additional security, are convincing. This paper: eprint.iacr.org/2007/318.pdf On the complexity of side-channel attacks on AES-256 - methodology and quantitative results on cache attacks - Perhaps my arguments were a little over-stated though. The attack I referenced in the proposal is the related-key attack on reduced-round AES-256. That is something I should have emphasized. Really, I am speculating that this shows that thinking AES-256 is hugely more secure than AES-128 is questionable, but it isn't a slam-dunk case. The side-channel attack paper you cited seems like the more interesting one. It doesn't seem like an argument against AES-256 on its own though, since it still says AES-256 is more difficult to attack through the given side channels than AES-128. So, the main remaining question with AES-256 vs. AES-128 is not whether AES-128 is just as secure as AES-256. Instead, we have to decide whether AES-256 a better security/performance trade-off vs AES-128. I agree with you that the performance numbers for AES-256 vs. AES-128 do not make this a slam-dunk. We should do the measurements on a typical Firefox OS device and see if there is a significant difference there. Until then, unless others suggest otherwise, I think I will just keep the relative ordering of analogous AES-256 and AES-128 cipher suites the same as they are in NSS today. However, it refers to software implementations of AES. Do we know if this result still applies for AESNI? One takeaway from your email is that with AES-NI I don't see a strong case for prefering AES-128 over AES-256. The issue is really what to do about the non-AES-NI case, assuming we all agree that the presence of AES-NI shouldn't affect the order that the client suggests cipher suites in. Thank you very much for taking the time to do these measurements and sharing your insight. Cheers, Brian -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
On Mon, Oct 7, 2013 at 4:50 PM, Brian Smith br...@briansmith.org wrote: On Thu, Sep 12, 2013 at 7:06 AM, Julien Vehent jul...@linuxwall.info wrote: It seems that AES-256 is always 25% to 30% slower than AES-128, regardless of AES-NI, or the CPU family. The slowest implementation of AES-256 has a bandwidth of 21MBytes/s, which is probably fast enough for any browser If performance was the only reason to prefer AES-128, I would disagree with the proposal. But your other arguments regarding AES-256 not provided additional security, are convincing. This paper: eprint.iacr.org/2007/318.pdf On the complexity of side-channel attacks on AES-256 - methodology and quantitative results on cache attacks - Perhaps my arguments were a little over-stated though. The attack I referenced in the proposal is the related-key attack on reduced-round AES-256. That is something I should have emphasized. Really, I am speculating that this shows that thinking AES-256 is hugely more secure than AES-128 is questionable, but it isn't a slam-dunk case. Hi Brian, all, Related-key attacks are irrelevant to TLS or any standard use of a block cipher. Side-channel attacks against AES just have to recover subkeys from a round or two, so it's not surprising that the difference between 10-round AES128 and 14-round AES256 doesn't make much of a difference. Against non-side-channel cryptanalysis of TLS ciphertext, AES-256 certainly has a higher security margin than AES-128. Trevor -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
Hi. thanks for mail. the reason why SEED support give not so much impact is SEED is not used alone but used with other crypto algorithms (hash, asymmetric...) SHA2 hash required in e-commerce transaction by the korean regulation. and which is also used in TLSv1.1+. SEED can be used under TLSv1.1+ environment. as we know, it is just now opened from box. regards mountie. On Tue, Oct 8, 2013 at 3:56 AM, Brian Smith br...@briansmith.org wrote: Mountie Lee moun...@paygate.net wrote: SEED was adopted to encourage escaping ActiveX dependency in Korea e-commerce environment. Many people at Mozilla, including us platform engineers, want this too. Our goal is to get rid of plugins on the internet completely. And, also, personally I think it is a great idea for Mozilla to do more to get Firefox working in South Korea. So, I think we all agree on the goals. at last year, adding SEED to WebCrypto API adopted as Action Item. the editor sent question any user agent plan to implement SEED I can not say discussing terminating SEED support in mozilla Whether SEED gets implemented to the WebCrypto API is a separate issue from whether we continue to support SEED in TLS. If we want to add SEED support to WebCrypto then we can do that even if we don't have SEED in TLS. I am not going to promise that we will implement SEED as part of the WebCrypto effort, but I do promise to give it serious consideration. minor algorithm itself has the meaning. it will be helpful for neutralizing or keeping possibilities. I agree that this is a concern. This is one of the reasons we are looking into the Salsa/ChaCha algorithms, as a backup or replacement for AES. Finally, software vendors, including Mozilla, need to work with the Korean government to agree on what to do about the Korean crypto regulations. Mozilla has been supporting SEED for TLS for a long time and it seems to have had no positive impact. If in the future the software industry and the Korean government decide that SEED in TLS is the way forward, then we can add SEED back if we remove it now. However, I am skeptical that the software industry is going to agree that SEED in TLS is the right path forward. Cheers, Brian -- Mountie Lee PayGate CTO, CISSP Tel : +82 2 2140 2700 E-Mail : moun...@paygate.net === PayGate Inc. THE STANDARD FOR ONLINE PAYMENT for Korea, Japan, China, and the World -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
On Mon, Oct 7, 2013 at 6:05 PM, Mountie Lee moun...@paygate.net wrote: SHA2 hash required in e-commerce transaction by the korean regulation. and which is also used in TLSv1.1+. Hi, First, we will be enabling TLS 1.2 in Firefox very soon. But, I think you may be referring to SHA-2-based cipher suites proposed in this internet draft: http://tools.ietf.org/html/draft-bjhan-tls-seed-00 Unfortunately, that internet draft expired and also the draft didn't even specify the cipher suite code points. Where can I find the current version of the Korean regulations on encryption. I have read this article: http://www.koreatimes.co.kr/www/news/biz/2012/04/123_109059.html That article notes that SEED is actually not mandatory in Korea any more. If so, it seems like a good idea to help the Korean community standardize on more common algorithms, right? That article also notes that implementations other than the ActiveX control have to be certified by the Korean government in order to be used. So, it seems like our SEED implementation could not be used legally anyway, since it hasn't been certified. Is that your understanding? My understanding is that the Korean government would also require websites that fall under these regulations to use certificates issued by some Korean certificate authorities. But, Mozilla does include either of the Korean certificate authorities and it seems unlikely to happen soon. See https://bugzilla.mozilla.org/show_bug.cgi?id=335197 Finally, the SEED cipher suite we do currently support does not support ephemeral key exchange. I see that the internet draft I linked to above does attempt to specify SEED cipher suites that support ephemeral key exchange. So, it seems pretty clear to me that it is OK to disable the SEED cipher suite we have currently enabled for now, while we figure out all the things that are necessary to help our Korean users. Cheers, Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
