Re: [Lurk] Is this scenario covered by LURK?

[Eric Burger <[e-mail]>]

<not as BOF chair>
The technology for ‘lawful’ intercept is indistinguishable from criminal eavesdropping is indistinguishable from ‘friendly’ DPI.

IMHO, if this scenario is covered by LURK, LURK must not be chartered and we all can go home.

> On Jun 21, 2016, at 10:14 PM, Youjianjie <[e-mail]> wrote:
> 
> Hi Thomas,
> 
> We’re thinking in this use case, if middle-box does traffic management, the three participated parties (i.e. client, server, and middle-box) should all be aware of this. Therefore, when the key manager (representing middle-box) asks the key server for key information, the key manager maybe needs to carry the digital signed data from the client (indicating client agreed and aware of this), 5-tuple (indicating which connection is decrypted), and decryption reason etc. These information are not discussed in the current document https://tools.ietf.org/html/draft-cairns-tls-session-key-interface-01 <https://tools.ietf.org/html/draft-cairns-tls-session-key-interface-01> . We’re wondering if these information are reasonable via SKI?
> 
> Your comments are welcome!
> 
> Thanks,
> Jianjie
> 
> 
> 发件人: Fossati, Thomas (Nokia - GB) [mailto:[e-mail]]
> 发送时间: 2016年6月21日 18:53
> 收件人: Youjianjie; Fossati, Thomas (Nokia - GB); Daniel Migault; [e-mail]
> 主题: Re: 答复: 答复: 答复: [Lurk] 答复: Is this scenario covered by LURK?
> 
> HI Jianjie,
> 
> I understand the two use cases are completely different, I'm not sure there'd be any substantial distinction in terms of interfaces though.
> 
> Cheers, t
> 
> From: Youjianjie <[e-mail] <mailto:[e-mail]>>
> Date: Tuesday, 21 June 2016 10:36
> To: "Fossati, Thomas (Nokia - GB)" <[e-mail] <mailto:[e-mail]>>, Daniel Migault <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
> Subject: 答复: 答复: 答复: [Lurk] 答复: Is this scenario covered by LURK?
> 
> Hi Thomas,
> 
> I think the second is different from the lawful interception. In this option, the edge server (middle-box) does and only does policy control when it is authorized and has the key information from the content owner. So, here’s an assumption that the content provider and the content owner should have some agreement for doing this, otherwise, the key information will not be provided to the middle-box for traffic optimization for example. That’s why we need to define the interface between the key manager and key server.
> 
> What do you think?
> 
> Thanks,
> Jianjie
> 
> 发件人: Fossati, Thomas (Nokia - GB) [mailto:[e-mail] <mailto:[e-mail]>]
> 发送时间: 2016年6月21日 17:19
> 收件人: Youjianjie; Fossati, Thomas (Nokia - GB); Daniel Migault; [e-mail] <mailto:[e-mail]>
> 主题: Re: 答复: 答复: [Lurk] 答复: Is this scenario covered by LURK?
> 
> Hi Jianjie,
> 
> Yes, both options are possible but the second looks very much like a lawful interception interface to me.
> 
> So, unless you are ready to convince the IETF that an update of RFC 2804 is in order, I guess that option is actually precluded?
> 
> Cheers, t
> 
> From: Youjianjie <[e-mail] <mailto:[e-mail]>>
> Date: Tuesday, 21 June 2016 03:56
> To: "Fossati, Thomas (Nokia - GB)" <[e-mail] <mailto:[e-mail]>>, Daniel Migault <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
> Subject: 答复: 答复: [Lurk] 答复: Is this scenario covered by LURK?
> 
> Hi Thomas,
> 
> One way is the middle-box submits a chunk of encrypted bytes to the Key Manager and gets the clear-text back. The other way is the middle-box gets the key information from the Key Manager. I think both are possible.
> 
> I’m wondering if this use case could be merged into the existing use case document? If the use case is acceptable, we’ll describe the interface requirements for it.
> 
> Thanks,
> Jianjie
> 
> 发件人: Fossati, Thomas (Nokia - GB) [mailto:[e-mail] <mailto:[e-mail]>]
> 发送时间: 2016年6月20日 17:18
> 收件人: Youjianjie; Fossati, Thomas (Nokia - GB); Daniel Migault; [e-mail] <mailto:[e-mail]>
> 主题: Re: 答复: [Lurk] 答复: Is this scenario covered by LURK?
> 
> Thanks Jianjie.
> 
> I was slightly confused because in the discussion so far (and in the LURK drafts) "edge server" has been used with distinct semantics ― i.e. a HTTP edge cache that terminates TLS.  Instead, in your picture it's used to mean "traffic management middle-box": firewall, IDS, anti-spam/malware, load balancer, whatever.
> 
> IIUC, what you want to achieve is that these middle-boxes submit a chunk of encrypted bytes to the Key Server and get the clear-text back (sort of DPI by proxy if you like) while at the same time hiding topological details about the Gi-LAN (though this seems to be ancillary).
> 
> While I think this is an interesting idea, I'm concerned that pulling this use case in to the picture at this point in time would derail the working group focus in endless political discussions.
> 
> However, we should keep in the back of our mind the fact that LURK must evolve (both refining existing use cases and incorporating new ones as well) and thus it needs to be built with an extensible interface from the onset.
> 
> Cheers, t
> 
> PS: It'd be nice if you took some time to draft the interfaces so that we can have a more precise idea of what you have in mind?
> 
> From: Youjianjie <[e-mail] <mailto:[e-mail]>>
> Date: Monday, 20 June 2016 07:26
> To: "Fossati, Thomas (Nokia - GB)" <[e-mail] <mailto:[e-mail]>>, Daniel Migault <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
> Subject: 答复: [Lurk] 答复: Is this scenario covered by LURK?
> 
> Hi Thomas,
> 
> It is the latter. In this figure, the edge server (e.g. middle-box) can manage the encrypted flows if it is trusted and authorized to have the key from Key server via Key manager.
> 
> We introduce a Key manager because there may be many edge servers in the network. It's better not to expose the topology of edge servers to the content owner if the Content Provider and the Content Owner are in different administrative domain.
> 
> Further comments are welcome.
> 
> Thanks,
> Jianjie
> 
> 
> 发件人: Lurk [mailto:[e-mail] <mailto:[e-mail]>] 代表 Fossati, Thomas (Nokia - GB)
> 发送时间: 2016年6月19日 1:39
> 收件人: Youjianjie; Daniel Migault; Fossati, Thomas (Nokia - GB); [e-mail] <mailto:[e-mail]>
> 主题: Re: [Lurk] 答复: Is this scenario covered by LURK?
> 
> Hi Jianjie,
> 
> I've been staring at the picture for a while but I still don't understand whether what you call "Edge Server" is actually a cache that terminates the TLS connection on behalf of the content owner, or some other middle-box that needs to do traffic management and wants to talk to the Key Server to DPI the encrypted flows.
> 
> If the former, your "Key Manager" is really just a LURK proxy ― I don't think there is anything new to standardise once the LURK interfaces are defined.
> 
> If the latter, I don't seem to remember anyone presenting this use case either at the BoF, on list, or in the interim meeting.
> 
> Cheers, t
> 
> From: Youjianjie <[e-mail] <mailto:[e-mail]>>
> Date: Friday, 17 June 2016 03:42
> To: Daniel Migault <[e-mail] <mailto:[e-mail]>>, "Fossati, Thomas (Nokia - GB)" <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
> Subject: 答复: [Lurk] Is this scenario covered by LURK?
> 
> Hi Daniel, Thomas,
> 
> Here’s a diagram illustrating the scenario I want to mean.
> 
> <image001.jpg>
> 
> Please also see my comments inline below:
> 
> Thanks,
> Jianjie
> > -----邮件原件-----
> > 发件人: Daniel Migault [mailto:[e-mail] <mailto:[e-mail]>]
> > 发送时间: 2016年6月16日 21:27
> > 收件人: Fossati, Thomas (Nokia - GB); Youjianjie; [e-mail] <mailto:[e-mail]>
> > 主题: RE: [Lurk] Is this scenario covered by LURK?
> >
> > Hi Jianjie,
> >
> > Thank you for bringing a potential new use case. Currently LURK aims at
> > providing an interface between Edge Servers and the Key Server in a context of
> > TLS. If I am correct, the use case you provide introduces an additional element
> > designated as a Key Manager.  From the description it is not clear to me what
> > role the Key Manager has, and its relation with the Edge Servers and the Key
> > Server.
> 
> The reason why we introduce a Key manager is that there're many edge servers in some cases. It's better not to expose the topology of edge servers to the content owner if the Content Provider and the Content Owner are in different administrative domain.
> 
> > Could you specify what role the Key Manager has as well as interactions
> > between:
> >    -  the Key Manger and Key Server
> 
> Key information needs to be interacted between them.
> 
> >    - the Key Manager and the Edge Server
> 
> Key information needs to be interacted between them.
> 
> > In addition, it might be also helpful to provide feed back why you think the use
> > cases of the draft do not address your use case. Could you please point what is
> > missing ?
> 
> Is the content owner also expected to deliver content traffic in the current use case doc?
> https://tools.ietf.org/html/draft-mglt-lurk-tls-use-cases-01 <https://tools.ietf.org/html/draft-mglt-lurk-tls-use-cases-01>
> 
> > BR,
> > Daniel
> >
> >
> > -----Original Message-----
> > From: Lurk [mailto:[e-mail] <mailto:[e-mail]>] On Behalf Of Fossati, Thomas
> > (Nokia - GB)
> > Sent: Thursday, June 16, 2016 8:40 AM
> > To: Youjianjie; [e-mail] <mailto:[e-mail]>
> > Subject: Re: [Lurk] Is this scenario covered by LURK?
> >
> > Hi Jianjie,
> >
> > On 16/06/2016 04:31, "Lurk on behalf of Youjianjie" <[e-mail] <mailto:[e-mail][e-mail]>
> > on behalf of [e-mail] <mailto:[e-mail][e-mail]>> wrote:
> > >Hi
> > >
> > >I've a question about the scenario. I'm not sure if the following
> > >scenario is covered by the LURK.
> > >
> > >In this scenario, the Content Provider and the Content Owner are in
> > >different administrative domain. Content owner is also responsible to
> > >deliver the content. The content provider participates the delivery of
> > >a content, providing necessary traffic management, such as FW, IPS.
> > >
> > >For example, the edge server can be middle-box in the operator's network.
> > >There may be multiple middle-boxes, which can be managed by a key
> > >manager in the operator's network. In order to do traffic management,
> > >the key manager needs to interact with the key server located in the
> > >content owner domain, in order to do traffic management since the
> > >packets are encrypted. Here, the interaction between key manager (e.g.
> > >operator's
> > >network) and key server (in content owner) needs to be standardized? Is
> > >this use case in the scope of LURK?
> >
> > Could you spend a few more lines on the kind of interaction that you are
> > envisaging between the key manager and the key server?
> >
> > Cheers, t
> >
> > _______________________________________________
> > Lurk mailing list
> > [e-mail] <mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/lurk <https://www.ietf.org/mailman/listinfo/lurk>_______________________________________________
> Lurk mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lurk