The chairs would like to have an interim to review the FATT (Formal Analysis
Triage Team) process. We are still working out the proposal, but we would like
to get this meeting scheduled to review any feedback / comments once we do post
the process. Please fill out the following with your availab
Hi! There is consensus to adopt this draft as a working group item.* This might
not be the exact form it ends up in, but there is sufficient interest to get
the work started. I'll work with the authors to migrate to the official
repository and submit an updated draft.
spt
* Apologies for takin
Hi! There is consensus to adopt this draft as a working group item.* I'll work
with the authors to migrate to the official repository and submit an updated
draft.
spt
* Apologies for taking so long. Some of the delay was a result of working on
the FATT process.
> On Jul 25, 2024, at 12:15, S
Hi David,
Thanks for digging in here. I haven't fully processed your comments, but it
does seem like we probably do need a -bis. Now that we've gotten 8446-bis
and ECH out the door, I don't think this is implausible. Do you feel like
you are getting close to a complete list of issues to be address
Joseph Salowey has requested publication of draft-ietf-tls-esni-22 as Proposed
Standard on behalf of the TLS working group.
Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
___
TLS mailing list -- tls@ietf.o
Backing up a bit, at what point do we say QUIC Datagram is the right
way to do this?
This whole adventure sounds like a mess.
On Fri, Sep 20, 2024 at 8:20 AM David Benjamin wrote:
>
> (Resending since I don't see these two mails in the list archives, so I'm not
> sure if the list software broke
> On Sep 23, 2024, at 16:50, Sean Turner via Datatracker
> wrote:
>
> Sean Turner has requested publication of draft-ietf-tls-svcb-ech-05 as
> Proposed Standard on behalf of the TLS working group.
>
> Please verify the document's state at
> https://datatracker.ietf.org/doc/draft-ietf-tls-svc
Sean Turner has requested publication of draft-ietf-tls-svcb-ech-05 as Proposed
Standard on behalf of the TLS working group.
Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-tls-svcb-ech/
___
TLS mailing list -- tls@i
Hi! Thanks to all those who have already filled out the poll. I am hoping to
close this out by Friday so I will send daily reminders until then.
Cheers,
spt
> On Sep 23, 2024, at 12:05, Sean Turner wrote:
>
> The chairs would like to have an interim to review the FATT (Formal Analysis
> Triag
We have requested the IESG publish ECH. The ECH protocol has undergone
formal analysis to verify its security and privacy properties. The
analysis referenced in the document is
https://www.cs.ox.ac.uk/people/vincent.cheval/publis/BCW-ccs22.pdf.
___
TLS
There is rough consensus that the document should have additional formal
analysis before publication. Ekr proposed the following for the
authentication property, which seems like a reasonable clarification
"I think the right analysis is one in which the attacker knows the PSK. For
instance, say we
For my neck of the woods, DTLS matters for WebRTC. It really should be
QUIC, but alas it isn't and I suspect redesigning all of WebRTC now atop
QUIC and then fully completing the transition would take much longer than
getting to DTLS 1.3, much as the DTLS 1.3 specification needs a -bis
document. :-
To add to the list of issues, DTLS 1.3 says very little about 0-RTT, but
skipping early data is very different between TLS and DTLS. In particular,
I think Appendix D.3 just doesn't apply to DTLS 1.3. DTLS 1.2
implementations were already expected to discard bad packets, so they'll
naturally skip o
I agree, and I think the Security Considerations already cover this point:
If the external PSK is known to any party other than the client and
the server, then the external PSK MUST NOT be the sole basis for
authentication. The reasoning is explained in Section 4.2 of
[K2016]. When t
14 matches
Mail list logo
