Subject: [TLS] A TLS extension transfering service indication information

From: "Dacheng Zhang" <[email-masked]>
Date: Tue, 29 Mar 2016 09:50:13 +0800

Hi, 

We have proposed an exension for TLS to transfer the information indicating
the service the client intends  to access. A motivation scenario is the
reverse charging.

Any comments and suggestions are really appreciated.

You can find the draft through the following link:

https://datatracker.ietf.org/doc/draft-zhang-tls-service-indication-extensio
n/

In addition, can we get a time slot to present this work in TLS please?

Cheers

Dacheng

---

From: Dave Garrett <[email-masked]>
Date: Tue, 29 Mar 2016 01:13:08 -0400

On Monday, March 28, 2016 09:50:13 pm Dacheng Zhang wrote:
> https://datatracker.ietf.org/doc/draft-zhang-tls-service-indication-extension/

You really should not use SNI as your abbreviation, as it will just be frequently confused with the server_name extension which is already the dominant use of those initials in TLS.

Dave

---

From: "Dacheng Zhang" <[email-masked]>
Date: Tue, 29 Mar 2016 13:51:49 +0800

OK，thanks for your comments. Will fix this issue in the next version.

---

From: Dave Garrett <[email-masked]>
Date: Tue, 29 Mar 2016 02:52:16 -0400

On Tuesday, March 29, 2016 01:35:50 am Eric Mill wrote:
> It looks like the abbreviation this draft uses is just "SI". It uses SNI at
> the top a few times to refer to Server Name Indication (which it typos as
> "service" name extension).
> 
> On Tue, Mar 29, 2016 at 1:13 AM, Dave Garrett <[email-masked]> wrote:
> > You really should not use SNI as your abbreviation, as it will just be
> > frequently confused with the server_name extension which is already the
> > dominant use of those initials in TLS.

You're correct; my mistake. I didn't notice the typo and reading a spec draft whilst tired is not always the best of ideas. ;)

CCing back to list and thread starter to make sure my correction is OTR for the list.

Fixing that typo in the draft would help to avoid future misreadings. Sticking in a direct reference to RFC6066 on first mention of SNI could add another level of clarification, if desired.

Thanks for quickly correcting me.

Dave

---

From: "Dacheng Zhang" <[email-masked]>
Date: Tue, 29 Mar 2016 15:48:15 +0800

Hi,
Actually, we refer to the extension as a 'SNI' extension. In this extension, SI(service indication) information is provided. In the next version, we will use 'SI extension' to take place of 'SNI extension'. ^_^
Cheers
Dacheng

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 29 Mar 2016 16:21:08 -0700

I have taken an initial look at this document, but I find myself confused
about the security
model.

Specifically, you say that you can't use SNI because customers will lie and
insert
the SNI for service A in the ClientHello when going to service B. However,
I don't
see how this token stops that, since all it represents is a bare assertion
of where
you are going that is authenticated with a MAC shared between the client,
the
ICP, and the ISP. What stops the client from doing the same thing, i.e.,
injecting
the token for service A into a connection destined for service B? B can
just ignore
the SI token, right?

Second if the tokens are client specific, what stops an attacker from
copying my
token and then replaying it in a separate connection, thus potentially
causing
the system to charge me or at least to use my rates for the attacker?

In short, this document needs a threat model (see RFC 3552) and an analysis
of why this solution meets that threat model.

Finally, why am I seeing what appears to be a MAC algorithm definition in
Section
2.1. Is there a reason you can't just use/cite HMAC?

-Ekr

On Tue, Mar 29, 2016 at 12:48 AM, Dacheng Zhang <[email-masked]
> wrote:

> Hi,
>
> Actually, we refer to the extension as a 'SNI' extension. In this
> extension, SI(service indication) information is provided. In the next
> version, we will use 'SI extension' to take place of 'SNI extension'. ^_^
>
> Cheers
>
> Dacheng
>
> ------------------------------------------------------------------
> 发件人：Dave Garrett <[email-masked]>
> 发送时间：2016年3月29日(星期二) 14:52
> 收件人：Eric Mill <[email-masked]>
> 抄 送：tls <[email-masked]>，张大成(淡久) <[email-masked]>
> 主 题：Re: [TLS] A TLS extension transfering service indication information
>
> > On Tue, Mar 29, 2016 at 1:13 AM, Dave Garrett <[email-masked]
> > wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: "Dacheng Zhang" <[email-masked]>
Date: Wed, 30 Mar 2016 09:42:21 +0800

Hi, Ekr:

Thanks for reviewing the draft and the comments. Please see my reply inline
please.

发件人:  Eric Rescorla <[email-masked]>
日期:  2016年3月30日 星期三 上午7:21
至:  dacheng de <[email-masked]>
抄送:  Eric Mill <[email-masked]>, Dave Garrett <[email-masked]>,
tls <[email-masked]>
主题:  Re: [TLS] 回复： A TLS extension transfering service indication
information

Specifically, you say that you can't use SNI because customers will lie and
insert
the SNI for service A in the ClientHello when going to service B. However, I
don't
see how this token stops that, since all it represents is a bare assertion
of where
you are going that is authenticated with a MAC shared between the client,
the
ICP, and the ISP. What stops the client from doing the same thing, i.e.,
injecting
the token for service A into a connection destined for service B? B can just
ignore
the SI token, right?

Dacheng： This is a very good point. How to secure the APPs on the client
device (e.g., How to secure client and prevent the message sent out from an
APP provided by ICP A from being intercepted by an APP provided by ICP B
installed on the same mobile)  is a hot topic. Lots of people are working
hard to address this issue. For instance, TEE is an attempt of protecting
the security of APPS on a mobile. In a TEE, APPs action are controlled and
secure channels are provided to distributed keys. So, in our solution, we
did not consider the case where the execution environment of APPs is not
secure. We assume if an attacker or a malicious has compromise a mobile, it
could cause more serious damages.

Dacheng: You are right. Since we use timestamps, there could a window for an
attacker to perform attacks by replaying or reusing the token. But we have
narrow down the attack window and mitigate the problem. But Thank you for
this comment. I got an idea. If the HMAC can cover the whole client hello
message, it will be harder for the attacker to reuse the token.Thoughts?

Dacheng: Agree! Will do that in the next version. In addition, we will be
very happy if you have no problem with the requirement. We found this issue
when we tried to widely use TLS to secure the communications between our
APPs and our services. If there could be any better idea or solution, we
will be very happy to support it.

Dacheng: I reuse this content from my previous drafts. If people don’t like
it, we could remove it. ^_^

Thanks a lot for your review, and look forward to further discussions on
this topic. ^_^

Cheers

Dacheng

-Ekr

On Tue, Mar 29, 2016 at 12:48 AM, Dacheng Zhang
<[email-masked]> wrote:
> Hi,
> 
> Actually, we refer to the extension as a 'SNI' extension. In this extension,
> SI(service indication) information is provided. In the next version, we will
> use 'SI extension' to take place of 'SNI extension'. ^_^
> 
> Cheers
> 
> Dacheng
>> You're correct; my mistake. I didn't notice the typo and reading a spec draft
>> whilst tired is not always the best of ideas. ;)
>> 
>> Fixing that typo in the draft would help to avoid future misreadings.
>> Sticking in a direct reference to RFC6066 on first mention of SNI could add
>> another level of clarification, if desired.
>>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 29 Mar 2016 20:19:25 -0700

On Tue, Mar 29, 2016 at 6:42 PM, Dacheng Zhang <[email-masked]>
wrote:

> Hi, Ekr:
>
> Thanks for reviewing the draft and the comments. Please see my reply
> inline please.
>
> Specifically, you say that you can't use SNI because customers will lie
> and insert

I'm not following. If you trust the device, then why do you need any kind
of cryptographic
authentication on the token.

> Dacheng: You are right. Since we use timestamps, there could a window for
> an attacker to perform attacks by replaying or reusing the token. But we
> have narrow down the attack window and mitigate the problem. But Thank you
> for this comment. I got an idea. If the HMAC can cover the whole client
> hello message, it will be harder for the attacker to reuse the
> token.Thoughts?
>

That wouldn't work with TLS 1.2 but would work with TLS 1.2.

> very happy if you have no problem with the requirement.
>

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.

-Ekr

> We found this issue when we tried to widely use TLS to secure the
> communications between our APPs and our services. If there could be any
> better idea or solution, we will be very happy to support it.
>
> Dacheng: I reuse this content from my previous drafts. If people don’t
> like it, we could remove it. ^_^
>
> On Tue, Mar 29, 2016 at 12:48 AM, Dacheng Zhang <
> [email-masked]> wrote:
>
>> Hi,
>>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 30 Mar 2016 14:53:49 +1100

> That wouldn't work with TLS 1.2 but would work with TLS 1.2.

I think that you meant that it would work with TLS 1.2 and extended
master secret, or TLS 1.3.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 29 Mar 2016 20:59:19 -0700

I meant "would work with TLS 1.3". I don't believe it will work with TLS
1.2 even
with EMS because (even with the MAC) the SI extension is bound to the
ClientHello
which is replayable in 1.2 because it contains public information, with the
only non-fixed information being the random. However in 1.3 it contains the
DH
key share, which the attacker doesn't know the corresponding private value
for.

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Wed, 30 Mar 2016 15:01:26 +1100

On 30 March 2016 at 14:59, Eric Rescorla <[email-masked]> wrote:
> I meant "would work with TLS 1.3". I don't believe it will work with TLS 1.2
> even

Right.  Score one for TLS 1.3.

---

From: "Dacheng Zhang" <[email-masked]>
Date: Wed, 30 Mar 2016 12:04:32 +0800

Hi, Erk:

My reply inline please.

Cheers

Dacheng

日期:  2016年3月30日 星期三 上午11:19

On Tue, Mar 29, 2016 at 6:42 PM, Dacheng Zhang <[email-masked]>
wrote:
> 抄送:  Eric Mill <[email-masked]>, Dave Garrett <[email-masked]>, tls
> <[email-masked]>
> 主题:  Re: [TLS] 回复： A TLS extension transfering service indication information
> 
> see how this token stops that, since all it represents is a bare assertion of
> where
> you are going that is authenticated with a MAC shared between the client, the
> installed on the same mobile)  is a hot topic. Lots of people are working hard
> to address this issue. For instance, TEE is an attempt of protecting the
> security of APPS on a mobile. In a TEE, APPs action are controlled and secure
> channels are provided to distributed keys. So, in our solution, we did not
> consider the case where the execution environment of APPs is not secure. We
> assume if an attacker or a malicious has compromise a mobile, it could cause
> more serious damages.

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?

> 
> Second if the tokens are client specific, what stops an attacker from copying
> my
> token and then replaying it in a separate connection, thus potentially causing
> narrow down the attack window and mitigate the problem. But Thank you for this
> comment. I got an idea. If the HMAC can cover the whole client hello message,
> it will be harder for the attacker to reuse the token.Thoughts?

> Dacheng: Agree! Will do that in the next version. In addition, we will be very
> happy if you have no problem with the requirement.

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.

-Ekr

> communications between our APPs and our services. If there could be any better
> idea or solution, we will be very happy to support it.
> 
> Thanks a lot for your review, and look forward to further discussions on this
> topic. ^_^
> 
> Cheers
> 
> Dacheng
> 
> -Ekr
> 
> 
> 
> 
> 
> 
> 
> 
> On Tue, Mar 29, 2016 at 12:48 AM, Dacheng Zhang <[email-masked]>
> wrote:
>> Hi,
>> 
https://datatracker.ietf.org/doc/draft-zhang-tls-service-indication-extens>>>>>
ion/
>>> You're correct; my mistake. I didn't notice the typo and reading a spec
>>> draft whilst tired is not always the best of ideas. ;)
>>>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 30 Mar 2016 15:06:27 +1100

> purpose, we need to do some additional work to address this issue, right?

What is wrong with client authentication?

---

From: "Dacheng Zhang" <[email-masked]>
Date: Wed, 30 Mar 2016 12:08:24 +0800

Right. When we design this solution, we assume it will work with TLS1.3. The
TLS WG has stopped working on the extensions for TLS 1.2, right?

发件人:  Eric Rescorla <[email-masked]>
日期:  2016年3月30日 星期三 上午11:59
至:  Martin Thomson <[email-masked]>
抄送:  dacheng de <[email-masked]>, tls <[email-masked]>
主题:  Re: [TLS] 回复： A TLS extension transfering service indication
information

-Ekr

---

From: "Dacheng Zhang" <[email-masked]>
Date: Wed, 30 Mar 2016 12:12:37 +0800

The charging GW will not authenticate the client, it only needs to be
informed how the following traffics will be charged, in a trusted way.
That is why we will do this work. For secure reasons, we intend to use TLS
to secure the traffics to or from our APP. So, we need to provide such
information in some way to the charging GW of ISP.

---

From: Peter Bowen <[email-masked]>
Date: Tue, 29 Mar 2016 21:17:01 -0700

It doesn't seem to be clearly spelled out: is the "charging GW" a
system that can read data passing between the client and server but
cannot modify it?  If so, do I have it right that you are trying to
design an extension that allows the client to send a message that can
be observed but not tampered?

---

From: Martin Thomson <[email-masked]>
Date: Wed, 30 Mar 2016 15:17:06 +1100

> informed how the following traffics will be charged, in a trusted way.

We've seen this request before.  It's not an easy question to answer.

In short, you want to make information about a flow (meta-information)
available to on-path intermediaries.

I believe that there is work ongoing in this area.

draft-you-tsvwg-latency-loss-tradeoff, see
https://mailarchive.ietf.org/arch/msg/accord/Jsbz-Iatb3WJTuFuvOzkdRrK-uI

And the upcoming accord BOF.

---

From: "Dacheng Zhang" <[email-masked]>
Date: Wed, 30 Mar 2016 12:27:29 +0800

Hi, Martin:

We are following the progress of that work. But in principle, any
extension to TLS should be done in this group, that is why we raised the
discussion in the TLS list. ^_^

Cheers

Dacheng

---

From: "Dacheng Zhang" <[email-masked]>
Date: Wed, 30 Mar 2016 13:14:31 +0800

>be observed but not tampered?
We translate that term from Chinese directly, and sorry for the confusion
caused. You are right, we trying to do this work in a standard way.

There could be hundreds of millions APP in use. The solution should be
scalable and light weight.

Cheers

Dacheng

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 30 Mar 2016 08:32:36 -0700

On Tue, Mar 29, 2016 at 9:04 PM, Dacheng Zhang <[email-masked]>
wrote:

> On Tue, Mar 29, 2016 at 6:42 PM, Dacheng Zhang <
>> the SNI for service A in the ClientHello when going to service B.
>> However, I don't
>> see how this token stops that, since all it represents is a bare
>> assertion of where
>> installed on the same mobile)  is a hot topic. Lots of people are
>> working hard to address this issue. For instance, TEE is an attempt of
>> protecting the security of APPS on a mobile. In a TEE, APPs action are
>> controlled and secure channels are provided to distributed keys. So, in our
>> solution, we did not consider the case where the execution environment of
>> APPs is not secure. We assume if an attacker or a malicious has compromise
>> a mobile, it could cause more serious damages.
>>
>

Again, you need a threat model. It sounds like you both do and do not trust
the client

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

-Ekr

---

From: "Dacheng Zhang" <[email-masked]>
Date: Thu, 31 Mar 2016 13:40:55 +0800

Thanks again for your comments. See my reply inline please. ^_^
> 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?

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.

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.

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.

Look forward to more discussions. ^_^

Cheers

Dacheng

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 31 Mar 2016 06:54:52 -0700

On Wed, Mar 30, 2016 at 10:40 PM, Dacheng Zhang <[email-masked]

> Again, you need a threat model. It sounds like you both do and do not
> trust the client
>
> 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.

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

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.

-Ekr

---

From: "Dacheng Zhang" <[email-masked]>
Date: Fri, 01 Apr 2016 09:45:48 +0800

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

On Wed, Mar 30, 2016 at 10:40 PM, Dacheng Zhang
<[email-masked]> wrote:
>> 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?
> 
> 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.

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.

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

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