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. > 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? > That wouldn't work with TLS 1.2 but would work with TLS 1.2. > > 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. > 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. > > 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
