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

[Stephen Farrell <[e-mail]>]

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.
>