On 12/2/20 6:00 PM, Ackermann, Michael wrote:
I don't disagree with anything you say on the TLS subject, which is
essentially that prior versions of TLS may be considered insecure, etc. and
should be deprecated.
RFC 2119 equates, semantically, at least in English, MUST NOT with
Barbara,
Thanks.
And I think I was aware of all you state below regarding TLS, and apologize for
any related confusion regarding IPv6, even though, for the purposes of my
comment, they are similar.
I don't disagree with anything you say on the TLS subject, which is
essentially that prior
On Dec 2, 2020, at 1:51 PM, STARK, BARBARA H wrote:
> The final version of this was published over a year ago (August 2019). The
> first draft was in 2017.
> You said enterprises needed 1-2 years (or more) lead time. In the US, I think
> they've had at least 3 years lead time, so far.
Hi Mike,
I think you may have mis-read some of my comments as being about NIST IPv6
requirements. They weren't. We're talking about TLS. They were specifically
about a NIST publication that requires certain servers to support TLS 1.2 (at a
minimum) and to be very carefully when justifying
HI Bill,
> On 2 Dec 2020, at 17:22, Bill Frantz wrote:
>
> On 12/2/20 at 5:37 AM, pgut...@cs.auckland.ac.nz (Peter Gutmann) wrote:
>
>> The fact that many of these devices are extremely critical is precisely why
>> they're never replaced or upgraded, because they can't be taken out of
>>
Thanks Barbara,
My responses are inline below.
-Original Message-
From: STARK, BARBARA H
Sent: Wednesday, December 2, 2020 11:20 AM
To: Ackermann, Michael ; 'Eliot Lear'
; 'Peter Gutmann'
Cc: 'draft-ietf-tls-oldversions-deprec...@ietf.org'
; 'last-c...@ietf.org'
; 'tls@ietf.org' ;
Hi Bill,
On Dec 2, 2020, at 11:23, Bill Frantz wrote:
> I would like to have a few more examples of "Can't be taken out of
> production".
>
> One I think I can address are heart pacemakers. These are imbedded in the
> patients chests. Upgrading them requires surgery. However, they have a
>
On Dec 2, 2020, at 11:22 AM, Bill Frantz wrote:
> One I think I can address are heart pacemakers. These are imbedded in the
> patients chests. Upgrading them requires surgery. However, they have a
> limited lifespan due to their batteries running down, I think we're talking
> about 10 years or
On 12/2/20 at 5:37 AM, pgut...@cs.auckland.ac.nz (Peter Gutmann) wrote:
The fact that many of these devices are extremely critical is precisely why
they're never replaced or upgraded, because they can't be taken out of
production.
I would like to have a few more examples of "Can't be taken
Hi Mike,
> As an Enterprise person I can say we are not well equipped to be aware of
> nor react "Nimbly" to changes such as this. Wide scope and security related
> changes can require major changes to core Business systems. This can mean
> significant time, effort and/or $$$.
I have to
On Dec 2, 2020, at 11:00 AM, Ted Lemon wrote:
> The situation right now is that it’s been known for a long time that RC4 and
> MD5 are not safe to use. Your vendors have known about this for a long time.
> If they do not have a roll-out plan for software that corrects the problem,
> you have
On Dec 2, 2020, at 9:58 AM, Ackermann, Michael wrote:
> As an Enterprise person I can say we are not well equipped to be aware of nor
> react "Nimbly" to changes such as this. Wide scope and security related
> changes can require major changes to core Business systems. This can mean
>
> it's a source of endless difficulty and
frustration due to the clash between "we can't replace or upgrade these
systems at the moment" and "there's some document that's just popped up
that says we need to take them out of production and replace them".
But in response to Eliot you
As an Enterprise person I can say we are not well equipped to be aware of nor
react "Nimbly" to changes such as this. Wide scope and security related
changes can require major changes to core Business systems. This can mean
significant time, effort and/or $$$.
The biggest barrier is that
I like what Barbara wrote.
Add words that say "think if this applies to you" and publish.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On 12/2/20 5:37 AM, Peter Gutmann wrote:
If a device can be at all critical (and even if it isn’t), then it should be
upgraded or replaced.
The fact that many of these devices are extremely critical is precisely why
they're never replaced or upgraded, because they can't be taken out of
On Wed, 2 Dec 2020 at 08:32, wrote:
> In TLS handshakes, certificate chains often take up the majority of
> the bytes transmitted.
>
> This document describes how certificate chains can be compressed to
> reduce the amount of data transmitted and avoid some round trips.
>
Round trips are only
> On 2 Dec 2020, at 11:44, Peter Gutmann wrote:
>
>
> It's actually the complete opposite, they will have every difficulty in doing
> so. You've got systems engineers whose job it is to keep things running at
> all costs, or where the effort to replace/upgrade is almost insurmountable,
> who
STARK, BARBARA H writes:
>If someone feels a strong need to ignore this in their own network, they will
>have no difficulty doing so (and have no difficulty justifying it to
>themselves and others inside their org).
It's actually the complete opposite, they will have every difficulty in doing
> On 2 Dec 2020, at 11:37, Peter Gutmann wrote:
>
> Eliot Lear writes:
>
>> If a device can be at all critical (and even if it isn’t), then it should be
>> upgraded or replaced.
>
> The fact that many of these devices are extremely critical is precisely why
> they're never replaced or
Eliot Lear writes:
>If a device can be at all critical (and even if it isn’t), then it should be
>upgraded or replaced.
The fact that many of these devices are extremely critical is precisely why
they're never replaced or upgraded, because they can't be taken out of
production.
Peter.
21 matches
Mail list logo
