Hi, All TLS experts:
We are seeking the experts from the TLS WG, who is/are familiar with the TLS
protocol itself and know how to extend it to accommodate new features within
TLS.
We have provided such extensions within the TCP
protocol(https://datatracker.ietf.org/doc/html/draft-wang-tcpm-tcp
Hiya,
On 15/03/2025 10:14, Russ Housley wrote:
Stephen:
I did write to Yunlei and ask for an IPR disclosure.
Yes, and thanks for doing that.
As far as I
know, Yunlei has never participated in an IETF activity, so he has
not promised for follow the NOTE WELL.
Dan pointed the LAMPS WG to
Revised agenda posted; this indicates my best question as to when the
presentations will fall.
stp
> On Mar 7, 2025, at 10:11 AM, Sean Turner wrote:
>
> Hi! We have posted the draft agenda for the tls@ietf122 session. The draft
> agenda can be found here:
> https://datatracker.ietf.org/doc/ag
Hi, Dmitry:We want to switch the TLS connection quickly to another address of the same server, to keep the following transaction traffic stick to the same server, that is to say, keep the service affinity during the network fluctuations.The previous address of the server is one ANYCAST address tha
I gave this document an initial read. At a high level this seems like
a good start if the TLS WG is going to pursue PAKE bindings to TLS
1.3. With that said, given the longish history of PAKEs in TLS,
I'd like to be sure that we have critical mass for implementation,
so if we get to the point of an
We want to switch the TLS connection quickly to another address of the same
server, to keep the following transaction traffic stick to the same server …
The previous address of the server is one ANYCAST address that are shared by
several servers that can provide the same service.
Are you trying
Hi, Rich:
I knew QUIC had such mechanism, as that are described in
https://www.rfc-editor.org/rfc/rfc9000.html#name-connection-migration. We just
want to implement the similar procedure in TLS, for different scenarios, at the
beginning of TLS handshake as quickly as possible.
Regarding to your
On Sat, Mar 15, 2025 at 4:55 PM Eric Rescorla wrote:
>
> Note that this wouldn't necessarily be the case if you allowed the
> combination of certificate-based auth and the PAKE, though that might
> be problematic for other reasons.
>
That was exactly my thought. I think I have seen some OPAQUE d
Thanks to everyone that has taken a look at draft-bmw-tls-pake13-01.txt and
provided feedback so far. As more people start reading it, I wanted to clarify
that the current draft version does not yet reflect the change we intend to
make to allow Certificates and the pake extension to be used toge
Thank you for the clarification. It is an interesting problem to think about,
especially when you think that the change might be introduced by “the network”
or by “the client”, such as when the user moves from home to office.
___
TLS mailing list -- t
On Sat, Mar 15, 2025 at 6:19 PM Rob Sayre wrote:
> On Sat, Mar 15, 2025 at 4:55 PM Eric Rescorla wrote:
>
>>
>> Note that this wouldn't necessarily be the case if you allowed the
>> combination of certificate-based auth and the PAKE, though that might
>> be problematic for other reasons.
>>
>
>
Reviewer: Jen Linkova
Review result: Ready
The document is clearly written and easy to understand even by people who knows
very little about TLS (like this reviewer ;) I think the document has no
negative impact on deployments: quite the opposite, it might motivate people to
move to TLS1.3.
I thi
Internet-Draft draft-ietf-tls-tlsflags-15.txt is now available. It is a work
item of the Transport Layer Security (TLS) WG of the IETF.
Title: A Flags Extension for TLS 1.3
Author: Yoav Nir
Name:draft-ietf-tls-tlsflags-15.txt
Pages: 9
Dates: 2025-03-15
Abstract:
A nu
Do I correctly understand that you are proposing the mechanism to save some
traffic and computation when we have a previously happened communication?
On Sat, 15 Mar 2025, 16:39 Aijun Wang, wrote:
> Hi, All TLS experts:
>
> We are seeking the experts from the TLS WG, who is/are familiar with the
14 matches
Mail list logo
