[TLS] doubt - what to do if a CA do not renew their expired cert?
Hi, I have a layman doubt. While working on a project, recently I discovered a list of CA cert which got expired. I am not responsible for sites using those cert. But my end users said sites using those certs are failing due to expired cert. So I visited the official CA website to download the latest renewed certificate, but I am unable to find any. In such cases what to do? SInce all sites using them will start failing. Is it not the duty of the CA to issue the renewed cert well in advance to their customers? one e.g. Subject: C=TR, L=Istanbul, O=Isimtescil Bilisim Anonim Sirketi, OU=SSL Department, CN=TrustSafe Domain Validated CA - Certificate: Data: Version: 3 (0x2) Serial Number: 6493029426882832914 (0x5a1bdfdcb9826a12) Signature Algorithm: sha256WithRSAEncryption Issuer: C=TR, L=Ankara, O=E-Tu\xC4\x9Fra EBG Bili\xC5\x9Fim Teknolojileri ve Hizmetleri A.\xC5\x9E., OU=E-Tugra Sertifikasyon Merkezi, CN=E-Tugra Certification Authority Validity Not Before: Dec 27 11:19:37 2018 GMT Not After : Mar 3 12:09:48 2023 GMT Subject: C=TR, L=Istanbul, O=Isimtescil Bilisim Anonim Sirketi, OU=SSL Department, CN=TrustSafe Domain Validated CA --- This got expired on 3 Mar 2023, but I am unable to find the renewed cert on the CA website (e-tugra). what to do in such cases? with regards, Saravanan ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D Action: draft-ietf-tls-deprecate-obsolete-kex-02.txt
Hi, Since the draft has DHE cipher suites as a MUST NOT, I believe the appropriate value is indeed "Discouraged". (From 8447bis: "N: Indicates that the item has not been evaluated by the IETF and that the IETF has made no statement about the suitability of the associated mechanism." That seems incongruent with MUST NOT.) We might as well add text to change the RSA cipher suites to "D". It'd be great if one of the chairs could please chime in and let us know if this sounds reasonable? thanks, Nimrod On Wed, 29 Mar 2023 at 08:28, John Mattsson wrote: > Hi, > > > > 5. IANA Considerations > > > > This document requests IANA to mark the cipher suites listed in Appendix > C as not recommended in the "TLS Cipher Suites" registry. Note that all > cipher suites listed in Appendix A and in Appendix D are already marked > as not recommended in the registry. > > How do we split the IANA actions for cipher suites between this document, > RFC8447, and draft-mattsson-tls-psk-ke-dont-dont-dont? > > ”N” seems highly inappropriate for TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA > > that is very clearly a “D” > > What about TLS_DHE_RSA_WITH_AES_128_GCM_SHA256. Is that a ”N”? The > definition of discourage is clear with RFC8447bis. The definition of > deprecated is not as clear. > > > > Cheers, > > John > > > *From: *TLS on behalf of internet-dra...@ietf.org < > internet-dra...@ietf.org> > *Date: *Sunday, 26 March 2023 at 00:54 > *To: *i-d-annou...@ietf.org > *Cc: *tls@ietf.org > *Subject: *[TLS] I-D Action: draft-ietf-tls-deprecate-obsolete-kex-02.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This Internet-Draft is a work item of the Transport Layer > Security (TLS) WG of the IETF. > >Title : Deprecating Obsolete Key Exchange Methods in TLS 1.2 >Authors : Carrick Bartle > Nimrod Aviram >Filename: draft-ietf-tls-deprecate-obsolete-kex-02.txt >Pages : 20 >Date: 2023-03-25 > > Abstract: >This document deprecates the use of RSA key exchange and Diffie >Hellman over a finite field in TLS 1.2, and discourages the use of >static elliptic curve Diffie Hellman cipher suites. > >Note that these prescriptions apply only to TLS 1.2 since TLS 1.0 and >1.1 are deprecated by [RFC8996] and TLS 1.3 either does not use the >affected algorithm or does not share the relevant configuration >options. > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-deprecate-obsolete-kex/ > > There is also an HTML version available at: > > https://www.ietf.org/archive/id/draft-ietf-tls-deprecate-obsolete-kex-02.html > > A diff from the previous version is available at: > > https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-deprecate-obsolete-kex-02 > > Internet-Drafts are also available by rsync at rsync.ietf.org: > :internet-drafts > > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design
> > The draft draft-tls-westerbaan-xyber768d00-00 references > draft-cfrg-schwabe-kyber-01, which has a number of annoying mistakes, > since fixed in editor's copy. > > And then, the correct reference for X25519 is probably RFC7748 instead > of RFC8037... > > > Really quick and dirty way to fix this would be to publish editor's > copy as draft-cfrg-schwabe-kyber-02 (or if CFRG adapts quickly, the > RG-00), and then publish draft-tls-westerbaan-xyber768d00-01, fixing > the references. > Thanks, done. Posted -02 of both the Kyber and Xyber drafts. Best, Bas ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design
Regarding additional key agreements. For the (public) web it would be best if we can agree on a default key agreement. If one half uses P-256+Kyber768 and the other X25519+Kyber768, then clients will either HRR half the time or need to send both. Neither are ideal. Obviously this point is moot for internal networks. So I do not oppose specifying additional preliminary key agreements, but I do not like to actively support it. What about specifying further preliminary key agreements in yet again a separate draft? Best, Bas On Sat, Apr 1, 2023 at 1:56 AM Bas Westerbaan wrote: > The draft draft-tls-westerbaan-xyber768d00-00 references >> draft-cfrg-schwabe-kyber-01, which has a number of annoying mistakes, >> since fixed in editor's copy. >> >> And then, the correct reference for X25519 is probably RFC7748 instead >> of RFC8037... >> >> >> Really quick and dirty way to fix this would be to publish editor's >> copy as draft-cfrg-schwabe-kyber-02 (or if CFRG adapts quickly, the >> RG-00), and then publish draft-tls-westerbaan-xyber768d00-01, fixing >> the references. >> > > Thanks, done. Posted -02 of both the Kyber and Xyber drafts. > > Best, > > Bas > > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design
Hi Bas, I prefer for the MTI to be P-256+Kyber768 for compliance reasons. It would be trivial for servers to add support for both identifiers as they introduce Kyber768, but you are right, the new draft should include an MTI identifier. From: TLS On Behalf Of Bas Westerbaan Sent: Friday, March 31, 2023 8:04 PM To: Ilari Liusvaara Cc: TLS@ietf.org Subject: RE: [EXTERNAL][TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. Regarding additional key agreements. For the (public) web it would be best if we can agree on a default key agreement. If one half uses P-256+Kyber768 and the other X25519+Kyber768, then clients will either HRR half the time or need to send both. Neither are ideal. Obviously this point is moot for internal networks. So I do not oppose specifying additional preliminary key agreements, but I do not like to actively support it. What about specifying further preliminary key agreements in yet again a separate draft? Best, Bas On Sat, Apr 1, 2023 at 1:56 AM Bas Westerbaan mailto:b...@cloudflare.com>> wrote: The draft draft-tls-westerbaan-xyber768d00-00 references draft-cfrg-schwabe-kyber-01, which has a number of annoying mistakes, since fixed in editor's copy. And then, the correct reference for X25519 is probably RFC7748 instead of RFC8037... Really quick and dirty way to fix this would be to publish editor's copy as draft-cfrg-schwabe-kyber-02 (or if CFRG adapts quickly, the RG-00), and then publish draft-tls-westerbaan-xyber768d00-01, fixing the references. Thanks, done. Posted -02 of both the Kyber and Xyber drafts. Best, Bas ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design
> On 1 Apr 2023, at 09:04, Bas Westerbaan > wrote: > > What about specifying further preliminary key agreements in yet again a > separate draft? Agreed. I'll do that.___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design
> I would pair secp384r1 with Kyber768 for completely different reasons: > Kyber768 is what the team kyber recommends. Agreed. > I don't think there are very good reasons for NIST curves here outside > wanting CNSA1 compliance, and for that you need secp384r1 classical > part. And for that, I would pick secp384r1_kyber768. > >From my perspective, the two reasons for including a NIST curves are: 1. To have an option for those who require FIPS compliance. In a short term at least one key agreement scheme should be FIPS-approved. In the long term both of them should be fips-approved. That way, in case security of Kyber768 falls below 112-bits or simply implementation is broken, one can still run key agreement in FIPS compliant manner. In the end, the ultimate goal of hybrid-tls draft is to ensure that at least one of the schemes provides security if the other gets broken. Would be good to use this in FIPS context also. 2. NIST curves are more often implemented in HW than Curve25519. When working with chips like ATECC608B, one ideally only adds SW-based Kyber and can reuse existing HW-based ECDH. Such migration is simpler, less risky and time-consuming than adding SW-based X25519. To accelerate migration, the hybrid-tls draft should move forward rather quickly and be useful variety of use-cases. Hence, I suggest we assign two codepoints one for X25519-Kyber768 and the other for ECDH/p256-Kyber768. X25519 and P256 provide same security level, from my old days in Cloudflare I remember both schemes were used quite often in TLS, so I hope this choice is not to controversial. Regarding CNSA, I've no experience with national security systems, but does it actually allows to use hybrid schemes? it seems to me that neither 1.0 nor 2.0 allows usage of hybrid schemes (SP800-56C is mentioned but in regards to ECDH, not KDF). Maybe those needs can be addressed at later stage? Kind regards, --- Kris Kwiatkowski Staff Cryptography Architect PQShield ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
