While I agree that TLSv1.0 and TLSv1.1 should be avoided as much as
possible, I believe this document fails to consider that there are old
systems that are still in use that cannot be upgraded. Strict
implementation of the MUST NOT rules in this document can even prevent
those systems from be
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 invali
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 content
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 fr
On 11/30/20 7:29 PM, Peter Gutmann wrote:
So I think the text should include wording to the effect that it applies to
public Internet use but not to embedded/SCADA/etc for which very different
considerations apply.
I've been thinking something like this also. But IMO there are still
valid ca
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 d
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
producti