Re: [TLS] Better TLS Client Authentication

Hi Phillip, I'm not able to figure out the merits of your proposal, but I see one major obstacle: Google have a de-facto monopoly (80%) on browser technology and your proposal seems to require a rather substantial upgrade. That is, unless Google buys into whatever you propose, it simply put

Re: [TLS] PR#28: Converting cTLS to QUIC-style varints

On 2020-10-07 19:47, Mohit Sethi M wrote: A strong +1 on the security issues of decode -> extract -> re-encode -> verify signature flow. The lack of canonical encoding can also mean that the resulting bytes can be different in different encoder/decoder implementations. It would have been nice

Re: [TLS] (offline) Re: Draft for SM cipher suites used in TLS1.3

an hurdle for innovation and adoption of new technology. thanx, Anders Rundgren On 2019-08-18 10:09, Kepeng Li wrote: Can you point to specific drafts where **normative** references are only available for paying a fee?  I guess that there are some, but I don’t know of any. This is one

Re: [TLS] Confirming consensus: TLS1.3->TLS*

Using the YEAR as Version was created to make sure that users having old versions of products that are constantly upgraded would feel the pressure to upgrade. This idea doesn't seem equally suitable for security protocols. TLS 4 would IMO be a logical choice since it is numerically higher than

Re: [TLS] Confirming consensus: TLS1.3->TLS*

On 2016-11-19 07:35, Victor Vasiliev wrote: On Fri, Nov 18, 2016 at 9:30 PM, Kazuho Oku > wrote: I oppose to going to TLS 4, due to the following reasons: * it might give people false notion that SSL 2.0, 3.0 is superior to TLS

Re: [TLS] CertficateRequest extension encoding

On 2016-09-06 16:15, Peter Gutmann wrote: David Benjamin writes: Either way I imagine our stack will just keep on ignoring it, so I don't feel about this all too strongly. But the topic came up so I thought I'd suggest this. I ignore it too. Client certs are so rare,