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

On Sat, Jul 8, 2017 at 11:31 AM, Paul Turner wrote: > > The Internet Draft describes the use of static (EC)DHE for traffic > entirely inside enterprise networks and intends to clearly state that it > should not be used for "information passed across the Internet". If we

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

Nice requirements. Will those be applied to all protocols around TLS? For example HTML/HTTP/QUIC tend to send data to third parties through additional connections and the HTTP referer header tells all those 3rd parties the URL used. This is a breach of the users privacy. For surveillance no

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

> 1) Both server and client must explicitly opt-in Why can't it be implicit such as when you click-through on the website's terms of service? > 2) A third party should be able to tell whether or not this feature is > enabled by observing the stream Why? Because we want to watch who's doing

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

This thread blew up rather quickly. Replying on a topic with quotes from various posts, below: On Saturday, July 08, 2017 05:09:12 am Stephen Farrell wrote: > On 08/07/17 03:06, Ackermann, Michael wrote: > > Converting all session traffic to clear text is not a viable > > alternative for ANY

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

On Sat, Jul 8, 2017 at 5:16 PM, Nick Sullivan wrote: > Putting questions of whether or not this belongs as a working group > document, I think there are some necessary requirements for > intra-datacenter passive decryption schemes that are not met by this draft. > >

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

On Friday, July 07, 2017 03:02:43 am Matthew Green wrote: > https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01 This document uses the terms: "Ephemeral (EC)DHE" & "Static (EC)DHE" The 'E' stands for ephemeral. Regardless of the technical, security, political, logistical, ethical,

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

Putting questions of whether or not this belongs as a working group document, I think there are some necessary requirements for intra-datacenter passive decryption schemes that are not met by this draft. Specifically, any passive decryption scheme should the following two properties: 1) Both

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

On 08/07/17 18:39, Watson Ladd wrote: > Why did static RSA not imply that? We never defined a standards track API for handing over the RSA private key. This draft proposes to do exactly the equivalent, hence the conflict with 2804. S. signature.asc Description: OpenPGP digital signature

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

On Sat, Jul 8, 2017 at 10:17 AM, Stephen Farrell wrote: > > > On 08/07/17 18:05, Russ Housley wrote: >> In draft-green-tls-static-dh-in-tls13, there is not one. I have not >> thought about it in these terms. The server, if acting in bad faith, >> can always release

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

On Sat, Jul 8, 2017 at 11:17 AM Russ Housley wrote: > I want to highlight that draft-green-tls-static-dh-in-tls13-01 does not > enable MitM. The server does not share the signing private key, so no > other party can perform a valid handshake. > This method allows a

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

On Sat, Jul 8, 2017 at 12:11 PM, Tony Arcieri wrote: > On Fri, Jul 7, 2017 at 6:02 AM, Richard Barnes wrote: > >> You could avoid changing how the DH works altogether by simply exporting >> the DH private key, encrypted with a key shared with the monitoring

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

Tony: I want to highlight that draft-green-tls-static-dh-in-tls13-01 does not enable MitM. The server does not share the signing private key, so no other party can perform a valid handshake. Further, the server is choosing to use a (EC)DH key that was generated by the key manager, so it is

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

On 08/07/17 18:05, Russ Housley wrote: > In draft-green-tls-static-dh-in-tls13, there is not one. I have not > thought about it in these terms. The server, if acting in bad faith, > can always release the client's traffic. Is it bad faith if the server is compelled to enable this wiretap

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

>>> And also: I'm sorry to have to say it, but I consider that >>> attempted weasel wording around the clear intent of 2804. The >>> clear and real effect if your wiretapping proposal were standardised >>> by the IETF would be that we'd be standardising ways in which >>> TLS servers can be

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

On 08/07/17 17:38, Jeremy Harris wrote: > The predicated architecture - tappable inside, non-tappable outside the > enterprise That's fiction. S signature.asc Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org

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

> On 8 Jul 2017, at 18:39, Tony Arcieri wrote: > > I was one of the people arguing my hardest against the BITS Security proposal > to continue to (ab)use RSA static keys to allow passive MitM, even though TLS > 1.3 had already moved forward on what I would call a more

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

+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]

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

On Fri, Jul 7, 2017 at 6:02 AM, Richard Barnes wrote: > You could avoid changing how the DH works altogether by simply exporting > the DH private key, encrypted with a key shared with the monitoring device, > in a server extension. (Not in EncryptedExtensions, obviously.) This >

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

Not sure what you are saying in regards to systems being badly designed or bad reasoning or what our blatantly false assertions are? I suspect this is not a productive path to pursue, so I will not. But in an effort to keep this discourse on track with the issue at hand, I will repeat

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

Regards to using proxies, I believe this is covered in the draft. But at a high level, most enterprises have tried this approach. It can work in some situations, but in most cases there are utilization, performance and management issues that prevent this solution from being effective or

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

On 08/07/17 16:31, Paul Turner wrote: > Stephen, > > You have referenced RFC 2804, which states the following in section > 3: > > "For the purposes of this memo, the following definition of > wiretapping is used: Wiretapping is what occurs when information > passed across the Internet from one

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

On Sat, Jul 8, 2017 at 8:44 AM, Stephen Farrell wrote: > On 08/07/17 16:39, Tony Arcieri wrote: > > Clearly there are echoes of the scary protocols of yesteryear, i.e. > > Clipper/LEAP. I think if you visit Matt Green's Twitter page and check > the > > image header you

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

On 08/07/17 16:39, Tony Arcieri wrote: > Clearly there are echoes of the scary protocols of yesteryear, i.e. > Clipper/LEAP. I think if you visit Matt Green's Twitter page and check the > image header you will discover he is quite familiar with these things, and > my personal presumption would

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

I was one of the people arguing my hardest against the BITS Security proposal to continue to (ab)use RSA static keys to allow passive MitM, even though TLS 1.3 had already moved forward on what I would call a more modern protocol design of the sort I believe payments companies should embrace to

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

Stephen, You have referenced RFC 2804, which states the following in section 3: "For the purposes of this memo, the following definition of wiretapping is used: Wiretapping is what occurs when information passed across the Internet from one party to one or more other parties is delivered to a

Re: [TLS] Fwd: New Version Notification for draft-tiloca-tls-dos-handshake-00.txt

Document: draft-tiloca-tls-dos-handshake-00.txt I'm trying to understand the threat model and operating model this is designed for. Let's start with the threat model. The anti-DoS mechanisms in DTLS are specifically oriented towards attackers who are not on-path, because on-path attackers can, as

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

Hi Stephen, Like you, I am very unhappy with this draft, and would not support its adoption as a WG draft. However I think that open discussion is in general good, and that the best venue for discussion of this draft is this mailing list. Even if some of this discussion devolves into generic

[TLS] Antw: Re: Truncated HMAC: what to do with the MAC key?

Thanks for your feedback. One other thing I could image is that truncated_hmac is mostly used in closed systems where one and the same implementation is used on both sides. @Peter: We are developing software for Smart Metering in Germany where TLS is used over the (wireless) Metering Bus. The

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

> On 8 Jul 2017, at 6:18, Timothy Jackson wrote: > > As an earlier poster asked, what advantage does this approach have over > TLS-inspecting proxies? Every IPS/IDS/next gen firewall with which I am > familiar is able to terminate at TLS connection,

[TLS] Fwd: New Version Notification for draft-tiloca-tls-dos-handshake-00.txt

Dear all, FYI, we have recently submitted a new draft proposing an extension for (D)TLS 1.2/1.3. The solution described in the draft addresses Denial of Service attacks against the handshake protocol, allowing servers to promptly abort invalid session set ups. Feedback and comments are of

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

Sean/Joe, This is a request that you, as chairs, shut down the distracting wiretapping discussion, at least until DTLS1.3 is done. I have planned to spend time reading draft 21 and DTLS, but that won't happen if we keep having to fight off the latest attempts to break TLS. I'd not be surprised

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

On 08/07/17 03:06, Ackermann, Michael wrote: > 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