Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On 12 July 2017 at 09:59, Steve Fenter wrote: >> And if you had one an estimate for how much malware does it's own >> obfuscation or home-grown crypto in addition or instead of using TLS. >> The reason to ask is that as soon as malware does that then you >> are back to

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

To paraphrase (and forgive me for being a bit brutal here), you have no basis for what you said other than handwaves and something from a Cisco marketing presentation? That is, "the odds are better if..." is a handwave, and not clearly true. "Malware could be caught ... with multiple inspection

Re: [TLS] chairs - please shutdown wiretapping discussion...

I must admit that I mostly agree with Stephan that this kind of thing should not exist. However, it exists now, and the chairs have decided we should at least discuss it. I think there are many ways to meet the "requirements" of network monitoring and protocol debugging, and some are worse

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

> On Jul 11, 2017, at 2:15 PM, Stephen Farrell > wrote: > > > To add to Ted's clarification requests: > >> On 11/07/17 19:39, Steve Fenter wrote: >> Network security monitoring is not just monitoring traffic that >> results from communications with customers and

Re: [TLS] chairs - please shutdown wiretapping discussion...

On Tue, Jul 11, 2017 at 05:16:31PM -0400, Ted Lemon wrote: > On Jul 11, 2017, at 4:58 PM, Ted Lemon wrote: > > On Jul 11, 2017, at 4:31 PM, Stephen Farrell > > wrote: > >> I'd bet folks would invent proprietary > >>

[TLS] I-D Action: draft-ietf-tls-dtls13-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security of the IETF. Title : The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 Authors : Eric Rescorla

Re: [TLS] chairs - please shutdown wiretapping discussion...

On 11/07/17 23:09, Yoav Nir wrote: > Whether one party to a conversation (phone or IP) has the right to > share private contents with a third party is a legal matter that > varies from country to country and from state to state. I only claim > that this draft does not change the fact that is

Re: [TLS] chairs - please shutdown wiretapping discussion...

> On 12 Jul 2017, at 0:21, Stephen Farrell wrote: > > > > On 11/07/17 22:10, Yoav Nir wrote: >> If one of the parties to a conversation cooperates with the wiretap, >> this isn’t an attack. > Lemme try on this one again from a different angle. > > In classic

Re: [TLS] chairs - please shutdown wiretapping discussion...

On 11/07/17 22:10, Yoav Nir wrote: > If one of the parties to a conversation cooperates with the wiretap, > this isn’t an attack. Lemme try on this one again from a different angle. In classic telephony wiretaps the carrier does the tap. There are similar situations with TLS... In hosted

Re: [TLS] chairs - please shutdown wiretapping discussion...

> On 11 Jul 2017, at 23:54, Christian Huitema wrote: > > On 7/11/2017 1:31 PM, Stephen Farrell wrote: > >> PS: There are also genuine performance reasons why the same >> DH public might be re-used in some cases, so there would be >> false positives in a survey to consider

Re: [TLS] chairs - please shutdown wiretapping discussion...

I’d rather not deal with this whole mess. -- Regards, Uri On 7/11/2017, 16:56, "TLS on behalf of Christian Huitema" wrote: On 7/11/2017 1:31 PM, Stephen Farrell wrote: > PS: There are also genuine performance reasons why the

Re: [TLS] chairs - please shutdown wiretapping discussion...

On 7/11/2017 1:31 PM, Stephen Farrell wrote: > PS: There are also genuine performance reasons why the same > DH public might be re-used in some cases, so there would be > false positives in a survey to consider as well. Well, yes. The classic argument is performance. Saving the cost of

Re: [TLS] 2nd WGLC: draft-ietf-tls-tls13

On Tue, Jul 11, 2017 at 1:39 PM, Benjamin Kaduk wrote: > > > Another question I also relates to 0-RTT, specifically with the freshness > checks and the case where the computed expected_arrival_time is in outside > "the window" by virtue of being in the future. (See the Note: at

Re: [TLS] 2nd WGLC: draft-ietf-tls-tls13

On 07/03/2017 10:53 PM, Sean Turner wrote: > All, > > This is the 2nd working group last call (WGLC) announcement for > draft-ietf-tls-tls13 to run through July 18th. This time the WGLC is for > version -21 (https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/). Note > that this WGLC ends

Re: [TLS] chairs - please shutdown wiretapping discussion...

On 11/07/17 21:03, Ted Lemon wrote: > Ah, you mean the first time the attack happens in the wild. Well, the first time it's detected in the wild. > Sure, I > can see that, but that gains the attacker no real advantage over just > exfiltrating all the keys. I agree. I think one can

Re: [TLS] chairs - please shutdown wiretapping discussion...

On Jul 11, 2017, at 3:59 PM, Stephen Farrell wrote: > I can't see that happening. Once the first example.com > is called > out for using this, others will make their list longer or take > other approaches, e.g. use one exfiltrated private value as

Re: [TLS] chairs - please shutdown wiretapping discussion...

On Jul 11, 2017, at 3:40 PM, Stephen Farrell wrote: > It'd seem possible for a server to hold a rather long > list of re-used static DH values and unlikely for normal > clients to detect those. Bearing in mind that the current proposal is intended to perpetuate a

Re: [TLS] chairs - please shutdown wiretapping discussion...

On 11/07/17 20:11, Christian Huitema wrote: > > For various reasons, some implementations may be tempted to use static > (EC) DH private key. Using such keys lowers the security guarantees of > TLS 1.3. Adversaries that get access to the static (EC) DH private key > can now get access to the

Re: [TLS] chairs - please shutdown wiretapping discussion...

On 11/07/17 20:01, Michael StJohns wrote: > Basically, 2804 is woefully out of date with respect to the current > state of the world. As I said before I do think the authors of this draft should indeed have said that it needs to obsolete 2804 as that is required for them to get the standards

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

To add to Ted's clarification requests: On 11/07/17 19:39, Steve Fenter wrote: > Network security monitoring is not just monitoring traffic that > results from communications with customers and partners. All it > takes is for one user to click on a phishing email and there is > malware inside

Re: [TLS] chairs - please shutdown wiretapping discussion...

On 7/10/2017 3:38 PM, Stephen Farrell wrote: On 10/07/17 17:42, Colm MacCárthaigh wrote: It's clear that there is a strong distaste here for the kind of MITM being talked about It is not (only) "distaste," it is IETF policy as a result of a significant debate on wiretapping. It is a policy

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On Jul 11, 2017, at 2:39 PM, Steve Fenter wrote: > Network security monitoring is not just monitoring traffic that results from > communications with customers and partners. All it takes is for one user to > click on a phishing email and there is malware inside the

Re: [TLS] chairs - please shutdown wiretapping discussion...

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

Re: [TLS] chairs - please shutdown wiretapping discussion...

What the draft actually says is that you can install a fixed key on the server rather than generating new keys every time, and then that fixed key can also be installed on monitoring software. This is, I believe, the actual intended use of the proposal. It’s also true that you can just

Re: [TLS] chairs - please shutdown wiretapping discussion...

On Jul 10, 2017, at 5:35 PM, Stephen Farrell wrote: > Consider SMTP/TLS. Where one MTA on the path supports this. > Say it's one operated by an anti-spam company for example. > That is clearly not the sender nor recipient. > > That meets all 4 points in 2804, right? I