Re: [TLS] draft-badra-tls-password-ext-01

[Alfred Hönes <[e-mail]>]

Badra,
thanks for your response.

> Dear Alfred,
> 
> Thank you very much for this detailed and useful review.
> I will integrate all of these comments in the future version.
> However, two comments are in-line.

See my replies to these below, in-line as well.

>> ...
>>       o   Entering a username consisting of up to 128 printable Unicode
>>           characters.
>> |     o   Entering a passphrase of up to 64 octets in length as ASCII
>>                   ^^^    ^^^^^^^^^^
>> |         strings or in hexadecimal encoding.  The user interface MAY
>>                   ^^                               ^^^^
>>           accept other encodings if the algorithm for translating the
>>           encoding to a binary string is specified.
>>
>> BTW: Why only 64 octets?
> 
> Do you mean that 128 octets is more appropriate?

It would better balance the length of the username recommended.
ASCII text is said to have an average entropy of 2..3 bits per octet;
thus 128 octets here would also admit to easily roughly balance the
straightforward randomness requirements for protecting a 256-bit key.


>> Furthermore, I strongly recommend to set requirements to ensure
>> a minimum entropy of the passphrase.  A simple rule (suitable for
>> being checked easily by humans), might be:
>>
>>   The passphrase SHOULD at least contain 16 different octets, and at
>>   least 16 octets (say, x) in the passphrase must have neighbor octets
>>   not contained in the set {x-1, x, x+1} (mod 256).
>>
>> (The latter part aims at excluding long 'runs' of ascending/descending
>> sequences.)
> 
> It seems good for me, please give a reference to recommend that,
> if any.

Sorry, no direct reference.
That's my private recipe, developed after discussions with
customers in consulting, based on various articles in periodicals
on what makes bad passwords/passphrases (usually checked first by
cracking tools).  '16' has been selected (a bit arbitrary) as a
compromise between good randomness and memorability.
Theoretically, the best method would be to apply various strong
statistical tests to support the hypothesis of high entropy for
a proposed password/passphrase, but that would be quite expensive
to implement and have the significant drawback that, if the tests
fail, you could not present (to the person entering) it a simple
explanation of *why* the password/passphrase is being rejected.
Keep in mind that this simple test is intended as a minimum
requirement, which does not exclude checking against 'black lists'
of too frequently used and/or guessable strings, e.g. the combined
thesauri of widespread password cracking tools, and other policy
based tests.

For general considerations on required entropy in passwords /
passphrases, see BCP 106 (RFC 4086) and FIPS 112.

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+

_______________________________________________
TLS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tls