On Tue, Jul 11, 2023 at 09:37:19PM +0100, Dennis Jackson wrote:
> Hi Ilari,
>
> On 10/07/2023 20:19, Ilari Liusvaara wrote:
> > What does "Note that the connection will fail regardless even if this
> > step is not taken as neither certificate validation nor transcript
> > validation can succeed."
On 12/07/2023 11:01, Ilari Liusvaara wrote:
On Tue, Jul 11, 2023 at 09:37:19PM +0100, Dennis Jackson wrote:
TLS Certificate Compression influences the transcript for the decompressing
party, as the output is the Certificate message which is used in the
transcript.
RFC 8879 does not alter how t
On Wednesday, 12 July 2023 06:02:09 CEST, Kampanakis, Panos wrote:
Hi Dennis,
One more topic for general discussion.
The abridged certs draft requires a server who participates and
fetches dictionaries in order to make client connections faster.
As Bas has pointed out before, this paradigm di
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
> On Jul 11, 2023, at 13:52, Salz, Rich wrote:
>
>> This email starts the working group last call for "Deprecating Obsolete Key
>> Exchange Methods in TLS 1.2” I-D, located here:
>
>> . https://datatracker.ietf.org/doc/draft-ietf-tls-deprecate-obsolete-kex
>
> Three minor issues and a quest
On 12/07/2023 04:54, Kampanakis, Panos wrote:
Hi Dennis,
Appendix B.1 talks about 100-200 new ICA and 10 Root certs per year. In the
past I had looked at fluctuations of CCADB and there are daily changes. When
checking in the past, I did not generate the ordered list as per pass 1 on a
daily
On Wed, Jul 12, 2023 at 12:40:13PM -0400, Sean Turner wrote:
> > On Jul 11, 2023, at 13:52, Salz, Rich wrote:
> >
> >> This email starts the working group last call for "Deprecating Obsolete
> >> Key Exchange Methods in TLS 1.2” I-D, located here:
> >
> >> . https://datatracker.ietf.org/doc/d
On 12/07/2023 05:02, Kampanakis, Panos wrote:
The abridged certs draft requires a server who participates and fetches
dictionaries in order to make client connections faster. As Bas has pointed out
before, this paradigm did not work well with OSCP staples in the past. Servers
did not chose to
Imo, the dictionary approach a simple way of trimming down the PQ auth data.
And your argument for the frequency of synching OCSP staples vs these certs is
a good one. I hope TLS termination points will agree if this moves forward, but
personally I don't find the approach too bad.
-Origina
> 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
Honestly, people can blame all sorts of things for the OCSP stapling problems,
but there was nothing inherently wrong with the approach. The implementations
were just pretty poor due to issues Hubert Kario correctly outlined. In
general,
the needs of server operators and maintainers of server so
>This appears in s2:
>Note that TLS 1.0 and 1.1 are deprecated by [RFC8996]
>and TLS 1.3 does not support FFDH [RFC8446].
>You’re suggesting that this be moved to s1?
My main point is say it once, not repeat it in each section.
> If that’s the case then maybe make Appendix B normative (and resort
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
On Wed, Jul 12, 2023, 11:31 AM Tim Hollebeek wrote:
> 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
>
> On Wed, Jul 12, 2023, 11:31 AM Tim Hollebeek 40digicert@dmarc.ietf.org> wrote:
>
>> 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
I wish there was a study of the certs issued by newly introduced CAs in CCADB
and how quickly they ramp up. I am concerned that a 1 year old dictionary could
end up slowing down a good amount of destinations. But again, that slowdown
does not mean an outage. And servers could ensure they get the
16 matches
Mail list logo
