Sure
https://github.com/tlswg/tls13-spec/pull/1210
John
From: Eric Rescorla
Date: Wednesday, 10 February 2021 at 18:18
To: "Salz, Rich"
Cc: "resea...@bensmyth.com" , John Mattsson
, "TLS@ietf.org"
Subject: Re: [TLS] draft-ietf-tls-rfc8446bis - Security propterites -
Protection of endpoint i
Salz, Rich wrote:
>Can you explain why TLS 1.2 isn't good enough for your needs?
I think it's bad to force industries requiring visibility to use TLS 1.2 unless
it is for a limited time. TLS 1.2 is obsolete. I think the TLS WG should not
spend any more time on TLS 1.2.
I personally do not obj
On 2/11/21 at 9:01 PM, rsalz=40akamai@dmarc.ietf.org (Salz,
Rich) wrote:
I would just like to recognize that there are some situations where it isn't
needed.
Can you explain why TLS 1.2 isn't good enough for your needs?
In my experience, there are many attacks that aren't anticipated
Hi,
I agree with Bill. Keeping confidentiality in all TLS/1.3 connections is
future proofing.
Supposedly analyzing and then leaving confidentiality out invites future
attacks.
Cheers,
- Ira
On Thu, Feb 11, 2021 at 9:56 AM Bill Frantz wrote:
> On 2/11/21 at 9:01 PM, rsalz=40akamai@dmarc.i
John,
Thanks for raising this topic I think it's important. I agree with you on
the technical situation. As you say, we should be encouraging people to
move to TLS 1.3, and NULL encryption cipher suites do not provide all the
guarantees that TLS 1.3 is intended to deliver. [0].
I also agree with
Hi Stephen,
I don't have quick and simple guide for how the systems are built sadly. I will
say in this context I am representing a group that defines industrial comms
called ODVA (https://www.odva.org/), although am drawing on my experience in
Industrial Communications beyond just ODVA. Perhap
Hi John, Eric,
Thanks for the input. We will certainly make some changes to the draft
regarding the inspection case. However, I can’t support removing the
performance/latency information completely, as I have heard from those who have
this very concern. That said, we will edit the language to m
On Thu, Feb 11, 2021 at 11:13 AM Jack Visoky
wrote:
> Hi John, Eric,
>
>
>
> Thanks for the input. We will certainly make some changes to the draft
> regarding the inspection case. However, I can’t support removing the
> performance/latency information completely, as I have heard from those who
>
Hi Eric,
I don’t have numbers offhand but I will say that many platforms I have
experience with have some sort of HW support, and might include things like
DMA. In these cases ChaCha20-Poly1305 is way behind in terms of performance
(which is expected as I believe it was mainly targeted to softw
On Thu, Feb 11, 2021 at 3:08 PM Jack Visoky
wrote:
> Hi Eric,
>
>
>
> I don’t have numbers offhand but I will say that many platforms I have
> experience with have some sort of HW support, and might include things like
> DMA. In these cases ChaCha20-Poly1305 is way behind in terms of performance
+1 to Eric.
Re. GCM – one problem it has is catastrophic failure if nonce is mis-/re-used.
Which is why I’d rather see AES-GCM-SIV.
--
Regards,
Uri
There are two ways to design a system. One is to make is so simple there are
obviously no deficiencies.
The other is to make it so comple
Yes agreed, and also when you put this into a product there’s usually a whole
bunch more considerations than just the raw numbers of how fast the hardware
can execute a given crypto primitive. However I wanted to find an example that
was public information since companies are often loath to shar
12 matches
Mail list logo
