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