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

Re: WGLC issue for p7: "strength"

From: Peter Saint-Andre <stpeter@stpeter.im>
Date: Tue, 27 Mar 2012 14:14:36 +0200
Message-ID: <4F71AF2C.6040803@stpeter.im>
To: Alexey Melnikov <alexey.melnikov@isode.com>
CC: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
On 3/23/12 1:27 PM, Alexey Melnikov wrote:
> 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 Tuesday, 27 March 2012 12:15:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:01 UTC