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

2017-07-21 Thread Ted Lemon
t; > Thanks > > > > Mike > > > > > > > > *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Ted Lemon > *Sent:* Thursday, July 20, 2017 10:48 AM > *To:* Tom Ritter <t...@ritter.vg> > *Cc:* IETF TLS <tls@ietf.org> > *Subject:* Re: [TLS

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

2017-07-20 Thread Tom Ritter
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

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

2017-07-20 Thread Paul Turner
-Original Message- From: Tom Ritter [mailto:t...@ritter.vg] Sent: Thursday, July 20, 2017 11:20 To: Paul Turner <ptur...@equio.com> Cc: Yoav Nir <ynir.i...@gmail.com>; IETF TLS <tls@ietf.org> Subject: Re: [TLS] Is there a way forward after today's hum? On 20 July 2

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

2017-07-20 Thread Stephen Farrell
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

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

2017-07-20 Thread Paul Turner
ietf.org> Subject: 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 c

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

2017-07-20 Thread Tom Ritter
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 >

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

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

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

2017-07-20 Thread Stephen Farrell
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

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

2017-07-20 Thread Paul Turner
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 <paul.tur...@venafi.com>; tls@ietf.org Subject: Re: [TLS] Is there a way forward after today's hum? H

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

2017-07-20 Thread Paul Turner
-Original Message- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Martin Rex Sent: Thursday, July 20, 2017 09:29 To: Russ Housley <hous...@vigilsec.com> Cc: IETF TLS <tls@ietf.org> Subject: Re: [TLS] Is there a way forward after today's hum? I'm sorry, Russ,

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

2017-07-20 Thread Ted Lemon
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

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

2017-07-20 Thread Tom Ritter
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

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

2017-07-20 Thread Paul Turner
ietf.org> Subject: 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 cas

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

2017-07-20 Thread Jeffrey Walton
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

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

2017-07-20 Thread Robin Wilton
on; tls@ietf.org Subject: 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 thr

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

2017-07-20 Thread Robin Wilton
From: Russ Housley <hous...@vigilsec.com> 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 <wil...@isoc.org<mailto:wil

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

2017-07-20 Thread Martin Rex
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

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

2017-07-20 Thread Stephen Farrell
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

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

2017-07-20 Thread Ted Lemon
TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Ted Lemon > *Sent:* Thursday, July 20, 2017 07:51 > *To:* Paul Turner <paul.tur...@venafi.com> > *Cc:* Robin Wilton <wil...@isoc.org>; <tls@ietf.org> <tls@ietf.org> > *Subject:* Re: [TLS] Is there a way forward af

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

2017-07-20 Thread Paul Turner
ietf.org> Subject: 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

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

2017-07-20 Thread Paul Turner
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Ted Lemon Sent: Thursday, July 20, 2017 07:51 To: Paul Turner <paul.tur...@venafi.com> Cc: Robin Wilton <wil...@isoc.org>; <tls@ietf.org> <tls@ietf.org> Subject: Re: [TLS] Is there a way forward after today's h

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

2017-07-20 Thread Stephen Farrell
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

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

2017-07-20 Thread Ted Lemon
g] *On Behalf Of *Ted Lemon > *Sent:* Thursday, July 20, 2017 07:25 > *To:* Paul Turner <paul.tur...@venafi.com> > *Cc:* Robin Wilton <wil...@isoc.org>; <tls@ietf.org> <tls@ietf.org> > *Subject:* Re: [TLS] Is there a way forward after today's hum? > > > &

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

2017-07-20 Thread Paul Turner
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Ted Lemon Sent: Thursday, July 20, 2017 07:25 To: Paul Turner <paul.tur...@venafi.com> Cc: Robin Wilton <wil...@isoc.org>; <tls@ietf.org> <tls@ietf.org> Subject: Re: [TLS] Is there a way forward after today's hum? P

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

2017-07-20 Thread Russ Housley
> 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

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

2017-07-20 Thread Ted Lemon
LS [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 > r

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

2017-07-20 Thread Paul Turner
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 co

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

2017-07-20 Thread Yoav Nir
> 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 in the response.

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

2017-07-20 Thread Ted Lemon
I think that's okay, since this is only for use in applications where both parties are in on the deal. But the problem with the static ecdh proposal is the the server is not compelled to reveal that it is doing it. On Jul 20, 2017 8:01 AM, "Russ Housley" wrote: > Ted, if

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

2017-07-20 Thread Russ Housley
The agenda included: - Data Center use of Static DH (30 min) https://datatracker.ietf.org/doc/draft-green-tls-static-dh-in-tls13/ - National Cybersecurity Center of Excellence (NCCOE) project for visibility within the

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

2017-07-20 Thread Russ Housley
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 in the response. So, if the client did not offer the extension, it would be a TLS protocol

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

2017-07-19 Thread Stephen Farrell
On 19/07/17 18:10, Russ Housley wrote: > The hum told us that the room was roughly evenly split. In hind > sight, I wish the chairs had asked a second question. If the split > in the room was different for the second question, then I think we > might have learned a bit more about what people

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

2017-07-19 Thread Ted Lemon
Provably involved, or involved setting an evil bit? On Wed, Jul 19, 2017 at 7:10 PM, Russ Housley wrote: > The hum told us that the room was roughly evenly split. In hind sight, I > wish the chairs had asked a second question. If the split in the room was > different for

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

2017-07-19 Thread Russ Housley
The hum told us that the room was roughly evenly split. In hind sight, I wish the chairs had asked a second question. If the split in the room was different for the second question, then I think we might have learned a bit more about what people are thinking. If a specification were