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? > > 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. 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 > 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-extens>>>>> ion/ >>>>> > > >>>>> > > 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
