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

Re: WGLC issue for p7: "strength"

From: Mark Nottingham <mnot@mnot.net>
Date: Sat, 24 Mar 2012 09:55:28 +1100
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <C1A31FD1-9E2C-401F-80EB-06E2B06E524E@mnot.net>
To: Alexey Melnikov <alexey.melnikov@isode.com>

On 23/03/2012, at 11: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.

That's what I was thinking too.

Mark Nottingham   http://www.mnot.net/
Received on Friday, 23 March 2012 22:56:00 UTC

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