Hi,
> On Mar 13, 2018, at 11:03 PM, Russ Housley wrote:
>
> Stephen:
>
>>> I do not know if the TLS WG will want to adopt this approach. I
>>> would like to find out.
>>
>> Did you read the list traffic from Oct/Nov? I have no idea how
>> you can be in doubt if you did. It's readily apparent
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
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
Stephen:
>> I do not know if the TLS WG will want to adopt this approach. I
>> would like to find out.
>
> Did you read the list traffic from Oct/Nov? I have no idea how
> you can be in doubt if you did. It's readily apparent that your
> draft has not caused a lot of people to change their mind
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
It seems like we get ourselves in trouble by allowing multiple
external PSKs to be present. If we allowed at most one external
PSK in a given ClientHello, then aborting the handshake on binder
failure would be the correct choice, as discovering a valid identity
would require discovering a valid ke
> 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
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
Hi Russ,
On 13/03/18 21:49, Russ Housley wrote:
> The Prague discussion was about draft-green-...
Much more was discussed than just that one dead draft. In particular
see the minutes for the more general question posed by the chairs.
> Nick Sullivan summarized four concerns with that approach.
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
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
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
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
* 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
> 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
* 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
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
* 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_visibility" extension, right?
(Assuming the server chooses to pl
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
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
I will pretty much repeat what I said below. Significant fundamental
infrastructure changes, are very difficult for very large organizations to
assimilate. Because of time and resource issues, large organizations would
seek to avoid major, overhaul type changes, wherever possible.The
>> Stephen, the opposite PoV is equally valid. There was no consensus in
>> Prague NOT to work on the topic. The mood of the room was evenly
>> divided.
>
> To clarify, this isn't voting. If there's no agreement in
> either direction there's no agreement (and I hope the default
> in the IETF is
> 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
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
On Tue, Mar 13, 2018 at 3:08 PM, Melinda Shore
wrote:
> On 3/13/18 10:44 AM, Kathleen Moriarty wrote:
>> And then there are other options too, like another WG. Even from
>> Stephen's list of who is in agreement with him, I've received a few
>> messages saying their text wasn't what he thinks it w
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 standards wherever/whenever possible and keep the number
of standards to the low
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
On 3/13/18 10:44 AM, Kathleen Moriarty wrote:
> And then there are other options too, like another WG. Even from
> Stephen's list of who is in agreement with him, I've received a few
> messages saying their text wasn't what he thinks it was. More
> discussion here would be good to figure out a wa
On Tue, Mar 13, 2018 at 1:21 PM, Melinda Shore
wrote:
> On 3/13/18 6:48 AM, Jim Reid wrote:
>> Stephen, the opposite PoV is equally valid. There was no consensus in
>> Prague NOT to work on the topic. The mood of the room was evenly
>> divided.
>
> To clarify, this isn't voting. If there's no agr
* "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
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
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
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
On Tuesday, 13 March 2018 16:18:48 CET Ilari Liusvaara wrote:
> On Mon, Mar 12, 2018 at 04:27:46PM +0100, Hubert Kario wrote:
> > When the server supports externally set PSKs that use human readable
> > identities (or, in general, guessable identities), the current text makes
> > it trivial to perf
* 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
> 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
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
+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
>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
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
On 3/13/18 6:48 AM, Jim Reid wrote:
> Stephen, the opposite PoV is equally valid. There was no consensus in
> Prague NOT to work on the topic. The mood of the room was evenly
> divided.
To clarify, this isn't voting. If there's no agreement in
either direction there's no agreement (and I hope the
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
- >>"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
* "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
+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 con
> 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
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
*>>* 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.
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
> 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
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
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
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
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
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
* 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
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
On Mon, Mar 12, 2018 at 04:27:46PM +0100, Hubert Kario wrote:
> When the server supports externally set PSKs that use human readable
> identities (or, in general, guessable identities), the current text makes it
> trivial to perform enumeration attack.
What would be impact of such enumeration at
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
> On 13 Mar 2018, at 14:21, Stephen Farrell wrote:
>
> 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 ev
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
Okay, just wanted to check!
> Am 13.03.2018 um 09:30 schrieb Martin Thomson :
>
> On Tue, Mar 13, 2018 at 8:06 AM, Mirja Kuehlewind (IETF)
> wrote:
>> Just to double-check, there is also no requirement or maybe recommend to not
>> send cleartext and 0-RTT data in the same packet?
>
> You mean
On Tue, Mar 13, 2018 at 8:06 AM, Mirja Kuehlewind (IETF)
wrote:
> Just to double-check, there is also no requirement or maybe recommend to not
> send cleartext and 0-RTT data in the same packet?
You mean in the same TCP segment? We do nothing to prevent that, and
nor should we. It would mess w
Hi Ekr,
just one more comment on this part
> Am 07.03.2018 um 20:03 schrieb Eric Rescorla :
>
> > > 3) I know previous versions of TLS didn't say that much either, but I
> > > find it a bit wired that there are NO requirements for the underlaying
> > > transport in this document. Previous versio
64 matches
Mail list logo
