W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2012

Re: WGLC issue for p7: "strength"

From: Alexey Melnikov <alexey.melnikov@isode.com>
Date: Fri, 23 Mar 2012 13:27:32 +0100
Message-ID: <4F6C6C34.4020701@isode.com>
To: Mark Nottingham <mnot@mnot.net>
CC: HTTP Working Group <ietf-http-wg@w3.org>
On 21/03/2012 23:55, Mark Nottingham wrote:
> Now<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/349>.
>
>
> On 16/03/2012, at 7:53 PM, Mark Nottingham wrote:
>> 2.1 Challenge and Response - "The user agent MUST choose to use one of the challenges with the strongest auth-scheme it understands..." What does "strongest" mean here? Should we have an index of auth scheme strength as a registry field?
Definitely not. The measure of strength a) might change over the time 
(e.g. new vulnerabilities might be discovered) and b) might depend on 
client's capabilities and preferences (e.g. is use of smartcard-related 
authentication methods more secure than entering a password).

In SASL we tried to use SSF (Strength Security Factor) to describe the 
level of protection provided by an encryption mechanism associated with 
an authentication mechanism. (Before you stop me, I know this doesn't 
apply to HTTP as is, but there are some similarities.) SSF is a number 
that roughly correspond to the symmetric cipher key length in bits. So 
guess what, describing "strength" of SASL mechanisms based on just SSF 
doesn't work, because there are other security properties that might be 
considered more important to the client/user, such as support for mutual 
authentication, not being susceptible to passive dictionary attack, etc.
>> This may seem like nit-picking, but we place a MUST against it.
You have a point. I suggest adding an explanatory paragraph showing what 
might be considered the strongest, without being too prescriptive. And 
maybe the use of MUST is not appropriate here.
Received on Friday, 23 March 2012 16:53:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:57 GMT