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. 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? 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? In short, this document needs a threat model (see RFC 3552) and an analysis of why this solution meets that threat model. 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. 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
