Re: Case-sensitive cipher names are a bad idea

[Jeffrey Walton]

On Sat, Aug 16, 2014 at 12:08 AM,   wrote:
>> ...
> Even today with Unicode character set families, the ability to provide
> a global case-independent mapping becomes a massive problem. There are
> a variety of latin-like alphabets and greek alphabets, and even
> IBM EBCDIC encodings that are much unlike the US-ASCII character set.
> Even more problematic are the cyrillic, hebrew, aramaic, asian, and
> african alphabets.  Do we need to accept transliteration to these
> various alphabetic schems?
>
> Traditionally, case-independence has been the conversion of US-ASCII
> and IBM EBCDIC encodings for named strings.  In documentation languages,
> the use of various Unicode tablular character sets are used.
>
> How much of this above work needs to be accomplished so that
> name case-independent and character code table independence needs
> to be accomplished.  Or should we just define a character encoding
> standard for the naming conventions and stick to the definitions?
I believe they are discussing strings like used in cipher suites (for
example, "RC4-MD5"). They are 8-bit clean.

For the upcoming hostname matching gear, IDNs must be A-label form
from RFC 6125, section 6.4.2.

Jeff
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Case-sensitive cipher names are a bad idea

[shathawa]

> Does ANYONE think that case-sensitive cipher names are good idea?
>
> Someone who types TLSV1:RC4-MD5 will find things working, but is likely to
> be surprised by how weakly-protected they are.
>
> /r$
>
> --
> Principal Security Engineer
> Akamai Technologies, Cambridge MA
> IM: rs...@jabber.me Twitter: RichSalz
>
>
---
Even today with Unicode character set families, the ability to provide
a global case-independent mapping becomes a massive problem. There are
a variety of latin-like alphabets and greek alphabets, and even
IBM EBCDIC encodings that are much unlike the US-ASCII character set.
Even more problematic are the cyrillic, hebrew, aramaic, asian, and
african alphabets.  Do we need to accept transliteration to these
various alphabetic schems?

Traditionally, case-independence has been the conversion of US-ASCII
and IBM EBCDIC encodings for named strings.  In documentation languages,
the use of various Unicode tablular character sets are used.

How much of this above work needs to be accomplished so that
name case-independent and character code table independence needs
to be accomplished.  Or should we just define a character encoding
standard for the naming conventions and stick to the definitions?

Sincerely,
Steven J. Hathaway


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Case-sensitive cipher names are a bad idea

[Salz, Rich]

> Well, one problem is that "strcasecmp" is not in the Standard C Library, and 
> in
> fact is illegal, because external identifiers beginning with "str" are 
> reserved to
> the implementation.

Openssl already handles that, thanks.

> That said, I agree that case-insensitive comparison would be a good idea
> here.

Great.

--  
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: rs...@jabber.me Twitter: RichSalz
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Case-sensitive cipher names are a bad idea

[Michael Wojcik]

Well, one problem is that "strcasecmp" is not in the Standard C Library, and in 
fact is illegal, because external identifiers beginning with "str" are reserved 
to the implementation.

There is no standard case-insensitive string-comparison function in C. You have 
to write your own.

Here's one:

#include 
int cmpstri(const char *s1, const char *s2)
{
const unsigned char *us1 = (const unsigned char *)s1, *us2 = (const 
unsigned char *)s2;

/***
Handle null inputs. This function treats null strings as equal to one 
another
and less than non-null strings. Some applications might prefer different
semantics (e.g. treating null strings as empty strings).
***/
if (!s1 && !s2) return 0;
else if (!s1) return -1;
else if (!s2) return 1;

/***
Compare strings. Use unsigned char because tolower is not guaranteed 
with signed
input, and plain char may be signed (implemenation-dependent). ISO 
9899-1990 7.3.
***/
while (*us1 || *us2)
{
unsigned char l1 = tolower(*us1), l2 = tolower(*us2);
if (l1 < l2) return -1;
if (l2 > l1) return 1;
us1++, us2++;
}

return 0;
}

(Untested, but copied with some modifications from an existing implementation.)

That said, I agree that case-insensitive comparison would be a good idea here.

-- 
Michael Wojcik
Technology Specialist, Micro Focus



> -Original Message-
> From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
> us...@openssl.org] On Behalf Of Salz, Rich
> Sent: Friday, 15 August, 2014 14:36
> To: openssl-users@openssl.org
> Subject: RE: Case-sensitive cipher names are a bad idea
> 
> > The case makes some things more clear:
> 
> I never said it didn't.
> 
> > There are lots of other ways to typo the input string.
> 
> Yup, but saying TLSV1 won't work while TLSv1 does work is silly.
> 
> > Perhaps there are currently no collisions, and case folding is likely safe,
> but I
> > don't really see much benefit from this.  I think that's the wrong problem
> to
> > invest time in.  Instead, things like the security level interface in
> "master",
> > (which still needs some polish) are more like the way to go.  The
> cipherlist
> > mini-language is much too subtle for most users.
> 
> While I tend to agree (my test: explain the difference between ! and -), I
> have seen people hurt by this particular problem.  I happen not to be
> thrilled with the security level interface, but that's me.  Many people will
> find it useful. It will not address the problems some of us have.
> 
> And as you point out, it's not done yet.
> 
> I'm talking a bugfix-level patch to turn strncmp() in ssl/ssl_ciph.c to
> strncasecmp.
> 
> Does anyone see a PROBLEM with this?
> 
>   /r$
> 
> --
> Principal Security Engineer
> Akamai Technologies, Cambridge MA
> IM: rs...@jabber.me Twitter: RichSalz
> __
> OpenSSL Project http://www.openssl.org
> User Support Mailing Listopenssl-users@openssl.org
> Automated List Manager   majord...@openssl.org


This message has been scanned for malware by Websense. www.websense.com
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Case-sensitive cipher names are a bad idea

[Salz, Rich]

> The case makes some things more clear:

I never said it didn't.

> There are lots of other ways to typo the input string. 

Yup, but saying TLSV1 won't work while TLSv1 does work is silly.

> Perhaps there are currently no collisions, and case folding is likely safe, 
> but I
> don't really see much benefit from this.  I think that's the wrong problem to
> invest time in.  Instead, things like the security level interface in 
> "master",
> (which still needs some polish) are more like the way to go.  The cipherlist
> mini-language is much too subtle for most users.

While I tend to agree (my test: explain the difference between ! and -), I have 
seen people hurt by this particular problem.  I happen not to be thrilled with 
the security level interface, but that's me.  Many people will find it useful. 
It will not address the problems some of us have.

And as you point out, it's not done yet.

I'm talking a bugfix-level patch to turn strncmp() in ssl/ssl_ciph.c to 
strncasecmp.

Does anyone see a PROBLEM with this?

/r$

--  
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: rs...@jabber.me Twitter: RichSalz
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Case-sensitive cipher names are a bad idea

[Viktor Dukhovni]

On Fri, Aug 15, 2014 at 11:43:51AM -0400, Salz, Rich wrote:

> Does ANYONE think that case-sensitive cipher names are good idea?
> 
> Someone who types TLSV1:RC4-MD5 will find things working, but is
> likely to be surprised by how weakly-protected they are.

The case makes some things more clear:

aRSA, kDHE, eNULL 

There are lots of other ways to typo the input string.  To protect
users from typos, raw cipherlist strings should not be exposed by
applications as the primary user/administrator interface for cipher
selection.

Perhaps there are currently no collisions, and case folding is
likely safe, but I don't really see much benefit from this.  I
think that's the wrong problem to invest time in.  Instead, things
like the security level interface in "master", (which still needs
some polish) are more like the way to go.  The cipherlist mini-language
is much too subtle for most users.

-- 
Viktor.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Case-sensitive cipher names are a bad idea

[Walter H.]

Hello

On 15.08.2014 17:43, Salz, Rich wrote:


Does ANYONE think that case-sensitive cipher names are good idea?

this is a bad idea; or can you explain the difference between   
tlsv1:rc4-md5 and TLSV1:RC4-MD5?


Someone who types TLSV1:RC4-MD5 will find things working, but is 
likely to be surprised by how weakly-protected they are.




the case of names doesn't make the cipher stronger ;-)

Walter


smime.p7s
Description: S/MIME Cryptographic Signature