On 7/16/17 7:55 AM, Salz, Rich wrote:
> I am not offended. I am saying that if it terminates the connection it
> is an endpoint not a middlebox.
Well, maybe. That's certainly the general understanding of middleboxes
(i.e that they they are not directly addressed [well, NATs, but] and
that they d
I am not offended. I am saying that if it terminates the connection it is an
endpoint not a middlebox.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On Sun, Jul 16, 2017 at 01:39:17AM +0100, Stephen Farrell wrote:
>
>
> On 15/07/17 23:55, Colm MacCárthaigh wrote:
> > So far responses on the mailing list have been saying "Don't use
> > pcap, instead run proxies".
> Sorry, but that is incorrect. Some list participants
> have said "we need pcap"
On Sat, Jul 15, 2017 at 5:39 PM, Stephen Farrell
wrote:
> On 15/07/17 23:55, Colm MacCárthaigh wrote:
> > So far responses on the mailing list have been saying "Don't use
> > pcap, instead run proxies".
> Sorry, but that is incorrect. Some list participants
> have said "we need pcap" and others h
Nick Sullivan writes:
>the Elliptic Curve variant has recently been identified as troublesome as
>well (see recent JWE vulnerability
>https://blogs.adobe.com/security/2017/03/critical-vulnerability-uncovered-in-json-encryption.html
>
>and CVE-2017-8932).
Which sorta begs the question, why was i
On 15/07/17 23:55, Colm MacCárthaigh wrote:
> So far responses on the mailing list have been saying "Don't use
> pcap, instead run proxies".
Sorry, but that is incorrect. Some list participants
have said "we need pcap" and others have said that
"no, we do not need to use packet capture." And othe
On Jul 15, 2017 12:39 PM, "Ackermann, Michael" wrote:
I would be interested in how you initiate the traces at all the hundreds
of thousands of servers and clients and how you control the flow of pcap
files back to where they need to be processed? How are users and apps
not impacted?
Current
On Sat 2017-07-15 07:38:57 +, Dobbins, Roland wrote:
>> On Jul 15, 2017, at 13:14, Daniel Kahn Gillmor
>> wrote:
>>
>> * This proposed TLS variant is *never* acceptable for use on the public
>> Internet. At most it's acceptable only between two endpoints within
>> a datacenter under a s
On Sat, Jul 15, 2017 at 12:12 PM, Salz, Rich wrote:
> > On the public internet, it's increasingly common for traffic to be MITMd
> in the form of a CDN.
>
> A CDN is not a middlebox, it is not a MITM. It is a site that the origin
> has hired to act as a "front" to it.
>
Don't take it as a criti
On Jul 15, 2017 12:33 PM, "Roland Zink" wrote:
see inline
Roland
Am 15.07.2017 um 03:40 schrieb Watson Ladd:
> On Fri, Jul 14, 2017 at 11:41 AM, Roland Dobbins
> wrote:
>
>> On 15 Jul 2017, at 1:01, Melinda Shore wrote:
>>
>> It might make sense to kick it over to ops for a discussion with p
Am 15.07.2017 um 23:14 schrieb Salz, Rich:
The terminology in RFC 3234 has evolved; language has a way of doing that.
Anyway it just depends on what you call middlebox and doesn't matter
much regarding draft-green-tls-static-dh-in-tls13-01.
I believe it does. Words matter.
So what is the d
The terminology in RFC 3234 has evolved; language has a way of doing that.
> Anyway it just depends on what you call middlebox and doesn't matter
> much regarding draft-green-tls-static-dh-in-tls13-01.
I believe it does. Words matter.
___
TLS mailing
RFC 3234 "Middleboxes: Taxonomy and Issues" says:
1.1. Terminology
The phrase "middlebox" was coined by Lixia Zhang as a graphic
description of a recent phenomenon in the Internet. A middlebox is
defined as any intermediary device performing functions other than
the normal, standard
> I think reverse proxies are middleboxes regardless if they have official
> origin
> TLS certificates. From the TLS viewpoint they may be the endpoint although
> from the HTTP viewpoint they are not.
This is wrong.
>From the HTTP viewpoint -- of the origin! -- they are not middleboxes., not
>
On Sat, Jul 15, 2017 at 10:39:16PM +0200, Roland Zink wrote:
> I think reverse proxies are middleboxes regardless if they have official
> origin TLS certificates. From the TLS viewpoint they may be the endpoint
> although from the HTTP viewpoint they are not.
CDNs go much farther than most reverse
I think reverse proxies are middleboxes regardless if they have official
origin TLS certificates. From the TLS viewpoint they may be the endpoint
although from the HTTP viewpoint they are not.
Roland
Am 15.07.2017 um 22:23 schrieb Salz, Rich:
A cache may be hired by a user, origin or even
> A cache may be hired by a user, origin or even a network operator to act as a
> "front" to the origin. Is it not a middlebox because of this? It is a
> question of
> definition if a CDN is in the middle or the endpoint :)
Yes. And I am saying that the definition doesn't include a CDN as a
mid
TLS is a two endpoint protocol. It looks like many of the use cases
describe problems with more than two endpoints but are using TLS because
it is commonly available. So should TLS be extended to be an n-party
protocol (or is this always considered wiretapping?) or should be there
another proto
A cache may be hired by a user, origin or even a network operator to act
as a "front" to the origin. Is it not a middlebox because of this? It is
a question of definition if a CDN is in the middle or the endpoint :)
Roland
Am 15.07.2017 um 21:12 schrieb Salz, Rich:
On the public internet, i
I would be interested in how you initiate the traces at all the hundreds of
thousands of servers and clients and how you control the flow of pcap files
back to where they need to be processed? How are users and apps not
impacted?
From: Watson Ladd [mailto:watsonbl...@gmail.com]
Sent: Sat
see inline
Roland
Am 15.07.2017 um 03:40 schrieb Watson Ladd:
On Fri, Jul 14, 2017 at 11:41 AM, Roland Dobbins wrote:
On 15 Jul 2017, at 1:01, Melinda Shore wrote:
It might make sense to kick it over to ops for a discussion with people whose
meat and potatoes is monitoring, management, an
On Jul 15, 2017 11:16 AM, "Ackermann, Michael" wrote:
YES!
I tried to say in my message that collecting traces on thousands, or
hundreds of thousands of hosts, is just not practical or possible. Not
to mention the administrative domain barriers to this.
We do it every day at my current em
On Jul 15, 2017 11:03 AM, "Dobbins, Roland" wrote:
On Jul 15, 2017, at 22:36, Ackermann, Michael wrote:
That being the unencrypted stream is available to the endpoints
Even where it is eventually available, they don't have the horsepower to
capture & forward.
It is always availible. How d
> On the public internet, it's increasingly common for traffic to be MITMd in
> the form of a CDN.
A CDN is not a middlebox, it is not a MITM. It is a site that the origin has
hired to act as a "front" to it.
___
TLS mailing list
TLS@ietf.org
https:
YES!
I tried to say in my message that collecting traces on thousands, or hundreds
of thousands of hosts, is just not practical or possible. Not to mention the
administrative domain barriers to this.
From: Dobbins, Roland [mailto:rdobb...@arbor.net]
Sent: Saturday, July 15, 2017 2:03 PM
To
On Jul 15, 2017, at 22:36, Ackermann, Michael
mailto:mackerm...@bcbsm.com>> wrote:
So you can collect packet trace information at thousands or nodes
This is precisely what is being posited, which is obviously unworkable.
There's a real lack of understanding of the challenges of scale, here.
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 it is eventually available, they don't have the horsepower to
capture & forward.
---
Roland Dobbins ma
On Fri, Jul 14, 2017 at 11:12 PM, Daniel Kahn Gillmor wrote:
> * This proposed TLS variant is *never* acceptable for use on the public
>Internet. At most it's acceptable only between two endpoints within
>a datacenter under a single zone of administrative control.
>
> * Forward secrec
On 7/15/17 4:01 PM, Sean Turner wrote:
> draft-ietf-tls-dnssec-chain-extension is getting moved back to Monday
> because that’s the only time Melinda can make.
No, I'm afraid that I *cannot* make it Monday, and need to have
our slot stay on Wednesday.
Melinda
signature.asc
Description: OpenPGP
Ted
Thank you for your response which appears to be an objective attempt to
1. Understand what some of our issues are.
2. Try to suggest optimal solutions. Both long and short term.
This type of positive/constructive attitude has been missing from the majority
of the List exchanges on th
On Sat, Jul 15, 2017 at 7:59 AM, Roland Dobbins wrote:
> On 15 Jul 2017, at 18:23, Daniel Kahn Gillmor wrote:
>
>> Whether it justifies a loss of security is a separate question.
>
>
> It isn't a loss of security - it's actually a net gain for security.
> Network visibility, independent of any end
On Sat, Jul 15, 2017 at 5:36 PM, Ackermann, Michael
wrote:
> 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
On Sat, Jul 15, 2017 at 7:56 AM, Roland Dobbins wrote:
> On 15 Jul 2017, at 18:19, Daniel Kahn Gillmor wrote:
>
>> I'd like to hear from the people who are doing full-take network capture
>> within their datacenters about how they protect the security of the
>> internal decryption systems.
>
>
> F
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
> On Jul 15, 2017, at 09:46, Salz, Rich wrote:
>
> encrypting-SNI and DANE/DNSSEC
draft-ietf-tls-dnssec-chain-extension is getting moved back to Monday because
that’s the only time Melinda can make.
In Yokohama, I said encrypted SNI has occupied about 27 hours of WG time so
this will make i
Travel plans were made based on the published agenda, an Matt Green will not be
on Prague on Monday. We should not discuss draft-green- without him.
Russ
> On Jul 15, 2017, at 9:46 AM, Salz, Rich wrote:
>
> I would *VERY VERY STRONGLY* like to see the static-dh draft be on Monday,
> and all
I would *VERY VERY STRONGLY* like to see the static-dh draft be on Monday, and
all the Monday topics moved to the main scheduled slot on Wednesday, even if it
means taking 5 minutes of each of encrypting-SNI and DANE/DNSSEC
Those are technical topics, far more suited to the main event then the o
I might want to try responding to the right thread. Apologies for the
noise. ;-)
Kyle
On Sat, Jul 15, 2017 at 9:08 AM, Kyle Rose wrote:
> I've rebased from the kernel master HEAD (4.12.0+), tested, and
> force-pushed the repository.
>
> Conveniently, it looks like, since the last time I searche
I've rebased from the kernel master HEAD (4.12.0+), tested, and
force-pushed the repository.
Conveniently, it looks like, since the last time I searched for one,
someone added an ECDH implementation to the kernel. That makes this a lot
easier.
Kyle
On Sat, Jul 15, 2017 at 8:18 AM, Kyle Rose wro
On Sat, Jul 15, 2017 at 7:59 AM, Roland Dobbins wrote:
> On 15 Jul 2017, at 18:23, Daniel Kahn Gillmor wrote:
>
> Whether it justifies a loss of security is a separate question.
>>
>
> It isn't a loss of security - it's actually a net gain for security.
Security isn't a scalar quantity, so ther
On 15 Jul 2017, at 18:23, Daniel Kahn Gillmor wrote:
Whether it justifies a loss of security is a separate question.
It isn't a loss of security - it's actually a net gain for security.
Network visibility, independent of any end-host, is a key requirement
for network security.
As to the s
On 15 Jul 2017, at 18:19, Daniel Kahn Gillmor wrote:
I'd like to hear from the people who are doing full-take network
capture
within their datacenters about how they protect the security of the
internal decryption systems.
Firstly, they generally aren't storing everything, forever. Most of t
On Sat 2017-07-15 07:42:58 +, Dobbins, Roland wrote:
>> On Jul 15, 2017, at 13:26, Daniel Kahn Gillmor
>> wrote:
>>
>> Could you point to an example of any regulation that requires plaintext
>> from network capture specifically?
>
> It often isn't feasible to obtain the plaintext any other w
On Sat 2017-07-15 11:55:44 +0300, Ilari Liusvaara wrote:
> Oh, and like any backdoor, this backdoor too has variety of security
> problems. And your adversaries would absolutely love to be able to
> exploit _you_ using these problems, as that would make their lives much
> easier.
I'd like to hear
I'd like to raise another point.
Static Diffie-Hellman is a cryptographically problematic construction. Not
only was it found to be fragile to implement in the prime field variant
(LogJam), the Elliptic Curve variant has recently been identified as
troublesome as well (see recent JWE vulnerability
> On Jul 15, 2017, at 16:30, Ted Lemon wrote:
>
> Roland, the reason that I made that particular comment was to try to show you
> that the position you have taken here is untenable.
It is not untenable. It is operational really.
> There is no such textbook.
As you now, that was a euphemi
I was at at least one of those presentations recently, and while it
certainly convinced me that there was a problem in the short term, it did
not convince me that the points you are making are inherent problems with
the technology. That is, the problem is not that there is no way to
achieve what
On Sat, Jul 15, 2017 at 11:05 AM, Dobbins, Roland
wrote:
> There is plenty of information on these topics available on the Internet
> today. Search engines exist. It isn't reasonable to expect a class to be
> held on the basics of network security & troubleshooting tools & techniques
> on this
> On Jul 15, 2017, at 16:05, Dobbins, Roland wrote:
>
> There is plenty of information on these topics available on the Internet
> today.
At the risk of self-replying, it should also be noted that highly informative
discussions of these challenges, & detailed presentations thereof, have take
On Jul 15, 2017, at 15:49, Ted Lemon
mailto:mel...@fugue.com>> wrote:
Can you point me to the textbook for that class, because I must have missed it!
There is plenty of information on these topics available on the Internet today.
Search engines exist. It isn't reasonable to expect a class t
On Sat, Jul 15, 2017 at 07:48:25AM +, Dobbins, Roland wrote:
>
>
> > On Jul 15, 2017, at 13:26, Daniel Kahn Gillmor
> > wrote:
> >
> > (b) we know that network capture is widely used adversarially by the
> > kinds of attackers that TLS is explicitly intended to defend
> > against?
On Sat, Jul 15, 2017 at 10:22 AM, Dobbins, Roland
wrote:
>
> I think that your first and third points are actually non-sequiturs: the
> unencrypted stream is available to the entities controlling either
> endpoint, not just the log.
>
> This assertion is both incorrect & incomplete in its scope.
>
On Jul 15, 2017, at 15:07, Ted Lemon
mailto:mel...@fugue.com>> wrote:
I think that your first and third points are actually non-sequiturs: the
unencrypted stream is available to the entities controlling either endpoint,
not just the log.
This assertion is both incorrect & incomplete in its sc
> On 15 Jul 2017, at 9:12, Daniel Kahn Gillmor wrote:
>
> On Sat 2017-07-15 05:58:31 +, Salz, Rich wrote:
>> Unless I missed the reply, I did not see any answer to my question as
>> to why it must be opt-in. Do we think evildoers will tell the truth
>> about what they are doing?
>
> Becaus
I think that your first and third points are actually non-sequiturs: the
unencrypted stream is available to the entities controlling either
endpoint, not just the log. There is no *technical *reason that in-flight
capture is required to address those two points.
Regarding your second point, this
> On Jul 15, 2017, at 14:48, Ted Lemon wrote:
>
> In the event that it is not feasible for an operator to obtain the plaintext
> of a message without the key, isn't that because they don't control either
> endpoint?
First of all, what goes on the wire is often contextually different (and
p
An update to a meeting session request has just been submitted by Stephanie
McCammon, on behalf of the tls working group.
-
Working Group Name: Transport Layer Security
Area Name: Security Area
Session Requester: Stephanie McCammon
Numbe
> On Jul 15, 2017, at 13:26, Daniel Kahn Gillmor wrote:
>
> (b) we know that network capture is widely used adversarially by the
> kinds of attackers that TLS is explicitly intended to defend
> against?
Because we know that network capture is an absolute, unquestionable requirement
in
In the event that it is not feasible for an operator to obtain the
plaintext of a message without the key, isn't that because they don't
control either endpoint? If so, why would it be their responsibility to
obtain the plaintext? It should be the responsibility of the controller
of one of the
> On Jul 15, 2017, at 13:26, Daniel Kahn Gillmor wrote:
>
> Could you point to an example of any regulation that requires plaintext
> from network capture specifically?
It often isn't feasible to obtain the plaintext any other way in a given
circumstance.
Not to mention the security & troub
> On Jul 15, 2017, at 13:14, Daniel Kahn Gillmor wrote:
>
> * This proposed TLS variant is *never* acceptable for use on the public
> Internet. At most it's acceptable only between two endpoints within
> a datacenter under a single zone of administrative control.
I would strongly attempt
62 matches
Mail list logo
