Re: [TLS] TLS@IETF101 Agenda Posted

Russ, On 15/03/18 17:29, Russ Housley wrote: >>> Nalini, why don't you (the consortium) define the standard, >>> then? > >> Indeed, if a “TLS13-visibility” standard has to be defined, it >> would make sense for the consortium (rather than the TLS WG) to >> define it. > > In fact, my mistake tha

Re: [TLS] TLS@IETF101 Agenda Posted

>> >> Nalini, why don't you (the consortium) define the standard, then? >> >> > Indeed, if a “TLS13-visibility” standard has to be defined, it would make >> > sense for the consortium (rather than the TLS WG) to define it. >> >> In fact, my mistake that was caught by Martin is exactly the re

Re: [TLS] TLS@IETF101 Agenda Posted

15, 2018 10:29 AM To: IETF TLS Subject: Re: [TLS] TLS@IETF101 Agenda Posted * >> Nalini, why don't you (the consortium) define the standard, then? > Indeed, if a “TLS13-visibility” standard has to be defined, it would make > sense for the consortium (rather than the TLS

Re: [TLS] TLS@IETF101 Agenda Posted

>> Nalini, why don't you (the consortium) define the standard, then? > Indeed, if a “TLS13-visibility” standard has to be defined, it would make > sense for the consortium (rather than the TLS WG) to define it. In fact, my mistake that was caught by Martin is exactly the reason that we want th

Re: [TLS] TLS@IETF101 Agenda Posted

[top-posted because the bulk of the quoted material really is necessary for context] Hi Nalini, It seems to me your and Stephen's recollections of events have two essential points in common (well, in my view they do) that I'd like to highlight here: 1. A number of your consortium's parties ar

Re: [TLS] TLS@IETF101 Agenda Posted

My responses for today are all in this message, including a response to Ralph. I'm going to try not to engage on this again until tomorrow. On Mar 14, 2018, at 6:52 PM, nalini elkins wrote: > 1. Multiple standards are likely to diverge. We don't need multiple standards, so this isn't an issue

Re: [TLS] TLS@IETF101 Agenda Posted

On 15/03/18 00:05, nalini elkins wrote: >> There is no question of a smokey back room. >I'm sorry to disagree so bluntly, but while I was an >AD some of the people involved here requested that I >meet them in private to discuss this topic before it >had been raised on the list, and without tellin

Re: [TLS] TLS@IETF101 Agenda Posted

* I think the core of the discussion is that no matter how many times I say that enterprises are trying to protect their customers, you do not consider that a valid use case. Can you point to a section in the Fenter draft that shows how customers are being protected? I could not find it.

Re: [TLS] TLS@IETF101 Agenda Posted

> On Mar 14, 2018, at 10:52 PM, Artyom Gavrichenkov wrote: > > 14 Mar. 2018 г., 22:32 Ralph Droms >: > >> On Mar 13, 2018, at 7:45 PM, Artyom Gavrichenkov > > wrote: >> >> 13 Mar. 2018 г., 18:38 Ted Lemon > >: >

Re: [TLS] TLS@IETF101 Agenda Posted

14 Mar. 2018 г., 22:32 Ralph Droms : > > On Mar 13, 2018, at 7:45 PM, Artyom Gavrichenkov > wrote: > > 13 Mar. 2018 г., 18:38 Ted Lemon : > >> One strategy that's very effective for overcoming resistance to bad ideas >> is to keep pushing the idea until nobody who's resisting it can afford to >>

Re: [TLS] TLS@IETF101 Agenda Posted

> On Mar 13, 2018, at 7:45 PM, Artyom Gavrichenkov wrote: > > 13 Mar. 2018 г., 18:38 Ted Lemon mailto:mel...@fugue.com>>: > One strategy that's very effective for overcoming resistance to bad ideas is > to keep pushing the idea until nobody who's resisting it can afford to > continue doing so

Re: [TLS] TLS@IETF101 Agenda Posted

On 14/03/18 23:16, Stephen Farrell wrote: > Of course some people who are used to MitMing connections will > have problems and will have to change. I got an offlist message correcting me about the above. I do agree that it's odd to describe post-facto decryption of a TLS session that used RSA k

Re: [TLS] TLS@IETF101 Agenda Posted

a) Nalini, I haven't posted anything even slightly close to the examples of offending messages you've just written. b) Is this the only message of mine that deserves a response? 14 Mar. 2018 г., 19:00 nalini elkins : > >>One strategy that's very effective for overcoming resistance to bad >> idea

Re: [TLS] TLS@IETF101 Agenda Posted

On 15/03/18 00:05, nalini elkins wrote: > There is no question of a smokey back room. I'm sorry to disagree so bluntly, but while I was an AD some of the people involved here requested that I meet them in private to discuss this topic before it had been raised on the list, and without telling me

Re: [TLS] TLS@IETF101 Agenda Posted

> If your consortium want a multi-party security protocol that does not affect > other folks' security as you seem to claim, then that is the obvious route to > explore. +1. It seems that this is at the core of the request. In which case the proper solution is to define this multi-party protoco

Re: [TLS] TLS@IETF101 Agenda Posted

Stephen, More on other points later. I am getting pretty tired as am jet lagged. >I am just fine with talking openly on the mailing list, as >per IETF processes. I see no benefit in smokey back room >discussions here at all, and only downsides to such. You know, this issue of side or quiet conve

Re: [TLS] TLS@IETF101 Agenda Posted

On 14/03/18 23:32, nalini elkins wrote: > But, it is a very difficult issue. If I can use a different analogy, if > the City of Monterey built a new sewer system and told me that to connect > to it, I had to build a new house, I would scream! Analogies cannot be used to draw conclusions, merel

Re: [TLS] TLS@IETF101 Agenda Posted

>>Enterprises value security and privacy. They have a different job to do. What they are trying to do is to protect against leakage of data, do fraud monitoring, protect against malware and many other things. When this gets into the medical arena, >>it can even be lives. I don't even see how

Re: [TLS] TLS@IETF101 Agenda Posted

- >The simple explanation is that people think they will have serious issues with TLS1.3 and actually, TLS1.2 when it is DH only. >They have a problem with a protocol that doesn’t use static-RSA key exchange. And they would rather not pay for a solution to that problem. I would not a

Re: [TLS] TLS@IETF101 Agenda Posted

* The simple explanation is that people think they will have serious issues with TLS1.3 and actually, TLS1.2 when it is DH only. They have a problem with a protocol that doesn’t use static-RSA key exchange. And they would rather not pay for a solution to that problem. ___

Re: [TLS] TLS@IETF101 Agenda Posted

Stephen, >So it doesn't really help the discussion to claim that >such-and-such a (set of person(s) is/are good actors - we do >assume that, but also that there are others who would like >the same changes to happen who do not share the IETF's goals >of making Internet security better as far as we

Re: [TLS] TLS@IETF101 Agenda Posted

On Wed, Mar 14, 2018 at 7:17 PM, nalini elkins wrote: > >>- > Nalini, why don't you (the consortium) define the standard, then? >> >> >> >> > Indeed, if a “TLS13-visibility” standard has to be defined, it would >> make sense for the consortium (rather than the TLS WG) to define it. >> >> >> >

Re: [TLS] TLS@IETF101 Agenda Posted

> > >- > Nalini, why don't you (the consortium) define the standard, then? > > > > > Indeed, if a “TLS13-visibility” standard has to be defined, it would > make sense for the consortium (rather than the TLS WG) to define it. > > > > I completely disagree. Here is why I would not prefer that r

Re: [TLS] TLS@IETF101 Agenda Posted

On 14/03/18 23:00, nalini elkins wrote: > The simple explanation is that people think they will have serious > issues with TLS1.3 and actually, TLS1.2 when it is DH only. Of course some people who are used to MitMing connections will have problems and will have to change. But that does not mean

Re: [TLS] TLS@IETF101 Agenda Posted

On Wed, Mar 14, 2018 at 6:52 PM, nalini elkins wrote: > > All, > > In London now & back on email: > > >- >> Nalini, why don't you (the consortium) define the standard, then? > > > > > Indeed, if a “TLS13-visibility” standard has to be defined, it would > make sense for the consortium (rather

Re: [TLS] TLS@IETF101 Agenda Posted

> > >>One strategy that's very effective for overcoming resistance to bad > ideas is to keep pushing the idea until nobody who's resisting it can > afford to continue doing so. > >There's a name for that tactics, it's called "consensus by exhaustion". (On the recent GNSO meeting this was briefly d

Re: [TLS] TLS@IETF101 Agenda Posted

All, In London now & back on email: - >> Nalini, why don't you (the consortium) define the standard, then? > Indeed, if a “TLS13-visibility” standard has to be defined, it would make sense for the consortium (rather than the TLS WG) to define it. I completely disagree. Here is why I w

Re: [TLS] TLS@IETF101 Agenda Posted

On Tue, Mar 13, 2018 at 3:16 PM, Russ Housley wrote: > Second, using > TLS1.2 does not technically address the issue. If the client were to > exclusively offer DHE-based ciphersuites, then the visibility techniques > that have been used in the past are thwarted. I expect this configuration to be

Re: [TLS] TLS@IETF101 Agenda Posted

>while sure, both TLS 1.0 and TLS 1.2 likely will be removed from those > afore- mentioned libraries at _some_ point, it is disingenuous to suggest it will happen in a matter of just few years, especially for the latter of the two protocols Absolutely true! __

Re: [TLS] TLS@IETF101 Agenda Posted

On Wednesday, 14 March 2018 19:53:21 CET Russ Housley wrote: > > On Mar 14, 2018, at 8:39 AM, Hubert Kario wrote: > > > > On Tuesday, 13 March 2018 23:16:47 CET Russ Housley wrote: > >> Ted: > >>> There's an easy way to do this, although as a sometime bank security > >>> geek > >>> I would strong

Re: [TLS] TLS@IETF101 Agenda Posted

Perhaps this would be a good time to put in a plug for additional funding for openssl et al... On Mar 14, 2018 14:53, "Russ Housley" wrote: > > > On Mar 14, 2018, at 8:39 AM, Hubert Kario wrote: > > > > On Tuesday, 13 March 2018 23:16:47 CET Russ Housley wrote: > >> Ted: > >>> There's an easy w

Re: [TLS] TLS@IETF101 Agenda Posted

> On Mar 14, 2018, at 8:39 AM, Hubert Kario wrote: > > On Tuesday, 13 March 2018 23:16:47 CET Russ Housley wrote: >> Ted: >>> There's an easy way to do this, although as a sometime bank security geek >>> I would strongly advise you to not do it: keep using TLS 1.2. >> This is a bogus argument.

Re: [TLS] TLS@IETF101 Agenda Posted

On Wed, Mar 14, 2018 at 8:32 AM, Ted Lemon wrote: > On Mar 13, 2018, at 11:49 PM, Russ Housley wrote: > > I was trying to separate these two cases. If the TLS session is terminated > at a load balancer, then the client within the load balancer is (as Ted > says) under control of the operator. T

Re: [TLS] TLS@IETF101 Agenda Posted

On Tuesday, 13 March 2018 23:16:47 CET Russ Housley wrote: > Ted: > > There's an easy way to do this, although as a sometime bank security geek > > I would strongly advise you to not do it: keep using TLS 1.2. > This is a bogus argument. First, staying with an old protocol version often > leads to

Re: [TLS] TLS@IETF101 Agenda Posted

On Mar 13, 2018, at 11:49 PM, Russ Housley wrote: > I was trying to separate these two cases. If the TLS session is terminated > at a load balancer, then the client within the load balancer is (as Ted says) > under control of the operator. The operator can include any extensions that > it wis

Re: [TLS] TLS@IETF101 Agenda Posted

Second, using TLS1.2 does not technically address the issue. If the client were to exclusively offer DHE-based ciphersuites, then the visibility techniques that have been used in the past are thwarted. >>> >>> The client in this case is under the control of the operator, so this i

Re: [TLS] TLS@IETF101 Agenda Posted

Clarifying question On Tue, Mar 13, 2018 at 10:55 PM, Russ Housley wrote: > Ted: > > I do not follow. > > This is a bogus argument. > > > I'm pretty sure there's a Monty Python skit about this, so I won't belabor > the point. > > > I'll avoid asking how many sparrows are needed ;-) > > First, sta

Re: [TLS] TLS@IETF101 Agenda Posted

Ted: I do not follow. >> This is a bogus argument. > > I'm pretty sure there's a Monty Python skit about this, so I won't belabor > the point. I'll avoid asking how many sparrows are needed ;-) >> First, staying with an old protocol version often leads to locking in >> unmaintained versions

Re: [TLS] TLS@IETF101 Agenda Posted

> On Mar 13, 2018, at 6:38 PM, Salz, Rich wrote: > > The second paragraph talks about how quickly PCI DSS moved. As a > counterpoint, how quickly did they move to delay TLS 1.0 when organizations > pushed back? SSL3 was "safe" to remove. So far they can't even follow > industry best practi

Re: [TLS] TLS@IETF101 Agenda Posted

13 Mar. 2018 г., 18:38 Ted Lemon : > One strategy that's very effective for overcoming resistance to bad ideas > is to keep pushing the idea until nobody who's resisting it can afford to > continue doing so. > There's a name for that tactics, it's called "consensus by exhaustion". (On the recent

Re: [TLS] TLS@IETF101 Agenda Posted

Have any of the folks in the “visibility” camp had discussions with browser vendors? And if so, have any of them said they would support this? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS@IETF101 Agenda Posted

On Mar 13, 2018, at 6:16 PM, Russ Housley wrote: > This is a bogus argument. I'm pretty sure there's a Monty Python skit about this, so I won't belabor the point. > First, staying with an old protocol version often leads to locking in > unmaintained versions of old software. Right, that's one

Re: [TLS] TLS@IETF101 Agenda Posted

So I re-read Steve's document. >To keep using TLS1.2 has been proposed and discussed many times over the > past year or so and is not acceptable for many reasons outlined in Steve > Fenters draft. So I will refer to that, rather than add repetition to the > list. But suffice to say it is

Re: [TLS] TLS@IETF101 Agenda Posted

On Mar 13, 2018, at 6:22 PM, Stephen Farrell wrote: > I mean, do you *really* think there's any chance of reaching rough > consensus on the list for this draft? If not, then ISTM you're > putting meeting attendees and list participants through a bunch > of pain for no gain. It's actually worse th

Re: [TLS] TLS@IETF101 Agenda Posted

* Second, using TLS1.2 does not technically address the issue. If the client were to exclusively offer DHE-based ciphersuites, then the visibility techniques that have been used in the past are thwarted. * Yes, the server cannot use the "tls_visibility" extension unless the client offer

Re: [TLS] TLS@IETF101 Agenda Posted

> On Mar 13, 2018, at 6:21 PM, Andrei Popov wrote: > > If the client were to exclusively offer DHE-based ciphersuites, then the > visibility techniques that have been used in the past are thwarted. > TLS1.3-visibility will be equally thwarted if the client does not send the > empty “tls_visibi

Re: [TLS] TLS@IETF101 Agenda Posted

* This is a bogus argument. First, staying with an old protocol version often leads to locking in unmaintained versions of old software. Second, using TLS1.2 does not technically address the issue. If the client were to exclusively offer DHE-based ciphersuites, then the visibility techniq

Re: [TLS] TLS@IETF101 Agenda Posted

Joe, On 13/03/18 16:09, Joseph Salowey wrote: > Hi Stephen, > > It is not accurate to say that there was consensus to stop discussion of > this topic in Prague. I did not say that. I said numerous times that there was a clear lack of consensus in Prague. Based on the question *you* asked, w

Re: [TLS] TLS@IETF101 Agenda Posted

chooses to play by the rules, of course.) Cheers, Andrei From: TLS On Behalf Of Russ Housley Sent: Tuesday, March 13, 2018 3:17 PM To: Ted Lemon Cc: IETF TLS Subject: Re: [TLS] TLS@IETF101 Agenda Posted Ted: There's an easy way to do this, although as a sometime bank security geek I

Re: [TLS] TLS@IETF101 Agenda Posted

Ted: > There's an easy way to do this, although as a sometime bank security geek I > would strongly advise you to not do it: keep using TLS 1.2. This is a bogus argument. First, staying with an old protocol version often leads to locking in unmaintained versions of old software. Second, using

Re: [TLS] TLS@IETF101 Agenda Posted

Richard Barnes and Rich Salz, Thank you for the kind words. They are much appreciated! Best of luck to Rich with the health concerns too. It’s been an interesting journey with a lot of great folks. Will reply to the issues later as I need to head out at the moment. -Darin On Tue, Mar 13, 20

Re: [TLS] TLS@IETF101 Agenda Posted

etition to the list. But suffice to say it is well beyond PCI for most Enterprises. -Original Message- From: Ted Lemon [mailto:mel...@fugue.com] Sent: Tuesday, March 13, 2018 4:28 PM To: Ackermann, Michael Cc: nalini elkins ; Subject: Re: [TLS] TLS@IETF101 Agenda Posted On Mar 13

Re: [TLS] TLS@IETF101 Agenda Posted

> On Mar 13, 2018, at 3:20 PM, Ackermann, Michael wrote: > > I think that most Enterprises are not espousing any conversations "how can we > avoid making any changes?" > But we would seek to avoid unnecessary, wholesale, infrastructure > architectural changes. > We want to stay with stand

Re: [TLS] TLS@IETF101 Agenda Posted

On Mar 13, 2018, at 3:20 PM, Ackermann, Michael wrote: > I think that most Enterprises are not espousing any conversations "how can we > avoid making any changes?" With respect, Michael, when I have conversed with you about this in the past, that is precisely what you have asked for. You do n

Re: [TLS] TLS@IETF101 Agenda Posted

rds to the lowest common denominator. That is why Enterprises are finally coming to the IETF. Hopeful of some common ground and collaborative solutions. From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Ted Lemon Sent: Tuesday, March 13, 2018 1:53 PM To: nalini elkins Cc: Subject: Re: [TLS] T

Re: [TLS] TLS@IETF101 Agenda Posted

All, The time has gotten away from me. I have to leave for the airport. I am taking my daughter to London & need to get us all packed & out of the house. I will write respond to all at length either from the airport or in London. Rich, so sorry about your health issues. My best wishes for a f

Re: [TLS] TLS@IETF101 Agenda Posted

* "We" is a consortium of organizations. I would say over 50 so far. They operate large data centers. They are in manufacturing, insurance, finance, and others. * Nalini, why don't you (the consortium) define the standard, then? Indeed, if a “TLS13-visibility” standard has to be d

Re: [TLS] TLS@IETF101 Agenda Posted

On Tue, Mar 13, 2018 at 1:52 PM, Ted Lemon wrote: > In addition, you are reducing compartmentalization with your keying > strategy—in order to make communications easily decryptable, you have to > have broadly-shared keys, and that reduces the amount of > compartmentalization that TLS can provide

Re: [TLS] TLS@IETF101 Agenda Posted

Yes, I've read all that through, and I've been in Prague, and I still feel that the problem statement lacks some clarification. This is, by the way, the reason draft-fenter is published; who would need that if the reasons all this visibility thing is proposed would have been transparent for anyone

Re: [TLS] TLS@IETF101 Agenda Posted

On Mar 13, 2018, at 12:37 PM, nalini elkins wrote: > "We" is a consortium of organizations. I would say over 50 so far. They > operate large data centers. They are in manufacturing, insurance, finance, > and others. Nalini, why don't you (the consortium) define the standard, then? The r

Re: [TLS] TLS@IETF101 Agenda Posted

* I am happy to set up an informal session where all can meet and talk quietly. Not everyone will be there on Sunday but maybe Monday breakfast or during a break? Just let me know if you are interested & we can make intros. I won’t be there (health issues), but I’ve already turned down su

Re: [TLS] TLS@IETF101 Agenda Posted

> On Mar 13, 2018, at 16:31, Artyom Gavrichenkov wrote: > > Hi Nalini, > > вт, 13 мар. 2018 г., 11:59 nalini elkins : > The TLS working group has been concentrating on making the Internet secure > for the individual user.We feel that there is also an underlying > motivation to help t

Re: [TLS] TLS@IETF101 Agenda Posted

Hi Eric, The author probably refers to a case where an infosec dept of an enterprise will not just disable TLSv1.3 on the servers, but will also set up some deep-juju DPI for filtering v1.3 in transit to make sure no one will enable v1.3 accidentally somewhere. As those DPI solutions are often of

Re: [TLS] TLS@IETF101 Agenda Posted

+1 > On 13 Mar 2018, at 17:23, Eric Rescorla wrote: > > > >> On Tue, Mar 13, 2018 at 8:58 AM, nalini elkins >> wrote: >> Stephen (and TLS group) >> >> We need to look at the bigger picture. >> >> The TLS working group has been concentrating on making the Internet secure >> for the ind

Re: [TLS] TLS@IETF101 Agenda Posted

>It would be far better if the concerned organizations could come forth directly. That helps the community see that there are real people who care enough about this to engage, and will hopefully allow more direct discussions of >the problems and possible solutions. >Kudos to the US Bank guys for

Re: [TLS] TLS@IETF101 Agenda Posted

On Tue, Mar 13, 2018 at 8:58 AM, nalini elkins wrote: > Stephen (and TLS group) > > We need to look at the bigger picture. > > The TLS working group has been concentrating on making the Internet secure > for the individual user.We feel that there is also an underlying > motivation to help the

Re: [TLS] TLS@IETF101 Agenda Posted

It would be far better if the concerned organizations could come forth directly. That helps the community see that there are real people who care enough about this to engage, and will hopefully allow more direct discussions of the problems and possible solutions. Kudos to the US Bank guys for lea

Re: [TLS] TLS@IETF101 Agenda Posted

- >>"We" is a consortium of organizations. I would say over 50 so far. They operate large data centers. They are in manufacturing, insurance, finance, and others. > See, I have a bit of a problem with that. As you should know (since you are a Mentor coordinator), participation is o

Re: [TLS] TLS@IETF101 Agenda Posted

* "We" is a consortium of organizations. I would say over 50 so far. They operate large data centers. They are in manufacturing, insurance, finance, and others. See, I have a bit of a problem with that. As you should know (since you are a Mentor coordinator), participation is on the b

Re: [TLS] TLS@IETF101 Agenda Posted

+1 ! Well stated. From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of nalini elkins Sent: Tuesday, March 13, 2018 11:59 AM To: Colm MacCárthaigh Cc: Subject: Re: [TLS] TLS@IETF101 Agenda Posted Stephen (and TLS group) We need to look at the bigger picture. The TLS working group has been

Re: [TLS] TLS@IETF101 Agenda Posted

> This might be a good time to review RFC 7282 Thanks, Melinda! Re-reading! Nalini On Tue, Mar 13, 2018 at 9:33 AM, Melinda Shore wrote: > On 3/13/18 8:09 AM, nalini elkins wrote: > > I agree that the room hummed to "continue the discussion". > > This might be a good time to review RFC 7282

Re: [TLS] TLS@IETF101 Agenda Posted

Rich, A clarification: > Well, I’d be fine with a bunch of point solutions that were only sold and deployed in an enterprise because, as I said last time, this is too risky for the public Internet. What I meant about being fine with is a solution INSIDE the enterprise. But, we need a STANDARD

Re: [TLS] TLS@IETF101 Agenda Posted

*>>* I hope that we can all work together to craft a solution. We don't want fragmentation and multiple DIY solutions. > Well, I’d be fine with a bunch of point solutions that were only sold and deployed in an enterprise because, as I said last time, this is too risky for the public Internet.

Re: [TLS] TLS@IETF101 Agenda Posted

On 3/13/18 8:09 AM, nalini elkins wrote: > I agree that the room hummed to "continue the discussion". This might be a good time to review RFC 7282 ("On Consensus and Humming in the IETF") so that everybody is more-or-less on the same page with respect to what a roughly 50/50 split hum means. Meli

Re: [TLS] TLS@IETF101 Agenda Posted

> I hope that we can all work together to craft a solution. We don't want > fragmentation and multiple DIY solutions. Well, I’d be fine with a bunch of point solutions that were only sold and deployed in an enterprise because, as I said last time, this is too risky for the public Internet. S

Re: [TLS] TLS@IETF101 Agenda Posted

Hi Nalini, вт, 13 мар. 2018 г., 11:59 nalini elkins : > The TLS working group has been concentrating on making the Internet secure > for the individual user.We feel that there is also an underlying > motivation to help the underdog and protect the political dissident. > This isn't about diss

Re: [TLS] TLS@IETF101 Agenda Posted

As I wrote to Rich, thanks for the correction. I hope that we can work together to craft a solution. We don't want fragmentation and multiple DIY solutions. Nalini On Tue, Mar 13, 2018 at 9:09 AM, Joseph Salowey wrote: > The consensus (as judge by the chairs) was that there no clear consens

Re: [TLS] TLS@IETF101 Agenda Posted

The consensus (as judge by the chairs) was that there no clear consensus to shut the discussion down. It was not that work on internal solution is needed. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS@IETF101 Agenda Posted

Thanks for the correction, Rich. I agree that the room hummed to "continue the discussion". I hope that we can all work together to craft a solution. We don't want fragmentation and multiple DIY solutions. Nalini On Tue, Mar 13, 2018 at 9:05 AM, Salz, Rich wrote: > >- Prague where half

Re: [TLS] TLS@IETF101 Agenda Posted

Hi Stephen, It is not accurate to say that there was consensus to stop discussion of this topic in Prague. There are vocal contingents both for an against this topic. We did not have discussion of this draft in Singapore because the authors could not make the meeting due to several issues and we

Re: [TLS] TLS@IETF101 Agenda Posted

* Prague where half of the room hummed that an internal solution is needed. No, this is not accurate. Half the room hummed *to continue discussion.* The discussion could still end with no action. ___ TLS mailing list TLS@ietf.org https://www.ietf

Re: [TLS] TLS@IETF101 Agenda Posted

Stephen (and TLS group) We need to look at the bigger picture. The TLS working group has been concentrating on making the Internet secure for the individual user.We feel that there is also an underlying motivation to help the underdog and protect the political dissident. These are all laudab

Re: [TLS] TLS@IETF101 Agenda Posted

It's my fault for the ambiguous wording, but in this context the quote from me reads as the opposite of my intent. To be more clear: what I meant was that while the proposals aren't making much progress, I don't mind that it's being discussed. I'm happy to have mailing list threads on the topic a

Re: [TLS] TLS@IETF101 Agenda Posted

Hiya, Just to be clear: I'm still waiting for the chairs and/or AD to explain how the proposed discussion of this draft is consistent with IETF processes, given the results of the discussion in Prague (a very clear lack of consensus to even work on this topic), and the discussion of the -00 versi

Re: [TLS] TLS@IETF101 Agenda Posted

Hiya, On Saturday, 10 March 2018, Melinda Shore wrote: > On 3/9/18 12:57 PM, Kathleen Moriarty wrote: > > The hummed answer to that question was very close to 50/50 in the > > room, inconclusive. > > From the perspective of consensus decision-making that's > actually very clear - there's no conse

Re: [TLS] TLS@IETF101 Agenda Posted

On 3/9/18 12:57 PM, Kathleen Moriarty wrote: > The hummed answer to that question was very close to 50/50 in the > room, inconclusive. From the perspective of consensus decision-making that's actually very clear - there's no consensus. What that means in practice depends on the question that was

Re: [TLS] TLS@IETF101 Agenda Posted

Kathleen, On 09/03/18 21:57, Kathleen Moriarty wrote: > Hello, Stephen. > > On Fri, Mar 9, 2018 at 4:24 PM, Stephen Farrell > wrote: >> >> Hi Joe, >> >> I'm sorry, but I gotta say that answer seems to me both unresponsive >> to the questions asked and unconvincing. >> >> On 08/03/18 23:08, Jose

Re: [TLS] TLS@IETF101 Agenda Posted

Hello, Stephen. On Fri, Mar 9, 2018 at 4:24 PM, Stephen Farrell wrote: > > Hi Joe, > > I'm sorry, but I gotta say that answer seems to me both unresponsive > to the questions asked and unconvincing. > > On 08/03/18 23:08, Joseph Salowey wrote: >> Hi Stephen, >> >> In the meeting in Prague there w

Re: [TLS] TLS@IETF101 Agenda Posted

Hi Joe, I'm sorry, but I gotta say that answer seems to me both unresponsive to the questions asked and unconvincing. On 08/03/18 23:08, Joseph Salowey wrote: > Hi Stephen, > > In the meeting in Prague there was interest in this problem space, but > neither the consensus to accept or reject thi

Re: [TLS] TLS@IETF101 Agenda Posted

Hi Darin, I just asked for clarification whether it's on a TLS WG agenda for London. I'm not quite sure this is a right thread to discuss the contents of that draft. (In fact, I'm pretty sire it isn't.) | Artyom Gavrichenkov | gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191 | mailto: xima.

Re: [TLS] TLS@IETF101 Agenda Posted

Artyom, Thanks for mentioning the ID and you are right that draft Fenter is the supporting problem description. The reason it was written was to help folks understand why legitimate internal out-of-band decryption is still needed on data once it reaches its destination and that there isn’t a viabl

Re: [TLS] TLS@IETF101 Agenda Posted

Hi Stephen, In the meeting in Prague there was interest in this problem space, but neither the consensus to accept or reject this work. The authors have revised their proposal to address some of the concerns raised by working group members and are asking to bring the new approach in front of the

Re: [TLS] TLS@IETF101 Agenda Posted

Hi Sean, Joe, WG also has this at its disposal: https://tools.ietf.org/html/draft-fenter-tls-decryption-00 Will that be discussed along with draft-rhrd-tls-tls13-visibility? Those two seem to be rather connected/dependant on each other. | Artyom Gavrichenkov | gpg: 2deb 97b1 0a3c 151d b67f 1ee5 0

Re: [TLS] TLS@IETF101 Agenda Posted

Hi Sean, Joe, On 08/03/18 16:20, Sean Turner wrote: > I’ve posted the draft agendas: > > Monday: > https://datatracker.ietf.org/meeting/101/materials/agenda-101-tls-sessb That includes: " TLS Vizability - Russ & Chairs - 30min - 10min draft - Russ https://datatracker.ietf.org/doc/draft-rhr