Simple SSL/TLS - Some Questions

[Ian Grigg]

Jill Ramonsky wrote:

> First, the primary design goal is "simple to use".


This is the highest goal of all.  If it is not simple
to use, it misses out on a lot of opportunities.  And
missing out results in less crypto being deployed.

If you have to choose between simple-but-incomplete,
versus complex-but-complete, then choose the former
every time.  Later on, you can always upgrade - or
the programmer using the system can upgrade - to the
full needs if they have shown themselves the need
for the complete solution that you optimised away.

On these lines, I'd suggest something like:



1.  select one cipher suit only, and reject the
rest.  Select the strongest cipher suit, such as
large RSA keys / Rijndael / SHA-256 or somesuch,
so there are no discussions about security.

1.b,  means basically do TLS only.  Don't offer
any fallback.  If someone is using your protocol,
they can select it to talk to their own apps.
If someone has to talk to another app using TLS
or SSL, then they almost certainly have to talk
all suites, so they are more or less forced to
do OpenSSL already.  Hence, almost by definition,
you are forced into the market where poeple don't
want to negotiate cipher suites, they want the
channel product between their own apps up and
running with no fuss.

2.  Notwishtanding 1. above, leave the hooks in
to add another cipher suite.  You should really
only plan on one or two more.  One for embedded
purposes, for example, where you really push the
envelope of security for slower devices.  And
another because someone pays you to do it :-)

3.  Ditch Anon-DH as a separate suite.  Concentrate
on pure certificate comms.  Never deviate more than
briefly from the true flavour of the tools you are
working with.

4.  Ignore all complex certificate operations such
as CA work, etc.  If someone wants that order of
complexity, then they want OpenSSL, which includes
most of those tools.

5.  To meet the dilemma posed by 3, 4, generate
self-signed certificates on the fly.  Then, the
protocol should bootstrap up and get running
easily.  SSH model.  Anyone who wants more, can
replace the certs with alternately named and
signed certs, as created with more specialised
tools.  Or they can help you to write those
parts.

Good protocols divide into two parts, the second
part of which starts "trust this key totally."
Ignore the first part for now, being, how you
got the key.

6.  Pick a good X.509 / ASN1 tool.  Don't do
that part yourself.  See all the writings on how
hard this is to do.  If you want to join the
guild of people who've done an ASN1 tool and can
therefore call it "easy", do so, but tell your
family you won't be home for Christmas :-)

7.  Produce a complete working channel security
product before going for first release.  Nothing
slows down progress than a bunch of people trying
to help build something that they can't agree on.
Build it, then ask for help to round it out.

8.  What ever you do ... try and work on the code
that is most beneficial for other reasons.  Don't
plan on completing the project.  In the event
that you don't complete, make sure that what you
did do was worthwhile for other reasons!

9.  Take all expert advice, including the above,
with some skepticism.  You will have much more
intuition because you will be deep in the issues.



>  With that in mind, I believe I could do a safer
> implementation in C++ than I could in C.


Go with it, then.  Being right means you win,
being wrong is an opportunity to learn :-)


> ... /Of course/ one should be
> able to communicate with standard TLS implementations, otherwise the
> toolkit would be worthless.


Is that the case?  I wide variety of uses for
any protocol are application to same application.
The notion of client-to-server is an alternate,
but it's only an alternate.  It is not a given
that apps builders want to talk to other TLS libs.

TLS is there to be used, as is all other software
and standards.  It is at your option whether you
wish to join the group of people that can express
comms in *standard* TLS, talking heterogeneously.


> (1) THE LICENCE
> 
> I confess ignorance in matters concerning licensing. The basic rules
> which I want, and which I believe are appropriate are:
> (i) Anyone can use it, royalty free. Even commercial applications.
> (ii) Anyone can get the source code, and should be able to compile it to
> executable from this.
> (iii) Copyright notices must be distributed along with the toolkit.
> (iv) Anyone can modify the code (this is important for fixing bugs and
> adding new features) and redistribute the modified version. (Not sure
> what happens to the copyright notices if this happens though).

Sounds like BSD-2 clause or one of the equivalents.

The only question I wasn't quite sure of
was whether, if I take your code, and modify it,
can I distribute a binary only version, and keep
the source changes proprietary?

If so, that's BSD.  If not, you need some sort
of restriction like Mozilla (heading towards GPL).

My own philosophy has always been that crypto has
enough barriers on it already, so it should not
add any more personality quirks than necessary,
hence preference for BSD two clause.  Mind you,
such a statement is a personality quirk, so you
be your own judge.

(Also, bear in mind that you - as owner of your
code - have the choice of issuing it under many
licences.  There is nothing technically wrong
with you issuing it under PD, BSD, Mozilla, GPL.
It might make things confusing for your user
base, but you can do it.  It's your code (as
long as it *was* your code :-)  The corollary to
this is that you don't need to decide up front,
it can change as time goes on, at the cost of
some confusion.)



> (2) THE NAME

> Anyway, all suggestions welcome.


I guess you disposed of SSL-easy.  J-TLS?
Jill-T might work if you are brave, and like
strong cola :)  "Jilt" has a ring to it.

Names are really hard.  I'd defer that one until
it pops out.

> Pretty Good TLS/SSL...


I think I recall the PGP Inc company having
trademarked "Pretty Good".

Q:  Does your employer have any say or comment
on this project?  Might be wise to clear up the
posture, and either get it in writing, or make
the repository public from the git-go.  Many an
open source project has foundered when the boss
discovered that it works...


> (3) MULTIPLY SIGNED CERTIFICATES
> 
> A technical question now. (I did look at RFC2246 before asking this, but
> didn't find the answer there). In GPG / PGP, one can have multiply
> signed certificates. It's not called a "certificate" in GPG, it's called
> a signed key, but the priniciple is the same. Alice can get her key
> signed by both Carol and Dave, which has the intended meaning that both
> Carol and Dave vouch for the authenticity of Alice's key. Thus, if Bob
> wishes to send to Alice, he can do so provided he trusts /either/ Carol
> /or/ Dave.
> 
> Can you do this with X.509 certificates? I know it would be hideously
> unusual (not to mention expensive) to get a single certificate signed by
> both Verisign and Thwarte, but can it be done? Is it possible? Is it
> allowed?


I don't believe it is possible to multiply-sign
x.509 certs.  This is one of the reasons that
PKIs based on x.509 have a miserable record, as
the absence of any web of trust support and the
promoting of a hierarchical trust model goes
against most business and individual practices.

That said, having chosen TLs, you've chosen
x.509 certs (with some caveats).  This is the
reason why concentrating on self-signed certs
is such a clean idea, it neatly avoids the
issues of trust models, be they broken or not.

OT3H, I suppose you could do TLS-sans certs,
which would make for an interesting project,
not to mention a lot of time spent justifying
your choices :-)

But, what's the point to the question?  I'm
not quite sure how this relates to the essential
question of implementing TLS?


iang

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com