Hello Andrei -
> On Mar 2, 2023, at 12:47 PM, Andrei Popov wrote:
>
>> I don't have details, but the NVMe/TCP specification suggests that it can
>> make use of multiple PSK identities during a TLS handshake.
> From my read of NVMe spec, it's one PSK/identity per TLS connection:
>
> "8.13.5.9 G
Hi Eric and Everyone, draft coauthor here.
Appendix C lists "DHE Cipher Suites Refered to by This Document", not ones
which are deprecated.
The intention of the current text is to permit fully ephemeral DHE over a
finite field (FFDHE) with sufficient group size.
However, we also have an unresolve
On Fri, Mar 3, 2023 at 9:21 AM Nimrod Aviram
wrote:
> Hi Eric and Everyone, draft coauthor here.
>
> Appendix C lists "DHE Cipher Suites Refered to by This Document", not ones
> which are deprecated.
>
The intention of the current text is to permit fully ephemeral DHE over a
> finite field (FFDHE
Hi Everyone,
We’ve recently had a brief side discussion around the issue of letting
vendors (or operators) know when something is expected to be deprecated:
https://mailarchive.ietf.org/arch/msg/tls/Djk35kp5P5Z1WfmN8_OJj_eYRLo/
Currently, there is no expected deprecation timeline for any specific
Nimrod,
Thanks for bringing this up. I don't think we really have had much of a
discussion.
I *do* think we should be thinking about deprecating TLS 1.2 at some point,
not so much because
it is bad (though of course we believe TLS 1.3 is better) but because it's
better to just have
one thing tha
+1 on the idea, but I am not convinced that the proposed process is sufficient
(and/or terms are not adequately clear).
It seems to me that the time "for everyone to upgrade" will be dependent upon
market factors related to the technology being replaced as well as with the
severeness of the pr
just want to point of out that at least in the IETF that RFC 9325 [1] was
recently published.
spt
[1] https://datatracker.ietf.org/doc/rfc9325/
> On Mar 3, 2023, at 13:40, Eric Rescorla wrote:
>
> Nimrod,
>
> Thanks for bringing this up. I don't think we really have had much of a
> discussi
>
> And of course, we really
> don't want to have to do major work on TLS 1.2, e.g. for Post-Quantum.
>
More to the point, I'd say the post-quantum transition is the natural
moment to move from ≤1.2 to 1.3.
(TLS 1.2 and earlier are vulnerable to PQ -> classical downgrades during
the transition be
On Fri, Mar 03, 2023 at 09:37:48PM +0100, Bas Westerbaan wrote:
> >
> > And of course, we really
> > don't want to have to do major work on TLS 1.2, e.g. for Post-Quantum.
> >
>
> More to the point, I'd say the post-quantum transition is the
> natural moment to move from ≤1.2 to 1.3.
Agreed.
>
On Fri, Mar 03, 2023 at 08:17:55PM +0200, Nimrod Aviram wrote:
> Specifically, we will have to decide when/if to deprecate version 1.2 of
> TLS within, say, the next 20 years.
20 years is a long time. We can only reason about shorter timelines.
In the next ~5 years, I don't yet see a defensible
On Fri, Mar 3, 2023 at 11:25 AM Sean Turner wrote:
> just want to point of out that at least in the IETF that RFC 9325 [1] was
> recently published.
>
Right. A salient sentence here: "Therefore, this document replaces
[RFC7525], with an explicit goal to encourage migration of most uses of TLS
1.
Viktor Dukhovni writes:
>Yes, once TLS 1.3 is closer to 20 years old, we'll know whether TLS 1.2 can
>or should be retired, but until such time, TLS 1.2 is likely to still be with
>us (embedded in home routers, printers, refrigerators, ...).
Another thing we need a lot more time to find out is w
Dear Sean Turner,
The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request.
tls Session 1 (2:00 requested)
Tuesday, 28 March 2023, Session II 0400-0600
Room Name: G401-G402 size: 225
-
On Fri, Mar 3, 2023, 1:50 PM Viktor Dukhovni wrote:
>
> On Fri, Mar 03, 2023 at 08:17:55PM +0200, Nimrod Aviram wrote:
>
> > Specifically, we will have to decide when/if to deprecate version 1.2 of
> > TLS within, say, the next 20 years.
>
> 20 years is a long time. We can only reason about short
On Fri, Mar 3, 2023 at 2:54 PM Peter Gutmann
wrote:
> Another thing we need a lot more time to find out is whether, like HTTP >
> 1.1,
> TLS 1.3 has forked TLS. For HTTP there'll perpetually be two lines going
> forward, HTTP for web browsers and HTTP 1.1 for everything
> that
> isn't a web bro
Boris Pismenny 于2023年3月2日周四 18:43写道：
>
> On Tue, Feb 28, 2023 at 2:18 PM Lanlan Pan wrote:
>
>> Personally I think, the negotiation may cause the downgrade security
>> risk, making PNE not actually work for privacy protection.
>> The hardware acceleration can support both PNE and plaintext packe
On Fri, Mar 03, 2023 at 03:49:28PM -0800, Watson Ladd wrote:
> > 20 years is a long time. We can only reason about shorter timelines.
> > In the next ~5 years, I don't yet see a defensible reason to deprecate
> > TLS 1.2.
>
> 20 years from today we'll be dealing with products shipped out today.
17 matches
Mail list logo
