Re: [TLS] draft-rhrd-tls-tls13-visibility at IETF101

[Stephen Farrell]

Russ,

On 14/03/18 03:03, 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 that your draft
>> has not caused a lot of people to change their minds. Do you agree?
>> If so, then the conclusion is obvious, isn't it?
> 
> I see a handfull of very vocal people on this topic and many quiet
> ones. 

Handful? I don't think that's at all accurate.

But we know head-counting doesn't count of course.

My question to you, that you've not answered, was whether you agree
that your draft has not caused any significant shift in positions.

> I hum in the meeting is a meaningful way to find out what the
> quiet people are thinking.

And of course also any people who try pack out the room for any
reason;-(

S






> 
> Russ
> 
> 


0x7B172BEA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] draft-rhrd-tls-tls13-visibility at IETF101

[Stan Kalisch]

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 that your
>> draft has not caused a lot of people to change their minds. Do
>> you agree? If so, then the conclusion is obvious, isn't it?
> 
> I see a handfull of very vocal people on this topic and many quiet ones.

I see at least seventeen people (This properly excludes the one recent 
clarification) who have articulated an opinion against what the draft proposes:

https://www.ietf.org/mail-archive/web/tls/current/msg25643.html


Thanks,
Stan

> I hum in the meeting is a meaningful way to find out what the quiet people 
> are thinking.
> 
> Russ
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] draft-rhrd-tls-tls13-visibility at IETF101

[Russ Housley]

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 minds. Do
> you agree? If so, then the conclusion is obvious, isn't it?

I see a handfull of very vocal people on this topic and many quiet ones.  I hum 
in the meeting is a meaningful way to find out what the quiet people are 
thinking.

Russ

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] draft-rhrd-tls-tls13-visibility at IETF101

[Stephen Farrell]

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.  See 
> https://mailarchive.ietf.org/arch/msg/tls/NJEsyOZ8S3m8fiGk3bJ_lDnL-dg
>
> 

> 
> draft-rhrd-... addresses all four of these concerns.  We had some 
> discussion on the mail list, which lead to -01 being posted.

The problem you have however is that you're trying to square a
circle, so picking any set of N objections to try to address will
still leave you ending up with something unacceptable, for at
least one of a bunch of reasons. Partly, that's because you need
there to be a boundary between a data centre and the rest of the
Internet that's meaningful to TLS, and no such boundary exists.

(So the answer to Nalini's problems is: for applications causing
you this particular pain within a data centre don't use TLS,
find another way and while that might be painful for Nalini's
consortium, it's the right answer, given the overall costs of
anything else.)

> 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 minds. Do
you agree? If so, then the conclusion is obvious, isn't it?

S.


0x7B172BEA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] draft-rhrd-tls-tls13-visibility at IETF101

[Russ Housley]

>> 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 not that in the absence of agreement, work
> goes forward).  The problem is how to come to agreement, and
> what that typically involves is refining the proposal to
> address objections.

The Prague discussion was about draft-green-...  Nick Sullivan summarized four 
concerns with that approach.  See 
https://mailarchive.ietf.org/arch/msg/tls/NJEsyOZ8S3m8fiGk3bJ_lDnL-dg 


draft-rhrd-... addresses all four of these concerns.  We had some discussion on 
the mail list, which lead to -01 being posted.

I do not know if the TLS WG will want to adopt this approach.  I would like to 
find out.

Russ___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] draft-rhrd-tls-tls13-visibility at IETF101

[Kathleen Moriarty]

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 was.  More
>> discussion here would be good to figure out a way forward.  The chairs
>> have not agreed to allow the work to go forward, but just the
>> discussions to determine next steps.
>
> Part of the problem here, I think, is that it's not clear
> what's under discussion - the general problem or this
> specific draft.  I tend to think that discussions of the
> general problem will probably be unproductive and
> polarizing, and that if there is a way forward on this
> it's to have credible and specific technical proposals.
> Remember that in terms of process we don't need to have
> unanimity on a decision, but all serious technical
> objections need to be addressed and resolved.  So,
> if someone has a draft that can eventually clear that
> bar, proponents of allowing third parties to decrypt
> TLS sessions have a way forward.  (Unfortunately I
> don't think this draft can make it through).  At any
> rate I would regret (a lot) seeing discussion meander
> on over to the broader should-we-or-shouldn't-we question.

I think the chairs made it clear that it is on the specific draft and
they just have 10 minutes to present.  I believe the slides are
already posted and include the use cases within them.  We've all spent
way more than 10 in this discussion ;-)

It's up to the WG to decide and it seems a few want to discuss it,
even from the list that Stephen says are not interested.  I think it's
better to let the discussion happen.

Best,
Kathleen

>
> Melinda
>
> --
> Software longa, hardware brevis
>
> PGP fingerprint: 4F68 2D93 2A17 96F8 20F2
>  34C0 DFB8 9172 9A76 DB8F
>



-- 

Best regards,
Kathleen

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] draft-rhrd-tls-tls13-visibility at IETF101

[Melinda Shore]

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 way forward.  The chairs
> have not agreed to allow the work to go forward, but just the
> discussions to determine next steps.

Part of the problem here, I think, is that it's not clear
what's under discussion - the general problem or this
specific draft.  I tend to think that discussions of the
general problem will probably be unproductive and
polarizing, and that if there is a way forward on this
it's to have credible and specific technical proposals.
Remember that in terms of process we don't need to have
unanimity on a decision, but all serious technical
objections need to be addressed and resolved.  So,
if someone has a draft that can eventually clear that
bar, proponents of allowing third parties to decrypt
TLS sessions have a way forward.  (Unfortunately I
don't think this draft can make it through).  At any
rate I would regret (a lot) seeing discussion meander
on over to the broader should-we-or-shouldn't-we question.

Melinda

-- 
Software longa, hardware brevis

PGP fingerprint: 4F68 2D93 2A17 96F8 20F2
 34C0 DFB8 9172 9A76 DB8F



signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] draft-rhrd-tls-tls13-visibility at IETF101

[Kathleen Moriarty]

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 agreement in
> either direction there's no agreement (and I hope the default
> in the IETF is not that in the absence of agreement, work
> goes forward).  The problem is how to come to agreement, and
> what that typically involves is refining the proposal to
> address objections.

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 way forward.  The chairs
have not agreed to allow the work to go forward, but just the
discussions to determine next steps.

>
>> IIRC the supporters of draft-green-tls-static-dh-in-tls13 agreed to
>> drop that draft and come back with a new one which would hopefully be
>> more likely to get WG consensus. That draft has now arrived. It’s
>> unreasonable to deny the new I-D a fair hearing and even worse to
>> reject it out of hand.
>
> It's surprising that it got agenda time without mailing list
> discussion.  Aside from the changes to the key
> exchange there are some clear usability problems.  While
> usability usually lies outside the purview of the IETF's
> technical work, in this case the work is premised on the
> ability of the user to consent (or not) to sharing keying
> material with a third party, which in turn suggests that
> they're presented with the question at the time the
> session is initiated, so that the extension isn't sent in
> the ClientHello.  Sounds like a click-through problem,
> tbh, where the user has little practical control over whether
> or not their data are shared with a third party.

This should have had discussion time in Singapore, as the chairs
mentioned.  I'm mostly responding though because their use cases are
entirely server-to-server from what I understand.  The client
connection to the enterprise can terminate at the network edge, then
anything within the enterprise is from another encrypted session
(which could be TLS 1.2 or another protocol, or this proposal, or
something else including methods that eliminate the architectural
design for monitoring on the wire within the datacenter).  If there
were a way to limit this extension to server-to-server, that would
eliminate the click through problem you mention and the server admin
would be aware on either end of this usage.  I don't know if there is
a way to do this without using another protocol, but making the use
case clear may help with ideas.

Best,
Kathleen

>
> Melinda
>
>
> --
> Software longa, hardware brevis
>
> PGP fingerprint: 4F68 2D93 2A17 96F8 20F2
>  34C0 DFB8 9172 9A76 DB8F
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



-- 

Best regards,
Kathleen

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls