Thanks to Eric and Rich for your technical responses and cautionary
statements.
I do see that Florian’s use-case below points to the continued need for
enterprise inspection as once the data lands inside the data center they
become the custodians of it and are responsible for the security and
perf
…use case*
Thanks in advance,
Darin Pettis
On Mon, May 17, 2021 at 3:33 PM Darin Pettis
wrote:
> Thanks to Eric and Rich for your technical responses and cautionary
> statements.
>
> I do see that Florian’s use-case below points to the continued need for
> enterprise inspect
now, it would be great to
address the need proactively.
Respectfully,
Darin
On Mon, May 17, 2021 at 3:48 PM Stephen Farrell
wrote:
>
> Hiya,
>
> On 17/05/2021 21:33, Darin Pettis wrote:
> > TLS 1.3 did a great job regarding safety of data on the Internet. For the
> > next
Sean - thank you for the update and options on rooms.
Ben and Brett - which room should we meet in?
Initially opposed to encrypting SNI as it appears to break many services
that utilize it but curious to hear more. Thx
On Mon, Nov 13, 2017 at 9:17 AM Christian Huitema
wrote:
> On 11/12/2017
Artyom,
Thanks for mentioning the ID and you are right that draft Fenter is the
supporting problem description.
The reason it was written was to help folks understand why legitimate
internal out-of-band decryption is still needed on data once it reaches its
destination and that there isn’t a viabl
Richard Barnes and Rich Salz,
Thank you for the kind words. They are much appreciated! Best of luck to
Rich with the health concerns too.
It’s been an interesting journey with a lot of great folks. Will reply to
the issues later as I need to head out at the moment.
-Darin
On Tue, Mar 13, 20
Agreed. I know a lot of good work has gone into TLS 1.3 and having
visibility to the data once it hits the data center seems like a new
capability to the good folks working that have had TLS 1.3 in mind for the
last couple years. But to enterprises, they have visibility to their data
today and
+1
On Tue, Jul 3, 2018 at 12:08 PM Bret Jordan wrote:
> From a discussion on the PATIENT list found here:
> https://www.ietf.org/mail-archive/web/patient/current/msg00078.html
>
>
> From my personal perspective, we need to be careful with all of these
> efforts. It feels like the pendulum has
On Thu, Nov 14, 2019 at 4:43 PM Adam Langley
wrote: People on this list who manage large corporate networks may wish to
pay attention to this: while you may not have updated servers to TLS 1.3
yet, eventually it'll happen and I suspect some will find a significant
amount of things like TPMs, in wh
Hi - trying to understand the intent of this: “Don’t stick out” approach
to eSNI, now being called ECHO apparently.
About a year ago, the understanding was that eSNI would be identifiable and
that enterprises wouldn’t need to use it internally and that it would only
be used on the Internet.
Is t
are
currently aware of it) know it by. However, as the new standard goes out
into the world, a major revision number seems appropriate to recognize the
significant changes that have gone into it.
+1
Darin Pettis
U.S. BANCORP made t
+1 with Andrei.
"That SSL should never be used" is the one clear message we have so going
back to SSL would muddy those waters too much. Strong vote for staying
with TLS. It will become better known over time- especially with the
current enterprise push to deprecate all SSL versions from use
On Thu, Oct 19, 2017 at 12:27 PM Salz, Rich wrote:
> We disagree.
>
> Being able to block traffic is much less effort than pretending to be
> another identity.
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
Firs
13 matches
Mail list logo
