Simple SSL/TLS - Some Questions

[Eric Rescorla]

Jill Ramonsky <Jill.Ramonsky at aculab.com> writes:
> Now - SSL or TLS - this confuses me. From what I've read in Eric's
> book, SSL version 3.0 or below is called SSL, wheras SSL version 3.1
> or above is called TLS.
I wouldn't use quite that terminology. Noone talks about SSL version
3.1, but rather TLS 1.0. However, if we're just speaking about what's
in the version numbers in the wire protocol you're right.

> Have I misunderstood that? In any case, I note
> the bit in Eric's book (p73 in my edition) where it says "In general,
> it is expected that an implementation speaks all lesser versions"
> ... even if lesser versions become known to be insecure. I'm not sure
> I like this -
>
> and in any case, it goes against the design goal of "lightweight". If
> you want to implement only TLS (for example, in a closed private
> network where all parties are known to be using the same version of
> the same protocol), why should you have to lug around SSL as well? I
> suppose I /want/ the solution to be "allow the toolkit to generate
> either SSL-only, or TLS-only, or SSL+TLS" ... but what I'm not sure
> about is, is the "TLS-only" option forbidden by the standard?
No, but it's like this: 

There's no way to advertise that you speak "only TLS 1.0".
So, if, for instance, a client says "I speak TLS 1.0" then
the server is well within its rights to say "thanks, let's to
SSL 3.0". The only thing the client can do is break the connection.
This isn't a disaster since the alternative would be for the
server to break the connection when it discovered that the client
only spoke TLS and it only spoke SSL, but it's a bit inefficient.

> Now, this scenario is all very well for banks and big businesses, but
> I guess I want to do "SSL for the rest of us". You see, the above
> scenario contains a couple of assumptions. It assumes (1) that Bob
> does not already have Alice's key - otherwise why would she need to
> send it? It further assumes (2) that Bob /does/ have Carol's key, /and
> that he trusts Carol/. Okay, fine, but what if these assumptions
> aren't met? I mean, let's assume that Bob already has Alice's
> key. (Let's say for sake of argument that she gave it to him
> personally). Now this means we can save on bandwidth by not having to
> transmit Alice's cert ... but already there are two problems: (1)
> would it be a violation of the protocol to omit the cert?,
Yes.

> and (2)
> without the cert, we would need some /other/ kind of message with
> which to replace it - one which says, simply, "Hi, this is Alice, use
> the copy of my key which you already have". So already I have
> questions - how free am I to allow variations in the handshake?
Not at all. If you want to do this you will have to use the ADH
mode. The alternative is to write a new ciphersuite specification.


> THE CIPHER SUITE
> 
> The list on page 74 of Eric's book looks a little limiting to me - not
> merely because the list is too short, but also because it's very
> design is wrong (in lumping all of the encryption ciphers together
> into a single 16-bit value with no internal structure). What if Alice
> would like to use, say, some elliptic curve function as her asymmetric
> algorithm?, or CAST-5 as her symmetric algorithm?, or SHA-256 as her
> hash function?

This has been an enormously contentious issue. I advise you to tune
into the IPsec mailing list of about 6 months ago for all the
arguments for and against suites. There's no point in reprising
them here. That's just the way TLS is.


> We could maybe fix this up by adding more entries to
> the list, but it's a global list, so who has the authority to add
> entries to it?

You need to submit it to the TLS WG for approval. 

That said, I'm trying to figure out why you care about this. 
The defined algorithms are good enough for almost all purposes.


> I believe that Alice and Bob should be able to
> communicate with whatever ciphers they wish, and should not need the
> permission of any global authority to do this. Are there any values in
> the range (0x0000 to 0xFFFF) which are reserved for private use
> between consenting parties?
0xff* is all private.

See A.5 of RFC 2246. You have read the RFC, right?

> It is even possible for Alice and Bob to use a proprietry cipher. For
> example, what if the chosen encryption algorithm is "one-time-pad",
> using a block of bits communicated out of band (e.g. via so-called
> quantum cryptography, or that hard-drive alternative discussed in
> another thread). How can this be communicated in the CipherSuite
> field? I would like to believe there is a way of doing this ... but if
> not, I'd like to know that too, so I can find a neat way of extending
> the protocol to /make/ it possible.
There is an Extensions RFC. Can't remember the RFC number offhand.

> THE COMPRESSION METHOD
> 
> Exactly the same question. Alice and Bob are consenting adults, and
> they want to use the BZIP compression algorithm. I'm not going to tell
> them they can't. (I suspect though that the answer to the previous
> query will also answer this one).
There's a similar answer. Currently there is a draft on TLS compression.

> THE CERTIFICATE
> 
> Can Alice and Bob each create their own certificates? With (for
> example) Alice's key signed by Bob, and Bob's key signed by Alice, as
> is often done in GPG? Who counts as the "Issuer" in this case? How can
> Alice (or a piece of software working on Alice's behalf) construct an
> X.500 Distinguished Name to describe herself /and be absolutely sure
> that it is globally unique/? On page 12 of Eric's book it explains
> that a DN is a sequence of RDNs, each of which only needs to be
> locally unique, so the whole sequence becomes globally unique. That's
> all very well, but it's still a global namespace overall, so who
> controls it? Let me be clear that Alice and Bob have no intention to
> give even a single penny to Verisign or any other entity, just so that
> they can talk to each other in private.
TLS is basically agnostic on certificate validation and construction.
It references PKIX but in practice you can do whatever you want.

I'm a little puzzled by some of these questions:
(1) Don't you want to be able to communicate with standard TLS
    implementations? If so, the kind of stuff you seem to want
    to do will in often break that.
(2) I thought your goal was simplicity. All these options for exotic
    mechanisms will make things less simple. 

-Ekr

-- 
[Eric Rescorla                                   ekr at rtfm.com]
                http://www.rtfm.com/

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