Rob Sayre writes:
>>On Mon, Dec 11, 2023 at 5:30 PM Peter Gutmann
>>wrote:
>>
>>Absolutely clear. I work with stuff with 20-30 year deployment and life
>>cycles. I'm fairly certain TLS 1.2 will still be around when the WebTLS
>>world is debating the merits of TLS 1.64 vs. TLS 1.65.
>
>I have
Off-list: Funny that you should mention nuclear power plants, at least one of
the systems I'm thinking of is used in nuclear power control. Those things are
remarkably resilient, including in at least one case having the facility
overrun by an invading army. They looted all the standard PCs bu
>From my experience, it is possible to update the firmware on many modern
>constrained IoT devices, including the TLS / DTLS stack, today. Of course,
>there are a lot of devices out there where updating the firmware involves
>physical access by some technician.
However, there are a few other ch
Viktor Dukhovni writes:
>Peter, is there anything beyond TLS-TLS that you're looking to see work on?
>Is the issue foreclosing on opportunities to do anticipated necessary work,
>or is it mostly that the statement that the work can't happen causing
>disruption with audits and other bureaucratic i
Loganaden Velvindron writes:
>I'm curious. Are those embedded devices or IoT type of appliances where the
>firmware has a TLS library that will never be updated ?
Typically, yes. Many devices don't support remote firmware update, or need
physical access to do it so it's never done, or will be d
Hi Peter,
with or without "freeze", I guess it will be not too easy to get enough
interest for required discussions and reviews to change or fix TLS 1.2.
On the other side, if there is enough interest for a special future 1.2
topic, I also don't get it, why that should be blocked with an "feature
Hi! Rich $, Martin T, and ekr have all added some thoughts. Anybody else
have some thoughts?
spt
> On Dec 6, 2023, at 11:20, Sean Turner wrote:
>
> Hi! A thread over on the IRTF’s CFRG list, see [0], has resulted in a PR, see
> [1], that includes additional instructions for the designated
I should also included a link to the revised PR:
https://github.com/tlswg/draft-ietf-tls-esni/pull/597
spt
> On Dec 11, 2023, at 22:01, Sean Turner wrote:
>
> I am going to go ahead and forward this. Note that since the “Comments”
> column isn’t a thing until we get 8447bis through the door th
Stephen:
I've been thinking about your point. Some people want to use RFC 8773 to
protect data that is transmitted today and recorded from the future invention
of a quantum computer. To do this, the handshake includes the identifier for
the external PSK, and an observer can get tracking data
Christian:
>>>
>>> Thanks. I am not 100% sure that we actually have an attack against the
>>> [EC]DH+PSK combination, but I am confident than if the PSK secret is weak,
>>> the attacker can get to the early data. If only for that, it is prudent to
>>> use long enough PSK.
>> As stated in draft
On Fri, Dec 08, 2023 at 05:47:01PM +, Salz, Rich wrote:
>
> Good point. https://github.com/richsalz/tls12-frozen/pull/12 has the
> change. I’ll wait until/if this is adopted by the WG to merge it.
Reading through the document, I noticed the following:
"To securely deploy TLS 1.2, either re
On Tue, Dec 12, 2023 at 1:09 AM Peter Gutmann
wrote:
> are
> you saying you don't believe that there are systems out there deployed and
> used with multi-decade life cycles?
I believe that--but these are so old that the other parts are starting to
become a problem. In my case, the ethernet stac
Peter knows more about long-term embedded systems that use TLS than anyone else
on this list. I trust him. Don’t think of things connected to the public
Internet, but rather things like client-auth missle launching systems, seismic
(nuclear) monitoring equipment, and the like. Stuff that you c
On Tue, Dec 12, 2023 at 1:23 AM Peter Gutmann wrote:
>
> Viktor Dukhovni writes:
>
> >Peter, is there anything beyond TLS-TLS that you're looking to see work on?
> >Is the issue foreclosing on opportunities to do anticipated necessary work,
> >or is it mostly that the statement that the work can'
Hiya,
On 12/12/2023 17:08, Russ Housley wrote:
Stephen:
I've been thinking about your point. Some people want to use RFC
8773 to protect data that is transmitted today and recorded from the
future invention of a quantum computer. To do this, the handshake
includes the identifier for the exte
15 matches
Mail list logo
