Re: [TLS] 回复： A TLS extension transfering service indication information

["Dacheng Zhang" <[e-mail]>]

发件人:  Eric Rescorla <[e-mail]>
日期:  2016年3月31日 星期四 下午9:54
至:  dacheng de <[e-mail]>
抄送:  Eric Mill <[e-mail]>, Dave Garrett <[e-mail]>,
tls <[e-mail]>, "刘大鹏(鹏成)" <[e-mail]>
主题:  Re: [TLS] 回复： A TLS extension transfering service indication
information



On Wed, Mar 30, 2016 at 10:40 PM, Dacheng Zhang
<[e-mail]> wrote:
> Thanks again for your comments. See my reply inline please. ^_^
>> 
>> I'm not following. If you trust the device, then why do you need any kind of
>> cryptographic
>> authentication on the token.
>> 
>> Dacheng：Let assume we trust the device. But the APP use a SNI to indicate the
>> service that the APP intends to access. Because the SNI is static which may
>> not be changed for months, it is easier for attackers who monitor the network
>> to get the SNI and use it to gain benefit. We need a securer solution. As I
>> have mentioned in my previous email, this solution will make such attacks
>> more difficult. By the way, SNI is not designed for this purpose, we need to
>> do some additional work to address this issue, right?
> 
> Again, you need a threat model. It sounds like you both do and do not trust
> the client
> 
> Dacheng: Threat model will be provided. Actually，we don’t try to protect
> against the compromise of client. Or the scenario where an APP against another
> one on the same device. This solution is used to protect against the attackers
> who are able to monitoring the communication between the client and the server

I'll await this.

 
> 
>> 
>> Hmm... I'm not at all sure that TLS should address this problem. However, my
>> review
>> was directed to whether your proposed solution even works on its own terms.
>> 
>> Dacheng: That is why we need to raise the discussion here. It would be great
>> if this issue could be considered by TLS WG.
> 
> I don't find this to be a very compelling use case and I don't think it's
> really appropriate to
> try to solve it at the TLS layer. If you want to have secure flow
> identification you should
> do it at the IP or TCP layers.
> 
> Dacheng:Ok, this requirement is quite strong. We need a solution to address
> this issue if we want to use TLS to secure our APPs deployed on hundreds o
> millions o mobile devices.  Also，China mobile and Huawei are working with us
> on this issue.

No, you only need it if you want to use a specific charging model.

Dacheng This is an important business model which will benefit both
customers and ICPs. But we cannot support it for the moment when we use TLS
to secure the traffic.


> Could you please tell me why it is better to address this issue at the IP or
> TCP layer. To the best of my knowledge. There is no space in IPv4 herders to
> insert any extensions. There are length limit in TCP options. In addition, TCP
> is implemented in kernel mode. It will cost more if we try to address this
> issue at the TCP or IP layer.

I think the architectural reasons here are pretty clear. IP is the common
network transport
layer, not TLS. Also, IPv6 has extension headers.

Dacheng: I consulted this to a lot of people. It seems they think in a
different way. The deployment of changes in TCP or IP are much more
difficiult. Currently, IPv4 rather than IPv6 is being used. This means our
online system still not be able to support this charging model for multiple
years. In addition, IP is at network layer protocol，while this work is about
providing information which indicate how to charge a flow. The work related
with a flow should be done at the transport layer or higher. Please correct
me if I am wrong.This issue is raised because the widely usage of TLS. If
Ipsec will be used to secure the communication between mobile and cloud. We
need to  address it at the IP layer. ^_^

-Ekr


> Look forward to more discussions. ^_^
> 
> Cheers
> 
> Dacheng
>>>> 
>>>> 
>>> 
>> 
>