Re: [TLS] Abridged Certificate Compression
Hi Dennis. I did read section 3.2.1 of the draft before posting, but I got the impression that the lexicographically ordered list of log identifiers produced in the "Secondly" step was only intended to be used as a reference in the "Finally" step, rather than emitted as "output". I understand that "This dictionary is constructed in three stages, with the output of each stage being concatenated with the next", but the only explicit language regarding which artifacts should be emitted as "output" is "Concatenate the byte representation of each extension (including extension id and length) and copy it to the output". It's not clear to me if that explicit language is intended to be part of the "Finally" step only, or if it's intended to apply to all of the steps. My attempt to clarify things: https://github.com/dennisjackson/draft-jackson-tls-cert-abridge/pull/9. From: TLS on behalf of Dennis Jackson Sent: 14 July 2023 11:30 To: TLS List Subject: Re: [TLS] Abridged Certificate Compression CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. On 13/07/2023 10:13, Rob Stradling wrote: How about also including in the shared dictionary the SHA-256 hashes of the public keys of all the known CTv1 logs, so that the 32-byte LogID field of each SCT will be compressed? This is already step 2 of the shared dictionary construction :-) (link<https://www.ietf.org/archive/id/draft-jackson-tls-cert-abridge-00.html#section-3.2.1-4>). Best, Dennis FWIW, RFC9162 (CTv2) tackles the same SCT bloat by changing the LogID type from a (32-byte) SHA-256 hash of the log's public key to a (minimum 4-byte) DER-encoded OID (excluding the tag and length octets). From: TLS <mailto:tls-boun...@ietf.org> on behalf of Tim Hollebeek <mailto:tim.hollebeek=40digicert@dmarc.ietf.org> Sent: 12 July 2023 19:29 To: Kampanakis, Panos <mailto:kpanos=40amazon@dmarc.ietf.org>; Dennis Jackson <mailto:ietf=40dennis-jackson...@dmarc.ietf.org>; TLS List <mailto:tls@ietf.org> Subject: Re: [TLS] Abridged Certificate Compression CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. SCTs have always seemed surprisingly large to me, and it has always seemed like there should be a more compact representation that has the same security properties, but I've never found the time to look more closely at it. If someone does have the time, figuring out how to reduce the size of SCTs would be quite helpful. -Tim > -Original Message- > From: TLS <mailto:tls-boun...@ietf.org> On Behalf Of > Kampanakis, Panos > Sent: Wednesday, July 12, 2023 2:23 PM > To: Dennis Jackson > <mailto:ietf=40dennis-jackson...@dmarc.ietf.org>; > TLS List > <mailto:tls@ietf.org> > Subject: Re: [TLS] Abridged Certificate Compression > > > The performance benefit isn't purely in the ~1KB saved, its whether it > > brings > the chain under the QUIC amplification limit or shaves off an additional > packet > and so avoids a loss+retry. There's essentially no difference in > implementation > complexity, literally just a line of code, so the main tradeoff is the > required disk > space on the client & server. > > Fair. I would add one more tradeoff which is pulling the end-entity certs in > the > CT window for pass 2. This is an one time cost for each dictionary version, so > maybe not that bad. > > Regardless, would compressing the leaf bring us below the QUIC 3.6KB > threshold for Dilithium 2 or 3 certs whereas not suppressing would keep us > above? I think it is not even close if we are talking WebPKI. Without SCTs, > maybe compressing could keep us below 4KB for Dilithium 2 leaf certs. But > even then, if we add the CertVerify signature size we will be well over 4KB. > > Additionally, would compressing the leaf bring us below the 9-10KB threshold > that Bas had tested to be an important inflection point? For WebPKI, it may > the 8-9KB cert below 9KB if we add the CertVerify signature size. Maybe not. > It > would need to tested. For Dilithium 3, maybe compression could render the > 11-12KB cert below 9KB if we got lucky, maybe not, but if we add the > CertVerify signature we won’t make it. For non-WebPKI, they will already be > below 9-10KB. > > So, I am arguing that we can't remain below the QUIC threshold by > compressing the leaf Dilithium cert. And we could remain below the 9-10KB > only for Dilithium2 leaves. I could be proven wrong if you have implemented &g
Re: [TLS] Abridged Certificate Compression
How about also including in the shared dictionary the SHA-256 hashes of the public keys of all the known CTv1 logs, so that the 32-byte LogID field of each SCT will be compressed? FWIW, RFC9162 (CTv2) tackles the same SCT bloat by changing the LogID type from a (32-byte) SHA-256 hash of the log's public key to a (minimum 4-byte) DER-encoded OID (excluding the tag and length octets). From: TLS on behalf of Tim Hollebeek Sent: 12 July 2023 19:29 To: Kampanakis, Panos ; Dennis Jackson ; TLS List Subject: Re: [TLS] Abridged Certificate Compression CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. SCTs have always seemed surprisingly large to me, and it has always seemed like there should be a more compact representation that has the same security properties, but I've never found the time to look more closely at it. If someone does have the time, figuring out how to reduce the size of SCTs would be quite helpful. -Tim > -Original Message- > From: TLS On Behalf Of Kampanakis, Panos > Sent: Wednesday, July 12, 2023 2:23 PM > To: Dennis Jackson ; TLS List > > Subject: Re: [TLS] Abridged Certificate Compression > > > The performance benefit isn't purely in the ~1KB saved, its whether it > > brings > the chain under the QUIC amplification limit or shaves off an additional > packet > and so avoids a loss+retry. There's essentially no difference in > implementation > complexity, literally just a line of code, so the main tradeoff is the > required disk > space on the client & server. > > Fair. I would add one more tradeoff which is pulling the end-entity certs in > the > CT window for pass 2. This is an one time cost for each dictionary version, so > maybe not that bad. > > Regardless, would compressing the leaf bring us below the QUIC 3.6KB > threshold for Dilithium 2 or 3 certs whereas not suppressing would keep us > above? I think it is not even close if we are talking WebPKI. Without SCTs, > maybe compressing could keep us below 4KB for Dilithium 2 leaf certs. But > even then, if we add the CertVerify signature size we will be well over 4KB. > > Additionally, would compressing the leaf bring us below the 9-10KB threshold > that Bas had tested to be an important inflection point? For WebPKI, it may > the 8-9KB cert below 9KB if we add the CertVerify signature size. Maybe not. > It > would need to tested. For Dilithium 3, maybe compression could render the > 11-12KB cert below 9KB if we got lucky, maybe not, but if we add the > CertVerify signature we won’t make it. For non-WebPKI, they will already be > below 9-10KB. > > So, I am arguing that we can't remain below the QUIC threshold by > compressing the leaf Dilithium cert. And we could remain below the 9-10KB > only for Dilithium2 leaves. I could be proven wrong if you have implemented > it. > > One more argument for making pass 2 optional or allowing for just pass 1 > dictionaries is that if we are not talking about WebPKI we don't have the > luxury of CT logs. But we would still want to option of compressing / omitting > the ICAs by using CCADB. > > > > > -Original Message- > From: Dennis Jackson > Sent: Wednesday, July 12, 2023 12:39 PM > To: Kampanakis, Panos ; TLS List > Subject: RE: [EXTERNAL][TLS] Abridged Certificate Compression > > 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. > > > > On 12/07/2023 04:34, Kampanakis, Panos wrote: > > > Thanks Dennis. Your answers make sense. > > > > Digging a little deeper on the benefit of compressing (a la Abridged > > Certs draft) the leaf cert or not. Definitely this draft improves vs > > plain certificate compression, but I am trying to see if it is worth > > the complexity of pass 2. So, section 4 shows a 2.5KB improvement over > > plain compression which would be even more significant for Dilithium > > certs, but I am trying to find if the diff between ICA > > suppression/Compression vs ICA suppression/Compression+leaf > > compression is significant. [/n] > > > > I am arguing that the table 4 numbers would be much different when > > talking about Dilithium certs because all of these numbers would be > > inflated and any compression would have a small impact. Replacing a CA > > cert (no SCTs) with a dictionary index would save us ~4KB (Dilithium2) > > or 5.5KB (Dilithium3). That is significant. [/n] > > > > Compressing the leaf (of size 8-9KB (Dilithium2) or 11-12 KB (Dilithium 3)) > using any mechanism would trim down ~0.5-1KB compared to not > compressing. That is because the PK and Sig can't be compressed and these > account for most of the PQ leaf cert size. So, I am trying to see if pass 2 > and > compression of the leaf cert benefit us much. > > I think there's a fairly big difference between
Re: [TLS] ct_compliant cached info field
Thanks EKR. Done, in https://github.com/google/certificate-transparency-rfcs/pull/307 On 22/02/2019 14:51, Eric Rescorla wrote: > That works for me > > -Ekr > > > On Fri, Feb 22, 2019 at 6:41 AM Rob Stradling <mailto:r...@sectigo.com>> wrote: > > EKR, Martin, > > Hi, and sorry for the long delay in replying. > > This originated in [1] and was added to 6962-bis in [2]. The > motivation > was to provide a mechanism to permit a TLS server to avoid sending CT > artifacts (SCTs, STHs, inclusion proofs) that it knows the TLS client > already has or doesn't need, thereby reducing bytes on the wire for > constrained and high-volume environments. > > The approach envisaged by RFC7924 seems to be: "here's a list of TLS > message fingerprints I've received previously; please don't send these > exact messages to me again". This works for stand-alone messages that > contain one item, such as the server's Certificate message (which > contains 1 server certificate chain). > > However, in 6962-bis's case, SCTs and inclusion proofs are not > stand-alone items; instead, they correspond to particular certificates. > Each relevant TLS message will contain a TransItemList, which will > probably contain at least a set of several SCTs; and whilst each SCT is > static, the set (and the order within the set) is not. Therefore, the > approach of caching TLS messages by fingerprint didn't look like it > would work for us. > > We concluded that it would make more sense for the client to make a > more > high-level statement: "here's a list of certificate fingerprints that > I've received previously and that I already regard as being > CT-compliant". > > This isn't an essential part of 6962-bis. Other than Ben L's "Sounds > like a good idea" comment in [1], I don't recall anyone commenting > on it > until EKR started this thread. > > I propose to remove this cached-info mechanism from 6962-bis, if nobody > objects. (It could of course be revisited in some future document, if > there's interest). > > > [1] https://trac.ietf.org/trac/trans/ticket/111 > > [2] https://github.com/google/certificate-transparency-rfcs/pull/186 > > On 31/12/2018 14:36, Eric Rescorla wrote: > > + trans > > > > On Sun, Dec 30, 2018 at 10:06 PM Martin Thomson > mailto:m...@lowentropy.net> > > <mailto:m...@lowentropy.net <mailto:m...@lowentropy.net>>> wrote: > > > > > > On Fri, Dec 28, 2018, at 04:58, Eric Rescorla wrote: > > > Please take a look at > > > > > > https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-30#section-6.5 > > > > At a minimum, this would seem to update cached_info. > > > > There's not a lot of meat on this text. It seems to be > saying that > > if you are providing transparency_info, then you can provide a > > certificate other than any of the certificates that the client > > believes to be CT compliant. Also, you don't provide > "x509_sct_v2" > > or "precert_sct_v2" in transparency_info. > > > > How is the client then able to determine that this new > certificate > > is CT compliant? Using "inclusion_proof_v2" and > > "signed_tree_head_v2" (or one or other)? If so, the text doesn't > > point in that direction. > > > > There's a lot of "why" missing in this document. Why would a > client > > choose to indicate "ct_compliant"? Why is cached_info being > > extended in this way? > > > > I might guess that the reason here is that the draft aims to > avoid > > including information that might change over time, which would > > render caches invalid. Isn't that motivation to recommend an SCT > > over an STH? > > > > Separately, why does this establish a new registry for signature > > schemes? It is obviously trying to keep TLS compatibility, > based on > > the codepoints, but forking the registry is a great way to create > > problems. > > -- > Rob Stradling > Senior Research & Development Scientist > Email: r...@sectigo.com <mailto:r...@sectigo.com> > -- Rob Stradling Senior Research & D
Re: [TLS] ct_compliant cached info field
EKR, Martin, Hi, and sorry for the long delay in replying. This originated in [1] and was added to 6962-bis in [2]. The motivation was to provide a mechanism to permit a TLS server to avoid sending CT artifacts (SCTs, STHs, inclusion proofs) that it knows the TLS client already has or doesn't need, thereby reducing bytes on the wire for constrained and high-volume environments. The approach envisaged by RFC7924 seems to be: "here's a list of TLS message fingerprints I've received previously; please don't send these exact messages to me again". This works for stand-alone messages that contain one item, such as the server's Certificate message (which contains 1 server certificate chain). However, in 6962-bis's case, SCTs and inclusion proofs are not stand-alone items; instead, they correspond to particular certificates. Each relevant TLS message will contain a TransItemList, which will probably contain at least a set of several SCTs; and whilst each SCT is static, the set (and the order within the set) is not. Therefore, the approach of caching TLS messages by fingerprint didn't look like it would work for us. We concluded that it would make more sense for the client to make a more high-level statement: "here's a list of certificate fingerprints that I've received previously and that I already regard as being CT-compliant". This isn't an essential part of 6962-bis. Other than Ben L's "Sounds like a good idea" comment in [1], I don't recall anyone commenting on it until EKR started this thread. I propose to remove this cached-info mechanism from 6962-bis, if nobody objects. (It could of course be revisited in some future document, if there's interest). [1] https://trac.ietf.org/trac/trans/ticket/111 [2] https://github.com/google/certificate-transparency-rfcs/pull/186 On 31/12/2018 14:36, Eric Rescorla wrote: > + trans > > On Sun, Dec 30, 2018 at 10:06 PM Martin Thomson <mailto:m...@lowentropy.net>> wrote: > > > On Fri, Dec 28, 2018, at 04:58, Eric Rescorla wrote: > > Please take a look at > > > https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-30#section-6.5 > > At a minimum, this would seem to update cached_info. > > There's not a lot of meat on this text. It seems to be saying that > if you are providing transparency_info, then you can provide a > certificate other than any of the certificates that the client > believes to be CT compliant. Also, you don't provide "x509_sct_v2" > or "precert_sct_v2" in transparency_info. > > How is the client then able to determine that this new certificate > is CT compliant? Using "inclusion_proof_v2" and > "signed_tree_head_v2" (or one or other)? If so, the text doesn't > point in that direction. > > There's a lot of "why" missing in this document. Why would a client > choose to indicate "ct_compliant"? Why is cached_info being > extended in this way? > > I might guess that the reason here is that the draft aims to avoid > including information that might change over time, which would > render caches invalid. Isn't that motivation to recommend an SCT > over an STH? > > Separately, why does this establish a new registry for signature > schemes? It is obviously trying to keep TLS compatibility, based on > the codepoints, but forking the registry is a great way to create > problems. -- Rob Stradling Senior Research & Development Scientist Email: r...@sectigo.com ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] OCSP stapling problem
On 19/12/2018 13:13, Salz, Rich wrote: >> OpenSSL already has some support for Must-Staple: >> https://github.com/openssl/openssl/pull/495 > > Oops, yeah, you're aright. But it's not really documented and not hooked up > to any popular server, is it? OpenSSL can parse it, but that's about it. I suspect that's true. What would hooking it up to a webserver look like, I wonder? Would the webserver automatically enable OCSP stapling if the server cert indicates Must Staple? Or would the webserver throw an error and refuse to start until the administrator has manually enabled OCSP stapling? -- Rob Stradling Senior Research & Development Scientist Sectigo Limited ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] OCSP stapling problem
On 19/12/2018 01:18, Salz, Rich wrote: >> The "exim" server claims to support stapling (for incoming connections) > > Yes, which isn't what I asked. > >> The Must-Staple belongs to the certificate which was requested > including "1.3.6.1.5.5.7.1.24=DER:30:03:02:01:05" > in the CSR. > > Does the exim server understand that extension? If, for example, exim was > built with OpenSSL, then it does not handle that extension. What TLS stack > was the server built with? > >> OCSP Must-Staple certificates are getting more popular. > > FWIW, I have not noticed this, but maybe I'm looking in the wrong places. On > the other hand, nobody has raised the issue, nor made a pull request, with > OpenSSL, so it can't be very popular yet. Rich, OpenSSL already has some support for Must-Staple: https://github.com/openssl/openssl/pull/495 (Perhaps I've misunderstood what is "the issue" that "nobody has raised"?) -- Rob Stradling Senior Research & Development Scientist Sectigo Limited ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] How to Validate Servers' Identities w/out reliable source of time
Hi Max. The most promising solution I've seen to this problem is Google's Roughtime protocol. Adam Langley's blog post: https://www.imperialviolet.org/2016/09/19/roughtime.html Protocol description: https://roughtime.googlesource.com/roughtime/+/HEAD/PROTOCOL.md Open-source implementation: https://roughtime.googlesource.com/roughtime Cloudflare's Roughtime service: https://blog.cloudflare.com/roughtime/ On 04/10/18 16:22, Dr. Pala wrote: Hi all, I am struggling with one issue that we have been seeing more and more often with the introduction of small IoT devices that connect to clouds via TLS and need to validate the cloud server's (or the other party's) certificate chain. In particular, the problem is that without a reliable (or trusted) source of Time information, devices can not reliably validate certificates (i.e., is the certificate even valid... ? is it expired ? is the revocation info fresh enough ?) and my question for the list is about best practices in the space. The problem is even more problematic for devices with limited access to the network (e.g., access only to specific servers / cloud services) since no "external" source of time can be used. Do you know if there are indications / best practices from ITU or from IETF (or other organizations) on how to deal with this issue ? Has the issue been addressed somewhere ? Cheers, Max -- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo -- Rob Stradling Senior Research & Development Scientist Email: r...@comodoca.com ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Certificate compression draft
Hi Hannes. Cached-Info is useful, but it can only "compress" if the client has previously seen and cached the server's certificate. AIUI, the purpose of draft-ghedini-tls-certificate-compression is to enable compression even in cases where the client hasn't yet seen the server's certificate. On 07/03/17 08:14, Hannes Tschofenig wrote: Hi Victor why don't you use RFC 7924: https://tools.ietf.org/html/rfc7924 This provides an even better "compression" ratio. Ciao Hannes On 03/06/2017 11:58 PM, Victor Vasiliev wrote: Certificate compression has been discussed on this list briefly before, and there was some interest in at least considering a draft for it. The draft now exists (co-authored by Alessandro and myself), and it can be found at: https://datatracker.ietf.org/doc/draft-ghedini-tls-certificate-compression/ [ GitHub repo: https://github.com/ghedo/tls-certificate-compression ] The proposed scheme allows a client and a server to negotiate a compression algorithm for the server certificate message. The scheme is purely opt-in on both sides. The current version of the draft defines zlib and Brotli compression, both of which are well-specified formats with an existing deployment experience. There are multiple motivations to compress certificates. The first one is that the smaller they are, the faster they arrive (both due to the transfer time and a decreased chance of packet loss). The second, and more interesting one, is that having small certificates is important for QUIC in order to achieve 1-RTT handshakes while limiting the opportunities for amplification attacks. Currently, TLS 1.3 over TCP without client auth looks like this: Round trip 1: client sends SYN, server sends SYN ACK Here, the server provides its own random value which client will have to echo in the future. Round trip 2: client sends ACK, ClientHello, server sends ServerHello...Finished Here, ACK confirms to server that the client can receive packets and is not just spoofing its source address. Server can send the entire ServerHello to Finished flight. In QUIC, we are trying to merge those two rounds into one. The problem, however, is that the ClientHello is one packet, and ServerHello...Finished can span multiple packets, meaning that this could be used as an amplification attack vector since the client's address is not yet authenticated at this point. In order to address this, the server has to limit the number of packets it sends during the first flight (i.e. ServerHello...Finished flight). Since certificates make up the majority of data in that flight, making them smaller can push them under the limit and save a round-trip. Cheers, Victor. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Confirming consensus: TLS1.3->TLS*
On 02/12/16 14:53, Thomas Pornin wrote: Commercial CA tend to sell "SSL certificates", not "TLS certificates" or "SSL/TLS certificates". It's worse than that. Many customers, and even some salespeople, seem to think that we sell "SSLs". -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 -> TLS 2.0?
On 30/08/16 21:14, Hubert Kario wrote:
On Tuesday, 30 August 2016 14:19:33 CEST Dave Garrett wrote:
* Keep the version ID as { 3, 4 } (already weird counting; changing risks
more intolerance)
IMNSHO this alone is enough of a reason not to do this
it's enough explaining to people that SSLv3.3 is really TLSv1.2, now we'll
have SSLv3.4 == TLSv1.3 == TLSv2.0
it's silly at this point
It's been silly for nearly two decades already!
https://plus.google.com/+IlyaGrigorik/posts/BesDRVDqB4h
So...
On 30/08/16 21:20, Erik Nygren wrote:
However, I think we should consider calling it TLS 4 or TLS 4.0 or TLS 5.
In particular, much of the non-technical audience still calls it "SSL"
(pet peeve of many of us, I suspect) and having a version number clearly
greater than SSLv3 and not confusing with SSLv2 would be quite
valuable. "TLS 2" may have risk for unfortunate confusions with SSLv2
and SSLv3.
How about we drop the "TLS" name completely, and simply call it "SSLv4"
or "SSLv5" ? Then the non-technical audience that still calls it "SSL"
would magically become correct again. :-)
Returning to a previous name seems to be trendy at the moment...
https://en.wikipedia.org/wiki/Mac_OS
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] RSA-PSS in TLS 1.3
On 02/03/16 09:10, Rob Stradling wrote: Neither you nor I can post in any of the CA/Browser forum’s lists, because neither of us has either a browser or a public CA. There are some people who are active there and are reading this list, so they might take such a proposal there. I’m not very optimistic, though. Please don't give up without even trying! If you have a proposal, I'd be happy to post it to the pub...@cabforum.org list on your behalf. Oh, somebody else beat me to it: https://cabforum.org/pipermail/public/2016-March/006910.html -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] RSA-PSS in TLS 1.3
On 01/03/16 19:20, Yoav Nir wrote: On 1 Mar 2016, at 8:23 PM, Alyssa Rowan <a...@akr.io> wrote: When a CA issues a certificate it has to work with every client and server out there, That doesn't have to be true. For example, many OpenSSL-based servers can be configured to serve an ECC certificate to TLS clients that indicate support for ECC, and to serve an RSA certificate to other TLS clients. When we use TLS 1.3, the other side supports TLS 1.3 as well, so it’s fair to assume that it knows PSS. Perhaps the PKIX working group and CAB/Forum could both use a friendly reminder not to ignore how perilous using RSA PKCS#1 v1.5 still remains? +1 Neither you nor I can post in any of the CA/Browser forum’s lists, because neither of us has either a browser or a public CA. There are some people who are active there and are reading this list, so they might take such a proposal there. I’m not very optimistic, though. Please don't give up without even trying! If you have a proposal, I'd be happy to post it to the pub...@cabforum.org list on your behalf. Alternatively, you could post it to the questi...@cabforum.org list yourself. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Controlling use of SHA-1
On 22/10/15 00:52, Dave Garrett wrote: I'm in favor of this change as well. It annoys Viktor, as it changes the fallback in a way that isn't ideal for some cases that trust the cert directly or with OE, IINM this also changes the fallback for servers that choose to include a PKIX trust anchor certificate in the Server Certificate message. Lots of publicly trusted root certificates have sha1WithRSAEncryption signatures. TLS clients typically don't verify these SHA-1 signatures, so there's no rush to remove them from trust anchor stores. but I think it's better than the alternative. Why would it make sense to prohibit the sending of PKIX trust anchor certificates that have sha1WithRSAEncryption signatures? Dave On Wednesday, October 21, 2015 03:17:44 pm Eric Rescorla wrote: I think this is the right answer and parallels what we are doing with PSS. -Ekr On Wed, Oct 21, 2015 at 12:15 PM, Martin Thomson <martin.thom...@gmail.com> wrote: The current draft permits the use of SHA-1 in the certificate chain, which gives SHA-1 a free pass indefinitely. Since we expressly forbid the use of SHA-1 for signing in TLS itself, we can just permit clients to include it in "signature_algorithms" and use that to determine whether SHA-1 is acceptable. That means that clients that want to disable SHA-1 (real soon now, we promise), can signal that preference cleanly. I've opened PR #317 for this, but the commit is probably more useful to review, since I built this on top of ekr's client authentication changes (to avoid messy rebases): https://github.com/martinthomson/tls13-spec/commit/354475cf02819a9cc808457f2c09fdaeb1f82aa5 -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
AIUI, OpenSSL's default highest preference curve is sect571r1 (aka B-571). See [1] and [2]. The result of calling OpenSSL's recommended SSL_CTX_set_ecdh_auto(ctx, 1) function is that the highest preference curve is automatically used for ECDH temporary keys used during key exchange. [3] And sure enough, when my SSL scanner (an OpenSSL-based client) scans itself (an httpd/mod_ssl/OpenSSL-based server) [4], it reports that sect571r1 is used. I haven't explicitly configured it to use this curve. In fact, I would reconfigure it to use secp256r1 if I could find a mod_ssl directive that would let me do that. So I'm wondering if most people using sect571r1 are using it simply because it's a default setting that they can't change, not because they have a particularly strong desire to use it. +1 to dropping sect571r1 and to Tony's suggestion of further trimming the curve list. [1] https://www.ssllabs.com/ssltest/viewClient.html?name=OpenSSLversion=1.0.1l [2] https://www.ssllabs.com/ssltest/viewClient.html?name=OpenSSLversion=1.0.2 [3] http://openssl.org/docs/ssl/SSL_CTX_set_ecdh_auto.html [4] https://sslanalyzer.comodoca.com/?url=sslanalyzer.comodoca.com On 15/07/15 22:42, Dave Garrett wrote: On Wednesday, July 15, 2015 05:39:26 pm Dave Garrett wrote: It's the most used of the rarely used curves. This statement is potentially confusing, actually, because in comparison to P256 _everything_ is rarely used when it comes to ECDHE. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
