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

On 20/07/17 21:21, Carl Mehner wrote: > On Thu, Jul 20, 2017 at 10:38 AM, Simon Friedberger > wrote: > I think using TLS 1.2 and waiting will only work up to a point. When > the regulators do require TLS 1.3 (and that may be years and years > away), enterprises still need somewhere to go in orde

Re: [TLS] datacenter TLS decryption as a three-party protocol

On 7/20/17, 16:32, "ilariliusva...@welho.com on behalf of Ilari Liusvaara" wrote: > Maybe we are better off just retrofitting RSA-key-transport back > into TLS-1.3? This has in fact been requested. Kenny Paterson said about the request: -

Re: [TLS] datacenter TLS decryption as a three-party protocol

On Thu, Jul 20, 2017 at 08:15:03PM +, Blumenthal, Uri - 0553 - MITLL wrote: > Maybe we are better off just retrofitting RSA-key-transport back > into TLS-1.3? In that case at least the peer could refuse this > method of key establishment, and one could safely assume that if a > peer insists on

Re: [TLS] datacenter TLS decryption as a three-party protocol

Maybe we are better off just retrofitting RSA-key-transport back into TLS-1.3? In that case at least the peer could refuse this method of key establishment, and one could safely assume that if a peer insists on that key establishment mechanism, this session will be surveilled? If I had to choos

Re: [TLS] datacenter TLS decryption as a three-party protocol

Colm MacCárthaigh wrote: > > If you maintain that draft-green is Wiretapping, then that is also the > correct term for what is happening today. Today, operators are using a > static key, used on the endpoints they control, to decrypt traffic > passively. The only difference is DH vs RSA, and I kno

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

On 20 Jul 2017, at 21:21, Carl Mehner wrote: It's not an overnight change, but it is a practical one, and one that could end up making these complicated applications that "need" static-key-style decryption work more effectively and efficiently. The problems of capex, opex, scale, additional c

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

On Thu, Jul 20, 2017 at 10:38 AM, Simon Friedberger wrote: > I would like to point out that a lot of this discussion seems to hinge > on the following argument: > > > On 17/07/17 13:04, Roland Dobbins wrote: >> On 16 Jul 2017, at 11:14, Salz, Rich wrote: >> >>> I really want to hear an answer to t

Re: [TLS] datacenter TLS decryption as a three-party protocol

On Thu, Jul 20, 2017 at 10:21 AM, Stephen Farrell wrote: > > > > It is odd ... and I'm being deliberately provocative to get at the > > doublethink. It is impossible to consider this mode wiretapping and not > > claim the browsers support it today. Plainly, they do. > > In what sense does a brows

Re: [TLS] datacenter TLS decryption as a three-party protocol

On 20/07/17 18:08, Colm MacCárthaigh wrote: > On Thu, Jul 20, 2017 at 9:55 AM, Stephen Farrell > wrote: > >> On 20/07/17 17:43, Colm MacCárthaigh wrote: >>> that's the term that people keep applying, >> >> That term was appropriate for draft-green as justified in [1] >> That's disputed by some

Re: [TLS] SNI with early data

On 07/20/2017 04:51 AM, Matt Caswell wrote: > I note in draft-21 the following text: > >When clients use a PSK obtained externally to send early data, then >the following additional information MUST be provisioned to both >parties: > >- The TLS version number for use with this PSK

Re: [TLS] datacenter TLS decryption as a three-party protocol

On Thu, Jul 20, 2017 at 9:55 AM, Stephen Farrell wrote: > On 20/07/17 17:43, Colm MacCárthaigh wrote: > > that's the term that people keep applying, > > That term was appropriate for draft-green as justified in [1] > That's disputed by some folks but it's the correct term. > If you maintain that

Re: [TLS] datacenter TLS decryption as a three-party protocol

On 20/07/17 17:43, Colm MacCárthaigh wrote: > that's the term that people keep applying, That term was appropriate for draft-green as justified in [1] That's disputed by some folks but it's the correct term. Claiming that current browsers "support" wiretapping is plain odd to me and not that us

[TLS] The TLS WG has placed draft-huitema-tls-sni-encryption in state "Candidate for WG Adoption"

The TLS WG has placed draft-huitema-tls-sni-encryption in state Candidate for WG Adoption (entered by Sean Turner) The document is available at https://datatracker.ietf.org/doc/draft-huitema-tls-sni-encryption/ ___ TLS mailing list TLS@ietf.org https:/

[TLS] The TLS WG has placed draft-thomson-tls-record-limit in state "Candidate for WG Adoption"

The TLS WG has placed draft-thomson-tls-record-limit in state Candidate for WG Adoption (entered by Sean Turner) The document is available at https://datatracker.ietf.org/doc/draft-thomson-tls-record-limit/ ___ TLS mailing list TLS@ietf.org https://www

Re: [TLS] datacenter TLS decryption as a three-party protocol

On Thu, Jul 20, 2017 at 12:44 AM, Salz, Rich wrote: > It’s like saying “all browsers that support TLS support wiretapping > because of the static RSA key exchange.” > > > > It’s a little disingenuous > It sure is! and hyperbolic, but that's the term that people keep applying, so it's clarifying

Re: [TLS] draft-ietf-tls-exported-authenticator questions

On Thu, Jul 20, 2017 at 12:02 AM, Ilari Liusvaara wrote: > While reading/implementing draft-ietf-tls-exported-authenticator I came > across the following: > > 1) > > The exporter labels are the opposite way around for handshake > contexts and finished keys, which makes little sense. > > The text

Re: [TLS] Is there a way forward after today's hum?

On 20 July 2017 at 10:29, Paul Turner wrote: > Thanks for this clarification. I agree that anything is possible in both > directions. Russ opened this discussion by asking about an alternative to > static DH. In this model, I’ve assumed the client would need to explicitly > opt-in by including an

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

I would like to point out that a lot of this discussion seems to hinge on the following argument: On 17/07/17 13:04, Roland Dobbins wrote: > On 16 Jul 2017, at 11:14, Salz, Rich wrote: > >> I really want to hear an answer to that question from folks who say >> they need TLS 1.3 but without it. >

Re: [TLS] Is there a way forward after today's hum?

-Original Message- From: Tom Ritter [mailto:t...@ritter.vg] Sent: Thursday, July 20, 2017 11:20 To: Paul Turner Cc: Yoav Nir ; IETF TLS Subject: Re: [TLS] Is there a way forward after today's hum? On 20 July 2017 at 10:07, Paul Turner mailto:ptur...@equio.com>> wrote: > It seems

Re: [TLS] Is there a way forward after today's hum?

On 20/07/17 16:23, Paul Turner wrote: >> I'd assert there's no way TLS clients in general could know when to >> set or unset the "please wiretap me" evil bit in a ClientHello, >> regardless of how complex a configuration is used. > > > It seems like the guidance would be for all TLS clients to

Re: [TLS] Is there a way forward after today's hum?

-Original Message- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Stephen Farrell Sent: Thursday, July 20, 2017 10:58 To: Paul Turner ; Ted Lemon Cc: Robin Wilton ; Subject: Re: [TLS] Is there a way forward after today's hum? On 20/07/17 15:40, Paul Turner wrote: > I’m

Re: [TLS] Is there a way forward after today's hum?

On 20 July 2017 at 10:07, Paul Turner wrote: > It seems like that problem exists today with TLS 1.3. If a government is > powerful enough to mandate key escrow, wouldn’t they also be power enough to > mandate implementing static DH with TLS 1.3 (so that they key escrow is > possible). In addition,

Re: [TLS] Is there a way forward after today's hum?

-Original Message- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Tom Ritter Sent: Thursday, July 20, 2017 10:44 To: Yoav Nir Cc: IETF TLS Subject: Re: [TLS] Is there a way forward after today's hum? On 20 July 2017 at 01:53, Yoav Nir < ynir.i

Re: [TLS] Is there a way forward after today's hum?

On 20/07/17 15:40, Paul Turner wrote: > I’m assuming that you’re referring to multiple nations being between > the TLS client and server. If a TLS client is set to not include the > extension, it seems the TLS client would simply close the connection. > It seems the client could choose whether it

Re: [TLS] Is there a way forward after today's hum?

Thanks for your response. Response to one of your comments below. From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Robin Wilton Sent: Thursday, July 20, 2017 09:45 To: Paul Turner ; tls@ietf.org Subject: Re: [TLS] Is there a way forward after today's hum? Hi Paul - thanks for this; two comm

Re: [TLS] Is there a way forward after today's hum?

-Original Message- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Martin Rex Sent: Thursday, July 20, 2017 09:29 To: Russ Housley Cc: IETF TLS Subject: Re: [TLS] Is there a way forward after today's hum? I'm sorry, Russ, but I think this would be seriously deceiving. Rus

Re: [TLS] Is there a way forward after today's hum?

The problem is that one of the applications for web browsers is as a replacement for 3270s (the first web browser). That use case is said to require this functionality. On Thu, Jul 20, 2017 at 4:43 PM, Tom Ritter wrote: > On 20 July 2017 at 01:53, Yoav Nir wrote: > > > > On 20 Jul 2017, at 8:

Re: [TLS] Is there a way forward after today's hum?

On 20 July 2017 at 01:53, Yoav Nir wrote: > > On 20 Jul 2017, at 8:01, Russ Housley wrote: > > Ted, if we use a new extension, then the server cannot include it unless the > client offered it first. I am thinking of an approach where the server > would include information needed by the decryptor

Re: [TLS] Is there a way forward after today's hum?

-Original Message- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Stephen Farrell Sent: Thursday, July 20, 2017 08:22 To: Paul Turner ; Ted Lemon Cc: Robin Wilton ; Subject: Re: [TLS] Is there a way forward after today's hum? Hiya, On 20/07/17 13:04, Paul Turner wrote:

Re: [TLS] Is there a way forward after today's hum?

On Thu, Jul 20, 2017 at 9:35 AM, Robin Wilton wrote: >... > If I am analysing this correctly, there are two "tampering events" involved > here. > > The first is: has someone tampered at the protocol/notification level to > prevent the client from being notified that static DH is in use? > > The se

Re: [TLS] Is there a way forward after today's hum?

Hi Paul - thanks for this; two comments inline. I'm an Outlook Webmail n00b, so just in case "nesting" doesn't work, I have marked them with @@@. From: Paul Turner Sent: Thursday, July 20, 2017 12:03 PM To: Robin Wilton; tls@ietf.org Subject: RE: [TLS] Is there

Re: [TLS] Is there a way forward after today's hum?

From: Russ Housley Sent: Thursday, July 20, 2017 12:35 PM To: Robin Wilton Cc: IETF TLS Subject: Re: [TLS] Is there a way forward after today's hum? On Jul 20, 2017, at 5:57 AM, Robin Wilton mailto:wil...@isoc.org>> wrote: Apologies for not replying "in thre

Re: [TLS] Is there a way forward after today's hum?

I'm sorry, Russ, but I think this would be seriously deceiving. Russ Housley wrote: > > If a specification were available that used an extension that involved > both the client and the server, would the working group adopt it, work > on it, and publish it as an RFC? > > I was listening very car

Re: [TLS] SNI with early data

Hi Matt, You might be also interested in this issue: https://github.com/tlswg/tls13-spec/issues/1040 --Kazu > I note in draft-21 the following text: > >When clients use a PSK obtained externally to send early data, then >the following additional information MUST be provisioned to both

Re: [TLS] Is there a way forward after today's hum?

Hiya, On 20/07/17 13:04, Paul Turner wrote: > Let’s use the oppressive government institution that I believe you’ve > mentioned (pardon me if I got that wrong) with a connection over the > Internet in this case. Sorry, I'm not sure what you mean there, but guessing, yes, there can be multiple n

Re: [TLS] Is there a way forward after today's hum?

It's a variant of (3). What your threat models do not take into account is how these attacks relate to the problem they are proposed to solve. The reason we're even having this discussion is because some data center operators feel that having ephemeral keys is too onerous, and that they would li

Re: [TLS] Is there a way forward after today's hum?

-Original Message- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Stephen Farrell Sent: Thursday, July 20, 2017 07:54 To: Paul Turner ; Ted Lemon Cc: Robin Wilton ; Subject: Re: [TLS] Is there a way forward after today's hum? On 20/07/17 12:44, Paul Turner wrote: > > I

Re: [TLS] Is there a way forward after today's hum?

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Ted Lemon Sent: Thursday, July 20, 2017 07:51 To: Paul Turner Cc: Robin Wilton ; Subject: Re: [TLS] Is there a way forward after today's hum? Paul, the reason to use the MiTM approach rather than simply hacking the endpoint the atta

Re: [TLS] Is there a way forward after today's hum?

On 20/07/17 12:44, Paul Turner wrote: > > I believe Russ was outlining a method where an extension would be > added to TLS 1.3 that would provide for delivery of a decryption key > to a third party during the handshake (correct me if I got that > wrong, Russ). Because it would be during the hand

Re: [TLS] Is there a way forward after today's hum?

Paul, the reason to use the MiTM approach rather than simply hacking the endpoint the attacker controls is that it may be much more convenient to be running out-of-the-box software on the endpoint. The MiTM isn't an attacker from the perspective of the controlled endpoint; it is simply a convenie

Re: [TLS] Is there a way forward after today's hum?

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Ted Lemon Sent: Thursday, July 20, 2017 07:25 To: Paul Turner Cc: Robin Wilton ; Subject: Re: [TLS] Is there a way forward after today's hum? Paul, it would be trivial to normal that exchange to conceal from the client that a static key is

Re: [TLS] Is there a way forward after today's hum?

> On Jul 20, 2017, at 5:57 AM, Robin Wilton wrote: > > Apologies for not replying "in thread" on this occasion, for noob reasons... > but here's the specific comment from Russ that I wanted to respond to: > > The hum told us that the room was roughly evenly split. In hind sight, I > wish the

Re: [TLS] Is there a way forward after today's hum?

Paul, it would be trivial to normal that exchange to conceal from the client that a static key is being used. No software mods required on either end: just in the middle. On Jul 20, 2017 1:04 PM, "Paul Turner" wrote: > > > > > *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Robin Wilton

Re: [TLS] Is there a way forward after today's hum?

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Robin Wilton Sent: Thursday, July 20, 2017 05:58 To: tls@ietf.org Subject: Re: [TLS] Is there a way forward after today's hum? Apologies for not replying "in thread" on this occasion, for noob reasons... but here's the specific comment from

Re: [TLS] SAAG TLS working group report

Hi Joe, On 20/07/17 09:54, Joseph Salowey wrote: > We had presentations on the pros and cons of a proposed mechanism > to decrypt TLS messages within the data center. A hum indicated that > there was roughly equal support on both sides. Therefore, well will > continue the discussion and it is

Re: [TLS] Is there a way forward after today's hum?

Apologies for not replying "in thread" on this occasion, for noob reasons... but here's the specific comment from Russ that I wanted to respond to: The hum told us that the room was roughly evenly split. In hind sight, I wish the chairs had asked a second ques

[TLS] SNI with early data

I note in draft-21 the following text: When clients use a PSK obtained externally to send early data, then the following additional information MUST be provisioned to both parties: - The TLS version number for use with this PSK - The cipher suite for use with this PSK - The

[TLS] SAAG TLS working group report

TLS met on Monday afternoon and Wednesday morning. For TLS 1.3, the document has completed second working group last call. There are ongoing measurements to resolve the last open issue which we believe should complete in 1-2 months. Work on DTLS is going well and we expect it to go to the IESG l

Re: [TLS] datacenter TLS decryption as a three-party protocol

It’s like saying “all browsers that support TLS support wiretapping because of the static RSA key exchange.” It’s a little disingenuous ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] datacenter TLS decryption as a three-party protocol

Ah, I get what you’re saying. DH parameter reuse for performance reasons is not a good thing, and it is not something recommended in the TLS RFCs. But offering standardized ways of exporting/importing keys for wiretapping/surveillance/discovery/analysis purposes is quite different. If a browser

[TLS] draft-ietf-tls-exported-authenticator questions

While reading/implementing draft-ietf-tls-exported-authenticator I came across the following: 1) The exporter labels are the opposite way around for handshake contexts and finished keys, which makes little sense. The text seems to imply that the finished key label the client uses for sending is