But I thought retired people were supposed to sleep in?
From: TLS On Behalf Of Dennis Jackson
Sent: Wednesday, March 6, 2024 7:39 AM
To: tls@ietf.org
Subject: Re: [TLS] draft-ietf-tls-cert-abridge Update
[External email]
Hi Panos,
On 05/03/2024 04:14, Kampanakis, Panos wrote:
Hi Den
ent: Friday, December 4, 2020 3:11 PM
To: Ackermann, Michael
Cc: 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: [La
does, I hope you
can be involved, as you are a greatly respected member of the IETF community
and could add a lot to that discussion.
Thanks again for taking this seriously!
Mike
-Original Message-
From: Ted Lemon
Sent: Friday, December 4, 2020 12:21 PM
To: Ackermann, Michae
al Message-
From: Stephen Farrell
Sent: Friday, December 4, 2020 10:22 AM
To: Ackermann, Michael ; BRUNGARD, DEBORAH A
; Rob Sayre
Cc: Eliot Lear ; Peter Gutmann
; STARK, BARBARA H ; Watson Ladd
; draft-ietf-tls-oldversions-deprec...@ietf.org;
last-c...@ietf.org; tls-cha...@ietf.org; tls@ietf.o
think that is what Barbara
suggested taking off to the other list.
Thanks
Mike
From: BRUNGARD, DEBORAH A
Sent: Friday, December 4, 2020 9:20 AM
To: Rob Sayre ; Ackermann, Michael
Cc: Eliot Lear ; Peter Gutmann
; STARK, BARBARA H ; Watson Ladd
; draft-ietf-tls-oldversions-deprec...@ietf.org
Once again I really appreciate your constructive comments and information.
Mike
-Original Message-
From: BRUNGARD, DEBORAH A
Sent: Thursday, December 3, 2020 5:10 PM
To: STARK, BARBARA H ; 'Watson Ladd' ;
Ackermann, Michael
Cc: 'Peter Gutmann' ; &#x
Therefore I would like the problem to not be
> acknowledged.
-Original Message-
From: STARK, BARBARA H
Sent: Thursday, December 3, 2020 12:03 PM
To: 'Watson Ladd' ; Ackermann, Michael
Cc: 'Eliot Lear' ; 'Peter Gutmann'
; 'draft-ietf-tls-oldversions-de
but someone should, IMHO.
Thanks
Mike
-Original Message-
From: STARK, BARBARA H
Sent: Wednesday, December 2, 2020 1:52 PM
To: Ackermann, Michael ; 'Eliot Lear'
; 'Peter Gutmann'
Cc: 'draft-ietf-tls-oldversions-deprec...@ietf.org'
; 'last-c..
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'
; 'l
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 this
This should not be dismissed as small segments of industries.This
represents ubiquitous use cases at all large organizations in Insurance, Health
Care, Banking, Automotive and many others.
We as the IETF should not lightly dismiss such significant numbers and volume,
even (or especially), i
+1
From: TLS On Behalf Of Bret Jordan
Sent: Tuesday, July 23, 2019 5:52 PM
To: Sean Turner
Cc: Tony Arcieri ; tls@ietf.org
Subject: Re: [TLS] TLS Impact on Network Security draft updated
ALERT This email was sent from a source external to BCBSM/BCN.
DO NOT CLICK links or attachments unless yo
+1
And I would add that the pervasive effects of encryption are not limited to
security of systems, but limit the abilities of other system management,
monitoring and diagnostic platforms as well.
From: TLS On Behalf Of Mark O
Sent: Tuesday, July 23, 2019 4:28 PM
To: tls@ietf.org
Subject: Re:
+1
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Bret Jordan
Sent: Tuesday, July 3, 2018 1:08 PM
To: tls@ietf.org
Subject: [TLS] Encrypted SNI
From a discussion on the PATIENT list found here:
https://www.ietf.org/mail-archive/web/patient/current/msg00078.html
From my personal perspecti
Good point Yoav.
And this positive side effect holds true in the health care and insurance
industries as well, and is not an accident. It is one of the primary reasons
this monitoring is performed.
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Yoav Nir
Sent: Thursday, March 15, 2018 12
etition to the list. But
suffice to say it is well beyond PCI for most Enterprises.
-Original Message-
From: Ted Lemon [mailto:mel...@fugue.com]
Sent: Tuesday, March 13, 2018 4:28 PM
To: Ackermann, Michael
Cc: nalini elkins ;
Subject: Re: [TLS] TLS@IETF101 Agenda Posted
On Mar 13
I think that most Enterprises are not espousing any conversations "how can we
avoid making any changes?"
But we would seek to avoid unnecessary, wholesale, infrastructure
architectural changes.
We want to stay with standards wherever/whenever possible and keep the number
of standards to the low
+1 !
Well stated.
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of nalini elkins
Sent: Tuesday, March 13, 2018 11:59 AM
To: Colm MacCárthaigh
Cc:
Subject: Re: [TLS] TLS@IETF101 Agenda Posted
Stephen (and TLS group)
We need to look at the bigger picture.
The TLS working group has been con
" idea of a client extension was added based on feedback at the Prague meeting
in order to help prevent the protocol from being used over the public Internet,
by preventing the protocol from being used without the client's knowledge."
Responding ONLY to the above sentence, as I agree with Step
- repeating
points already countered is just disruptive noise, sorry.
Thanks,
S.
On 25/10/17 01:41, Ackermann, Michael wrote:
> Excellent points/questions and I just wanted to add that your final example,
> regarding hosting providers actually being a MitM, is EXTREMELY prevale
Excellent points/questions and I just wanted to add that your final example,
regarding hosting providers actually being a MitM, is EXTREMELY prevalent in
Enterprises today and is a management/ monitoring issue specifically pointed
out by Steven Fenter in his presentation to the TLS WG in Pragu
...@akamai.com]
Sent: Tuesday, October 24, 2017 9:30 AM
To: Ackermann, Michael
Cc: tls@ietf.org
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
➢ The objective is to be passively observe, out of band and not to be a
MitM or modify/inject text.Just as we all do today
NO
The objective is to be passively observe, out of band and not to be a MitM or
modify/inject text.Just as we all do today.
-Original Message-
From: Benjamin Kaduk [mailto:bka...@akamai.com]
Sent: Monday, October 23, 2017 6:33 PM
To: Ackermann, Michael ; Tony Arcieri
; Adam
This can be solved without changes to the protocol or a standardized “backdoor”
- and is being done today by at least some enterprises.
Having worked (and presently working) for more than one company of this nature,
in the payments business no less, I would like to restate that it's incredibly
ssage-
From: Salz, Rich [mailto:rs...@akamai.com]
Sent: Friday, October 20, 2017 12:57 PM
To: Ackermann, Michael ; Stephen Farrell
; Darin Pettis ; tls@ietf.org
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
So it sounds like we are in agreement that continuing to us
statements are not at all constructive,
germane nor worthy of response.
From: Ted Lemon [mailto:mel...@fugue.com]
Sent: Monday, October 23, 2017 1:45 PM
To: Ackermann, Michael
Cc: Salz, Rich ; tls@ietf.org
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
On Oct 23, 2017, at 1
because the new version of the
existing protocol is not backwards compatible, which is something we have come
to expect.
From: Ted Lemon [mailto:mel...@fugue.com]
Sent: Monday, October 23, 2017 12:44 PM
To: Ackermann, Michael
Cc: Salz, Rich ; tls@ietf.org
Subject: Re: [TLS] Publication of draft-rhrd
...@akamai.com]
Sent: Monday, October 23, 2017 12:27 PM
To: Ackermann, Michael ; Ted Lemon
Cc: tls@ietf.org
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
* I am merely trying to understand if there are any constructive
suggestions amongst all these discussions, that we should
From: Ted Lemon [mailto:mel...@fugue.com]
Sent: Monday, October 23, 2017 11:41 AM
To: Ackermann, Michael
Cc: Steve Fenter ; tls@ietf.org
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
On Oct 23, 2017, at 10:35 AM, Ackermann, Michael
mailto:mackerm...@bcbsm.com>> wrote:
I
I have.
I was only asking what your opinion was, based on that statement in your reply.
From: Ted Lemon [mailto:mel...@fugue.com]
Sent: Sunday, October 22, 2017 7:44 PM
To: Ackermann, Michael
Cc: Steve Fenter ; tls@ietf.org
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
On
I am willing to bet that his point was not at all that Enterprises could switch
quickly, as you say in your response.
We do not do ANYTHING quickly.
I believe his point was that because we do not move quickly, we need to
prepare as much in advance as possible, and assure that the base protocol
So it sounds like we are in agreement that continuing to use TLS 1.2 is not a
viable long term alternative.
-Original Message-
From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie]
Sent: Friday, October 20, 2017 12:14 PM
To: Ackermann, Michael ; Salz, Rich ;
Darin Pettis ; tls
Expressly reacting to the viability of continuing to use TLS1.2 forever.
As a network person, this sounds a little like suggesting that if we feel
there are operational shortcomings in IPv6, then we should just plan to stay
with IPv4, forever.
And that approach may even be viable for the shor
Ted
You may be aware that most enterprises have been migrating away from 3270 for
20 years or more. Very little still exists. What little does exist is
usually implemented via tn3270. In the browser scenario you describe I would
expect the Server side to be a tn3270 server, but you will
: Ackermann, Michael
Cc: Matthew Green ; Dobbins, Roland
; IETF TLS
Subject: RE: [TLS] draft-green-tls-static-dh-in-tls13-01
On Jul 15, 2017 12:39 PM, "Ackermann, Michael"
mailto:mackerm...@bcbsm.com>> wrote:
I would be interested in how you initiate the traces at all the hundre
It seems that us Enterprise folks have not been clear.
Every Enterprise I know has invested HEAVILY in infrastructures that tap,
transport and process terabytes of packet trace or .pcap data every day.
This is huge and omnipresent in all large Enterprise environments.
AND IT WORKS! For
: Saturday, July 15, 2017 3:26 PM
To: Ackermann, Michael
Cc: Matthew Green ; Dobbins, Roland
; IETF TLS
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
On Jul 15, 2017 11:16 AM, "Ackermann, Michael"
mailto:mackerm...@bcbsm.com>> wrote:
YES!
I tried to say in my message
To: Ackermann, Michael
Cc: Ted Lemon ; IETF TLS ; Matthew Green
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
On Jul 15, 2017, at 22:36, Ackermann, Michael
mailto:mackerm...@bcbsm.com>> wrote:
That being the unencrypted stream is available to the endpoints
Even where
: Saturday, July 15, 2017 12:19 PM
To: Ackermann, Michael
Cc: Dobbins, Roland ; IETF TLS ; Matthew
Green
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
On Sat, Jul 15, 2017 at 5:36 PM, Ackermann, Michael
mailto:mackerm...@bcbsm.com>> wrote:
Your first sentence illustrates the disc
Most of us have Key Vaults and related management systems that are so (OVER in
my opinion) secure, that this has never been a problem for us (in reality
NOT in theory or conversation).
-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Daniel Kahn Gillmor
Sen
Ted
Your first sentence illustrates the disconnect between the Enterprise
perspective and what many at IETF are saying.
That being the unencrypted stream is available to the endpoints. IT IS NOT.
When you run a packet trace at the endpoint, you will see encrypted payloads
and will need th
I am not certain if I speak for all Enterprise individuals involved in this
discourse or not.
But I would like to endorse what Ted is saying.
As much fun as this debate has become (not), Enterprises originally raised
this issue to the TLS-WG, to engage their considerable expertise, and to help
...@gmail.com]
Sent: Monday, July 10, 2017 4:11 PM
To: Ackermann, Michael
Cc: Polk, Tim (Fed) ; tls@ietf.org
Subject: Re: [TLS] chairs - please shutdown wiretapping discussion...
On Jul 10, 2017 8:46 AM, "Ackermann, Michael"
mailto:mackerm...@bcbsm.com>> wrote:
+1 !!!
And
Fo
]
Sent: Monday, July 10, 2017 3:37 PM
To: Ackermann, Michael ; Polk, Tim (Fed)
; tls@ietf.org
Subject: Re: [TLS] chairs - please shutdown wiretapping discussion...
On 10/07/17 16:30, Ackermann, Michael wrote:
> Given the above scenario, I do not understand how this can be construed
+1 !!!
And
For the enterprise situations, we typically own, operate and manage the
involved "Facilities":
The Servers
The Applications
The Networks
The Keys
The Data
and in Many cases the clients as well
Given the above scenario, I do not understand how this can be construed as
"Wiretapping".
+1
From: Yoav Nir [mailto:ynir.i...@gmail.com]
Sent: Saturday, July 8, 2017 8:36 AM
To: Timothy Jackson
Cc: Ackermann, Michael ; Watson Ladd
; Christian Huitema ; tls@ietf.org
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
On 8 Jul 2017, at 6:18, Timothy Jackson
mailto:tjack
my statement that converting everything to clear text is not viable
in my world(s).
-Original Message-
From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie]
Sent: Saturday, July 8, 2017 5:09 AM
To: Ackermann, Michael ; Watson Ladd
; Christian Huitema
Cc: tls@ietf.org
affordable. Not to mention the introduction of manifold new potential points
of failure.
From: Timothy Jackson [mailto:tjack...@mobileiron.com]
Sent: Friday, July 7, 2017 11:19 PM
To: Ackermann, Michael ; Watson Ladd
; Christian Huitema
Cc: tls@ietf.org
Subject: Re: [TLS] draft-green-tls-static
Converting all session traffic to clear text is not a viable alternative for
ANY enterprises or industries that I am aware of. In particular those in
financial sectors.
Security policies, legislation and in many cases just good practice would not
allow for this.
We are compelled by these fac
Matt
This document is extremely well written and describes the needs of enterprises
well, IMHO.I believe and have heard, there are similar needs beyond the
enterprise realm, but since we are the only ones formally expressing concerns,
so be it.
The detail on the implementation, as well
Feel better Jason!
-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Salz, Rich
Sent: Thursday, May 4, 2017 10:58 AM
To: m...@sap.com
Cc: Natasha Rooney ; tls@ietf.org
Subject: Re: [TLS] trusted_ca_keys
> There is some wording in PKIX and X.509 which creates the im
+2
On removing all references to SSL.
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of darin.pet...@usbank.com
Sent: Friday, December 2, 2016 1:55 PM
To: Andrei Popov
Cc: TLS ;
Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS*
+1 with Andrei.
"That SSL should never be used" is the o
+1 On Ted's comments.
In Enterprise circles TLS is an unknown acronym and as painful as it is, we
must usually refer to it as SSL, before anyone knows what we are talking
about.
Software products are guilty too. Parameter fields frequently reference SSL.
:(
-Original Message---
Sent: Saturday, September 24, 2016 10:10 PM
To: Ackermann, Michael ; Pawel Jakub Dawidek
; tls@ietf.org
Subject: RE: [TLS] Industry Concerns about TLS 1.3
> This lack of scope, depth and detail [in MITM infrastructures] are
> what drove us to install the packet collection infrastructures
t impossible), it has higher CPU demands, it increases
handshake times. This is the price we pay for a better security and in my
opinion it is acceptable.
W dniu 9/23/16 o 09:49, Ackermann, Michael pisze:
> Without re stating the original message from the bank coalition, which
> states
ginal Message-
From: Watson Ladd [mailto:watsonbl...@gmail.com]
Sent: Friday, September 23, 2016 11:44 AM
To: Ackermann, Michael
Cc: noloa...@gmail.com; tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3
On Fri, Sep 23, 2016 at 8:31 AM, Ackermann, Michael
wrote:
> I am no
Walton [mailto:noloa...@gmail.com]
Sent: Friday, September 23, 2016 10:55 AM
To: Ackermann, Michael
Cc: BITS Security ; tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3
On Fri, Sep 23, 2016 at 10:46 AM, Ackermann, Michael
wrote:
> From the perspective an Enterprise that runs the
>From the perspective an Enterprise that runs these applications and has
>invested HEAVILY in the debugging networks.
The reason we are debugging these networks is so that "The 5-6 order of
magnitude of folks using them" will have good service. If they do not, they
will consider com
58 matches
Mail list logo
