On Tue, Mar 29, 2016 at 9:04 PM, Dacheng Zhang <dacheng....@alibaba-inc.com> wrote:
> Hi, Erk: > > My reply inline please. > > Cheers > > Dacheng > > 发件人: Eric Rescorla <e...@rtfm.com> > 日期: 2016年3月30日 星期三 上午11:19 > 至: dacheng de <dacheng....@alibaba-inc.com> > 抄送: Eric Mill <e...@konklone.com>, Dave Garrett <davemgarr...@gmail.com>, > tls <tls@ietf.org> > 主题: Re: [TLS] 回复： A TLS extension transfering service indication > information > > > > On Tue, Mar 29, 2016 at 6:42 PM, Dacheng Zhang < > dacheng....@alibaba-inc.com> wrote: > >> Hi, Ekr: >> >> Thanks for reviewing the draft and the comments. Please see my reply >> inline please. >> >> 发件人: Eric Rescorla <e...@rtfm.com> >> 日期: 2016年3月30日 星期三 上午7:21 >> 至: dacheng de <dacheng....@alibaba-inc.com> >> 抄送: Eric Mill <e...@konklone.com>, Dave Garrett <davemgarr...@gmail.com>, >> tls <tls@ietf.org> >> 主题: Re: [TLS] 回复： A TLS extension transfering service indication >> information >> >> 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? >> >> 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. >> > > 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 > 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. -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. >> >> 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? >> >> 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 < >> dacheng....@alibaba-inc.com> 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 <davemgarr...@gmail.com> >>> 发送时间：2016年3月29日(星期二) 14:52 >>> 收件人：Eric Mill <e...@konklone.com> >>> 抄 送：tls <tls@ietf.org>，张大成(淡久) <dacheng....@alibaba-inc.com> >>> 主 题：Re: [TLS] A TLS extension transfering service indication information >>> >>> 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 <davemgarr...@gmail.com >>> > wrote: >>> > > 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. >>> >>> >>> 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 >>> >>> >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >>> >> >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
