I just threw in a couple of PRs to align this I-D with 8446bis & 8447bis, but
forgot to add this issue. I have corrected this now so that we won’t forget
again:
https://github.com/tlswg/tls-flags/issues/36
spt
> On Mar 17, 2024, at 13:53, David Benjamin wrote:
>
> Did this ever get resolved?
On Sun, Mar 17, 2024 at 11:53 PM Karthikeyan Bhargavan <
karthikeyan.bharga...@inria.fr> wrote:
> Is there value in citing the security analysis for ECH as an informative
> reference?
>
> [image: 3548606.cover.jpg]
>
> A Symbolic Analysis of Privacy for TLS 1.3 with Encrypted Client Hello |
> Proc
Is there value in citing the security analysis for ECH as an informative
reference?
Yes!
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Oh, perfect! I was trying to find the GitHub repo to make the PR but missed
it somehow. Here's a PR: https://github.com/tlswg/tls-flags/pull/37
On Mon, Mar 18, 2024 at 5:01 PM Sean Turner wrote:
> I just threw in a couple of PRs to align this I-D with 8446bis & 8447bis,
> but forgot to add this
The following errata report has been verified for RFC6176,
"Prohibiting Secure Sockets Layer (SSL) Version 2.0".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5536
--
Status: Verified
Type:
> …and now I'm coming around to the idea that we don't need to do anything
special to account for the "wrong" server behavior. Since RFC8446 already
explicitly said that clients are allowed to not predict their most
preferred groups, we can already reasonably infer that such servers
actively believ
Any change of getting this adopted by the WG ?
On Mon, 18 Mar 2024 at 15:47, David Benjamin wrote:
>
> > …and now I'm coming around to the idea that we don't need to do anything
> > special to account for the "wrong" server behavior. Since RFC8446 already
> > explicitly said that clients are al
Hi Deirdre,
Just in case I miss the meeting (which is unfortunately after midnight
for me), I would like to mention that this is great idea and I would be
happy to contribute to this.
In our recent research on integrating attestation in Inria's ProVerif
artifacts [1] for TLS 1.3, we faced se
I do think a 'reference' Tamarin model would be useful. It would of course
only model part of TLS (1.3, for example) and only through a particular
symbolic model/tool. And would require maintenance by...someone.
For the triage panel, I do think the preliminary triage is key: we'd ask a
group of ex
A new version of this draft was published a few weeks ago with an
entirely new design. Unless I missed it, the new version hasn't yet been
discussed on the TLS list and I was unaware of the changes until I came
to prepare for the meeting. I have quite a few concerns - I'm sorry to
bring them up
On 18.03.24 16:56, Deirdre Connolly wrote:
I do think a 'reference' Tamarin model would be useful.
Why should it be a Tamarin model? Why not a ProVerif model?
It would of course only model part of TLS (1.3, for example) and only
through a particular symbolic model/tool. And would require
maint
Hi,
I thought the old version was a quite good starting point. This new version
seems significantly worse. I think it has three major problems:
1. It uses the application layer and therefore requires changes in the
application layer. For many uses of TLS, it is not acceptable to change the
app
On Mon, Mar 18, 2024 at 06:46:51PM +, John Mattsson wrote:
> Hi,
>
> I thought the old version was a quite good starting point. This new
> version seems significantly worse. I think it has three major
> problems:
>
> 1. It uses the application layer and therefore requires changes in the
> app
Hello,
I would like to express my support for getting a codepoint for ML-KEM (the
queue was closed quicker than I expected, so didn’t have a chance to do it at
the meeting).
The motivation:
* First of all the integration is rather straightforward.
* MLKEM already got a large amount of research
Recently, Matt Campagna emailed the hybrid KEM group (Douglas, Shay and me)
about a suggestion about one way to potentially improve the performance (in the
'the server hasn't upgraded yet' case), and asked if we should add that
suggestion to our draft. It occurs to me that this suggestion is eq
> If the server supports P256+ML-KEM, what Matt suggested is that, instead
of accepting P256, it instead a ClientHelloRetry with P256+ML_KEM. We then
continue as expected and end up negotiating things in 2 round trips.
I assume ClientHelloRetry was meant to be HelloRetryRequest? If so, yeah, a
se
On Tue, 19 Mar 2024 at 15:27, David Benjamin wrote:
> > If the server supports P256+ML-KEM, what Matt suggested is that, instead
> of accepting P256, it instead a ClientHelloRetry with P256+ML_KEM. We then
> continue as expected and end up negotiating things in 2 round trips.
>
> I assume Client
17 matches
Mail list logo
