On Wed, Jul 10, 2013 at 5:39 PM, Nico Williams <n...@cryptonector.com>wrote:
> > > Also: despite mentioning a few proposals, there's no mention of > ChannelID / > > Channel-bound cookies [3]. > > > > ChannelID seems to solve these problems, seems more polished than other > > proposals, and apparently is being experimentally deployed (see Chrome | > > Preferences | Cookies and site data | "google.com" or "gmail.com"). > > There's definitely mention of channel binding. Channel bound cookies > used over HTTPS would meet the requirements of this spec, except for > the CRIME/BEAST resistance part. > > I'm not sure that we should mandate CRIME/BEAST resistance -- TLS > should arguably be able to resist such attacks. But it will take a > long time to deploy TLS that does, and that's what makes it appealing > to have CRIME/BEAST resistance in the session continuation protocol. We should not be mandating resistance to particular attacks already solved. But we should be mandating a change in the authentication design. The point is that the security of the authentication tokens should not be compromised even if the confidentiality scheme fails. Confidentiality should be built on authentication, not the other way round as using bearer tokens forces us to do. CRIME/BEAST would be a serious problem in any case and I find it amazing that we still have people pushing header compression schemes even now. And thats not the end of the problems either. The 'make it unsafe, we want speed' crowd is currently looking at using HTTP over UDP for bulk transport (not CoAP, web browsing) so expect DoS problems to get much worse. The lesson we should be drawing from CRIME/BEAST is that the web browser developers don't actually give a damn about security. There are security people working for them but don't be fooled, the people who manage those products don't consider security a priority or else we would have revocation checking in SSL clients that is meaningful and many other things. The KGB and the NSA both have doctrines that say that a system must be robust in the case of failure of a cryptographic protocol. We have to adopt the same sort of approach because modern Web browsers are ridiculously complex and getting more so. There is nobody who can claim to understand and be able to vouch for the security of the interactions between all the components. CRIME is a consequence of two design decisions taken without care for security: header compression and active code. Those two decisions are not going to be the last. Since we can't understand the consequences of those interactions our only viable design approach is to design the session continuation scheme so that the security of the authentication secrets ONLY depends on things we can count on. > >> - Will you be willing to review the problem statement? > >> - Will you be willing to read multiple solution proposals to help the > >> working group choose? > >> - Will you be willing to review the solution document? > > > > I'd be more interested in websec taking this on if someone could argue > why > > ChannelID is *not* the right solution, and had some ideas how to do > better. > > See above. > > Nico > -- > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > -- Website: http://hallambaker.com/
_______________________________________________ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
