On 15/12/2020 12:51, tom petch wrote:
On 14/12/2020 16:36, tom petch wrote:
On 14/12/2020 14:53, Stephen Farrell wrote:
On 10/11/2020 11:33, Stephen Farrell wrote:
On 10/11/2020 11:30, tom petch wrote:
Perhaps a second look at the algorithm
to work out why these got missed to get a fix on
Hiya,
On 15/12/2020 12:51, tom petch wrote:
I see RFC5953, RFC6353 have been added. RFC5953 is obsoleted so should
it be listed in 1.1 in the list of RFC already obsoleted, the one that
start with RFC5101?
Argh/oops:-)
I just posted -11 fixing that.
Thanks,
S.
On 14/12/2020 16:36, tom petch wrote:
On 14/12/2020 14:53, Stephen Farrell wrote:
Hi Tom,
On 10/11/2020 11:33, Stephen Farrell wrote:
On 10/11/2020 11:30, tom petch wrote:
Perhaps a second look at the algorithm
to work out why these got missed to get a fix on how many more there
may be.
On 14/12/2020 14:53, Stephen Farrell wrote:
Hi Tom,
On 10/11/2020 11:33, Stephen Farrell wrote:
On 10/11/2020 11:30, tom petch wrote:
Perhaps a second look at the algorithm
to work out why these got missed to get a fix on how many more there may be.
Sure, that's reasonable. (Mightn't
Hi Tom,
On 10/11/2020 11:33, Stephen Farrell wrote:
On 10/11/2020 11:30, tom petch wrote:
Perhaps a second look at the algorithm
to work out why these got missed to get a fix on how many more there may be.
Sure, that's reasonable. (Mightn't be today.)
Just did that check by comparing
Bill Frantz writes:
>I would like to have a few more examples of "Can't be taken out of
>production".
Well as a bit of a generalisation anything running an RTOS is likely to be
something that can't be taken out of production, and certainly wouldn't be
taken out of production for something as
I disagree here as those other implementations just need to make their own
business risk decisions and put in place an exception process. One option in
the risk decision process is to accept risk, you can also mitigate, eliminate,
or transfer the risk.
Best regards,
Kathleen
Sent from my
Having risk management experience as well as policy establishment and
enforcement, I would rather see the clear notification that something is not
secure. Then the organization makes the decision to take that risk based on
likelihood/impact considerations. This factors in risk tolerance and
Nick Hilliard writes:
>
> What's relevant to the IETF is that it needs to make sound technical
> recommendations about the usability and appropriateness of standards.
> If organisations choose not to keep supporting some or all of their
> product lines, this shouldn't impact the IETF's
Ted Lemon wrote on 05/12/2020 01:32:
Of course no product has infinite lifetime, but lots of iot stuff is
expected to be in the walls for 30 years. Radiology equipment lasts
decades. Etc.
yip, this is one of the reasons that medical and other certified
equipment (e.g. military, industrial, etc)
On Fri, Dec 4, 2020 at 4:18 PM Nick Hilliard wrote:
>
> This shouldn't stop the IETF from formally deprecating standards which
> are known to be dysfunctional.
>
The disconnect might be around the term "operator", which some might read
as "wiretap enthusiast".
The IETF should of course
On Dec 4, 2020, at 19:17, Nick Hilliard wrote:
> people don't necessarily buy stuff that's not ungradeable. They buy stuff
> which has a support lifetime of finite duration.
Same thing. If you’re serious about business continuity, you have an
arrangement with the vendor about what happens if
Ted Lemon wrote on 04/12/2020 22:47:
Why do people buy stuff that’s not upgradeable? Probably because the
manufacturer doesn’t give them a choice, and there’s no way to force the
choice. The recent discussions about legally requiring
firmware-upgradeable IoT devices (e.g. in Singapore) is
eprecating TLSv1.0 and TLSv1.1)
to Best Current Practice
[External email]
On Dec 4, 2020, at 3:00 PM, Ackermann, Michael wrote:
> 1. Enterprises do not expect nor want IETF to be responsible for their
> planning for changes in technology.But when IETF decides to change
> pro
On Dec 4, 2020, at 5:29 PM, Ackermann, Michael wrote:
> Regards to the 12 years vs 1-2.12 years is probably too long for just
> about anything, once it is determined to be a business need. But that is
> the key first step. Then it will likely be a minimum of 1-2 years to get
> the
: Stephen Farrell ; BRUNGARD, DEBORAH A
; Rob Sayre ; Peter Gutmann
; Watson Ladd ; Eliot Lear
; last-c...@ietf.org; tls-cha...@ietf.org;
draft-ietf-tls-oldversions-deprec...@ietf.org; STARK, BARBARA H
; tls@ietf.org
Subject: Re: [Last-Call] [TLS] Last Call:
(Deprecating TLSv1.0 and TLSv1.1
On Dec 4, 2020, at 3:00 PM, Ackermann, Michael wrote:
> 1. Enterprises do not expect nor want IETF to be responsible for their
> planning for changes in technology.But when IETF decides to change
> protocols or deprecate existing technology of any sort, it would be
> beneficial to all if
: [Last-Call] [TLS] Last Call:
(Deprecating TLSv1.0 and
TLSv1.1) to Best Current Practice
[External email]
As Barbara builds her confidence for the IETF list and while we have
Mike's attention-
Mike, you commented "More, it is a lack of understanding of how things
work within Enterpris
Michael, fundamentally the disconnect here seems to be that the IETF could ever
be responsible for helping businesses to figure out how to plan for changes in
technology _other_ than by doing work like this. Deprecating old versions of
protocols is exactly what the IETF should be doing. This is
On Fri, 4 Dec 2020 14:20 BRUNGARD, DEBORAH A
mailto:db3...@att.com>> wrote:
> As Stephen said, couldn?t resist, first cup of coffee-
>
> That?s always the question of the day- what is an operator, vendor,
> researcher?
>
> I know ?academia? on this list that have more operational experience
rg
Subject: Re: [Last-Call] [TLS] Last Call:
(Deprecating TLSv1.0 and TLSv1.1)
to Best Current Practice
Hi Michael,
On 04/12/2020 15:14, Ackermann, Michael wrote:
> We (Enterprises) are not as involved as we should be in IETF, and that
> is our own problem/fault. What I think irrit
;
last-c...@ietf.org; tls-cha...@ietf.org; tls@ietf.org
Subject: Re: [Last-Call] [TLS] Last Call:
(Deprecating TLSv1.0 and TLSv1.1)
to Best Current Practice
[External email]
As Stephen said, couldn’t resist, first cup of coffee-
That’s always the question of the day- what is an operator, vendor
Hi Michael,
On 04/12/2020 15:14, Ackermann, Michael wrote:
We (Enterprises) are not as involved as we should be in IETF, and
that is our own problem/fault. What I think irritates people like
Stephen,
I'm not irritated at all:-)
is that there have been situations where we finally try to
s-oldversions-deprec...@ietf.org<mailto:draft-ietf-tls-oldversions-deprec...@ietf.org>'
mailto:draft-ietf-tls-oldversions-deprec...@ietf.org>>;
'tls@ietf.org<mailto:tls@ietf.org>' mailto:tls@ietf.org>>
Subject: RE: [Last-Call] [TLS] Last Call:
(Deprecating TLSv1.0 and TL
; 'Eliot Lear' 40cisco@dmarc.ietf.org>; 'last-c...@ietf.org' ; '
> tls-cha...@ietf.org' ; '
> draft-ietf-tls-oldversions-deprec...@ietf.org' <
> draft-ietf-tls-oldversions-deprec...@ietf.org>; 'tls@ietf.org' <
> tls@ietf.org>
> Subject: RE: [Last-Call] [TLS]
...@ietf.org' ;
'tls-cha...@ietf.org' ;
'draft-ietf-tls-oldversions-deprec...@ietf.org'
; 'tls@ietf.org'
Subject: RE: [Last-Call] [TLS] Last Call:
(Deprecating TLSv1.0 and TLSv1.1)
to Best Current Practice
[External email]
As Barbara builds her confidence for the IETF list and while we have
On Thu, Dec 3, 2020 at 4:54 PM Stephen Farrell
wrote:
>
> There are of course a set of networks that have difficulty
> in managing and updating the systems that make up their
> networks.
>
That's true, but attackers run on their own schedule.
I don't think IETF documents should include caveats
(Even though this sub-thread has no effect on the draft, I
couldn't resist:-)
On 03/12/2020 23:53, Rob Sayre wrote:
The enterprise perspective is not usually considered or understood at IETF
I think that perspective is both considered and understood, but not usually
accommodated.
I think
On Thu, Dec 3, 2020 at 2:38 PM Ackermann, Michael
wrote:
> The enterprise perspective is not usually considered or understood at IETF
>
I think that perspective is both considered and understood, but not usually
accommodated.
I can't even imagine shipping TLS 1.2 for anything at this point,
f.org'
; 'tls@ietf.org' ; 'tls-cha...@ietf.org'
Subject: RE: [TLS] [Last-Call] Last Call:
(Deprecating TLSv1.0 and TLSv1.1)
to Best Current Practice
[External email]
Ow! Mike is my friend. Don't go dissing my friend!
I think the problem in communication we've just experienced is becau
ls-cha...@ietf.org' ;
'draft-ietf-tls-oldversions-deprec...@ietf.org'
; 'tls@ietf.org'
Subject: Re: [Last-Call] [TLS] Last Call:
(Deprecating TLSv1.0 and TLSv1.1)
to Best Current Practice
Ow! Mike is my friend. Don't go dissing my friend!
I think the problem in communication we've just experi
Ow! Mike is my friend. Don't go dissing my friend!
I think the problem in communication we've just experienced is because Mike
strayed away from Last Call discussion on a specific document, to
asking/discussing a more general question of how IETF can better communicate
with enterprises and
On Wed, Dec 2, 2020, 3:18 PM Ackermann, Michael wrote:
>
> 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
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
...@ietf.org'
Subject: RE: [TLS] [Last-Call] Last Call:
(Deprecating TLSv1.0 and TLSv1.1)
to Best Current Practice
[External email]
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
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
>>
' ; 'tls-cha...@ietf.org'
Subject: RE: [TLS] [Last-Call] Last Call:
(Deprecating TLSv1.0 and TLSv1.1)
to Best Current Practice
[External email]
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 t
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
rg
Subject: Re: [TLS] [Last-Call] Last Call:
(Deprecating TLSv1.0 and TLSv1.1)
to Best Current Practice
[External email]
> 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 sy
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 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.
> >I would suggest the strong, unambiguous statement with explanation
> for
> >why the statement is being made.
>
> Yes.
>
> >There is no need to describe (possible) exceptions.
>
> My opinion is exactly the opposite. Do describe the exceptions, as precisely
> and
>I would suggest the strong, unambiguous statement with explanation for
>why the statement is being made.
Yes.
>There is no need to describe (possible) exceptions.
My opinion is exactly the opposite. Do describe the exceptions, as precisely
and unambiguously as you
> It is incredibly difficult to draw a line so precisely as to where the threat
> to a
> device begins and ends, given the wide range of deployment scenarios. If a
> device can be at all critical (and even if it isn’t), then it should be
> upgraded or
> replaced. Better that this be out there
> On 1 Dec 2020, at 16:21, Salz, Rich wrote:
>
>> And how will the people who can ignore it know that it's OK for them to do
>> so?
>
> Well, frankly, that's not our problem. If someone is going to blindly insist
> on RFC conformance and doesn't recognize the wording that says "might not
>And how will the people who can ignore it know that it's OK for them to do
> so?
Well, frankly, that's not our problem. If someone is going to blindly insist
on RFC conformance and doesn't recognize the wording that says "might not apply
to you" ... well, so be it.
I am more concerned
It is incredibly difficult to draw a line so precisely as to where the threat
to a device begins and ends, given the wide range of deployment scenarios. If
a device can be at all critical (and even if it isn’t), then it should be
upgraded or replaced. Better that this be out there in its
Salz, Rich writes:
>The right thing to do, from a security viewpoint, is DO NOT USE TLS 1.0 OR
>TLS 1.1 If you have special circumstances, then do not follow the RFC (once
>published).
And how will the people who can ignore it know that it's OK for them to do so?
Once it's published, everyone
On 12/1/20, 4:29 AM, "Peter Gutmann" wrote:
Stephen Farrell writes:
>That said, if someone had words to suggest that might garner consensus,
that
>would be good.
I think all it needs is something along the lines of "This BCP applies to
TLS
as used on the public
The right thing to do, from a security viewpoint, is DO NOT USE TLS 1.0 OR TLS
1.1 If you have special circumstances, then do not follow the RFC (once
published).
If not following the RFC makes some people uncomfortable, that’s their bug. We
should not water down our recommendations.
On 12/1/20 4:29 AM, Peter Gutmann wrote:
I think all it needs is something along the lines of "This BCP applies to TLS
as used on the public Internet [Not part of the text but meaning the area that
the IETF creates standards for].
Not specifically relevant to this draft, but: Is it actually
Stephen Farrell writes:
>That said, if someone had words to suggest that might garner consensus, that
>would be good.
I think all it needs is something along the lines of "This BCP applies to TLS
as used on the public Internet [Not part of the text but meaning the area that
the IETF creates
I haven't followed all the nuances of this discussion, but it seems to boil
down to use of "MUST NOT" when certain "EXCEPTIONS MAY" exist for private
enterprise running legacy kit, which makes decision makers anxious, since
they don't want responsibility for something they "MUST NOT" do: A
Hiya,
On 01/12/2020 00:29, Peter Gutmann wrote:
However I think your comment points out the overall problem:
usage in web, mail and OSes
This means there's no consideration at all of use in embedded/SCADA/whatever.
I wouldn't agree with "no consideration" but guess we might
agree about
Nick Lamb writes:
>You won't get such a certificate from a public CA (presumably meaning a CA
>issuing in the Web PKI).
Well, you're less likely to now thanks to CT. Before that public CAs issued
huge numbers of them, including EV certs.
>They're subject to the CA/B Baseline Requirements
On Fri, 27 Nov 2020 23:43:42 -0500
Keith Moore wrote:
> I'm aware of that. But what really is the point of a cert
> (especially one issued by a public CA) that has an RFC1918 address as
> its subject? Not that it matters that much because the vast majority
> of sites using embedded systems
On 11/27/20 11:58 PM, Eric Rescorla wrote:
To clarify, my suggestion was that https with TLS < 1.2 be treated as
insecure, not as neither secure nor insecure or any kind of "in
between".
Well, the problem is that it is secure from the perspective of the
site author
but insecure
Well, I think our respective positions are clear, so I'll just limit myself
to one point.
On Fri, Nov 27, 2020 at 8:43 PM Keith Moore
wrote:
> >
> >
> > > > I'm not sure what clients you're talking about, but for the clients
> > > > I am aware of, this would be somewhere between a broken
On 11/27/20 11:30 PM, Eric Rescorla wrote:
Well, I can't speak to how it sounds to you, but it's not a marketing
argument but rather a security one. This is easiest to understand in
the context of the Web, where you have a reference that contains one
bit: http versus https,and all https
Hi Keith,
Thanks for your note. I think it's clear we see things differently,
and I don't think it's that useful to get into an extended back and
forth on those points. Accordingly I've done a fair bit of trimming to
focus on the points where I think you may have misunderstood me
(perhaps due to
On 11/27/20 9:53 PM, Eric Rescorla wrote:
Keith,
Thanks for your note. Most of the general points you raise here were
discussed
when the TLS WG decided to move forward with this draft [0], though
perhaps some of that is not reflected in the text. Of course that
doesn't make this points
Keith,
Thanks for your note. Most of the general points you raise here were
discussed
when the TLS WG decided to move forward with this draft [0], though
perhaps some of that is not reflected in the text. Of course that
doesn't make this points invalid, so I'll try to summarize my
view of the
On 10/11/2020 16:35, Sean Turner wrote:
Sorry for any confusion introduced as a result of this typo. DTLS 1.0
is RFC4347 not RFC 6347; RFC 6347 is DTLS 1.2.
Ah, mea-culpa then (even if someone else suggested
the change I should've spotted that;-). I'll look
back at the script algorithm in any
On 10/11/2020 11:30, tom petch wrote:
Perhaps a second look at the algorithm
to work out why these got missed to get a fix on how many more there may be.
Sure, that's reasonable. (Mightn't be today.)
Cheers,
S.
OpenPGP_0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
76 matches
Mail list logo
