[Lurk] 答复: 答复: 答复: 答复: Is this scenario covered by LURK?

[Youjianjie <[e-mail]>]

Hi Stephen,

Thanks for detailed explanation. I've got better understanding of RFC2804. I agree that TLS MitM should not be in the scope of LURK. 

I've a question about the current use cases (https://tools.ietf.org/html/draft-mglt-lurk-tls-use-cases-01), do you think the TLS client needs to be aware of the decryption by the edge server? For example, in Content Owner / Content Provider Use Case, they are in different administrative domain. The TLS client is the subscriber of the content owner not the content provider. 

Thanks,
Jianjie

> -----邮件原件-----
> 发件人: Stephen Farrell [mailto:[e-mail]]
> 发送时间: 2016年6月23日 17:04
> 收件人: Youjianjie; Fossati, Thomas (Nokia - GB); Daniel Migault; [e-mail]
> 主题: Re: 答复: [Lurk] 答复: 答复: Is this scenario covered by LURK?
> 
> 
> 
> On 23/06/16 09:13, Youjianjie wrote:
> > Hi Stephen,
> >
> > I read RFC2804. I'm confused about the problem for the middle-box use
> > case. In this use case, the sending party, the recipient party and
> > the middle-box are all know about the traffic management.
> 
> "Traffic management" here being a euphemism for TLS MitM I guess.
> 
> > The
> > assumption is they've negotiated and agreed for doing this. Is it
> > still inconsistent with RFC2804?
> 
> IMO, practically, yes. Standardising a TLS MitM is exactly the kind
> of thing that is not consistent with RFC2804. And that has been
> proposed and rejected numerous times. Please see the httpbis and TLS
> WG archives for discussion that we ought not repeat here for the N-th
> time.
> 
> Second, any assumption that the TLS client is modified, is also, I
> think, likely best considered out of scope of LURK. The one use-case
> on which we clearly have interest involves browsers and CDNs and web
> sites. Browsers afaik have zero interest in enabling a new TLS MitM
> (I certainly hope they don't) no matter how such a "feature" is
> named.
> 
> ISTM that this thread is a side-track that leads nowhere.
> 
> S.
> 
> >
> > Thanks, Jianjie
> >
> >> -----邮件原件----- 发件人: Stephen Farrell
> >> [mailto:[e-mail]] 发送时间: 2016年6月22日 18:22 收
> 件人:
> >> Youjianjie; Fossati, Thomas (Nokia - GB); Daniel Migault;
> >> [e-mail] 主题: Re: [Lurk] 答复: 答复: Is this scenario covered by
> >> LURK?
> >>
> >>
> >>
> >> On 22/06/16 09:40, Youjianjie wrote:
> >>> It is about decryption under the negotiation agreement among the
> >> participated parties.
> >>
> >> Not wearing any hats, but if work in lurk is inconsistent with
> >> RFC2804 that will IMO be a significant negative.
> >>
> >> I'd say there are use-cases for lurk that don't have that problem
> >> and that developing those would be more productive.
> >>
> >> S.
> >>
> >> PS: I'd say exactly the same about using spud/plus to do things
> >> that RFC2804 says we don't do so this isn't really a "what venue"
> >> issue.
> >