On 2/23/06, James Holderness <[EMAIL PROTECTED]> wrote: > > I understand the desire for interoperability, but if you have to make a > recommendation, why Basic+TLS rather than say Digest without TLS which is > certainly a lot easier? There may be very convincing security reasons for > wanting to recommend TLS but I don't know enough about security to know what > these arguments are. So far the only complaint I've seen against Digest was > that someone hacking into your password database could use the password > hashes to spoof a login. IMHO that's not a very convincing argument.
It's not a very convincing argument, but it's not the argument one would make against Digest. Digest requires storing a password, not a password hash. That's pretty bad. And all of John's points apply as well. When the WG finishes this document, the security ADs are going to look for 'mandatory-to-implement' security features. That's why we added a bunch of specifics to the XML Security section in the format document. Any client in the wild is going to have to implement Basic+TLS, so make it a requirement for clients. Who cares if some Intranet client that only does Kerberos isn't compliant? That approach also has the nice side-effect of ruling out sucky HTTP implementations. For example, J2ME/MIDP 1.0 clients wouldn't be compliant, because they don't ship with HTTPS. J2ME/MIDP 2.0 clients ship with HTTPS *and* sockets, so you can do PUT and DELETE on the socket. It's not too hard to write, and you can buy a MIDP 2.0 prepaid phone from Boost Mobile for $50, which includes $10 worth of minutes. That's the cheapest phone you can get in the US with no credit, so it's basically open to everyone with regular access to a computer. -- Robert Sayre "I would have written a shorter letter, but I did not have the time."
