Subject: Re: [TLS] Unifying tickets and sessions

From: Ryan Carboni <[email-masked]>
Date: Wed, 22 Oct 2014 09:44:18 -0700

From: "Richard Fussenegger, BSc"

> [*] Better would be 'from all ciphers in use' otherwise one ends up with
> a (insert ridiculous high value here) bit key while only using 128 bit
> ciphers in the configuration. Dropping the key if a new stronger
> configuration is loaded seems like a good idea to me at this point. I'm
> looking at this from a performance perspective and glimpsing over to the
> fact that the cryptography community agrees that 128 bit security will
> be enough for the next 10 to 20 years.[2] I really can't tell if this
> would be problematic from an implementation point of view. I think that
> single hosts won't have a problem here and I guess that it wouldn't be
> for clusters as well. The cluster configuration should be in sync but it
> could become a problem if one node has a differing configuration (for
> whatever reason). What opinion/insights do you have on this?

 Quantum computers are reaching 512-qubits now.
http://www.bbc.com/news/science-environment-27632140

Quantum cryptography would result in key-sizes effectively being halved,
and in 15 to 40 years a quantum computer could potentially be built by a
nationstate to enhance known cryptographic attacks and reduce keyspaces
substantially.

It's unlikely though that the NSA will devote quantum computing to breaking
the encryption of cat videos.

I suggest an advisory that for unauthenticated encryption, 128-bits are
used, and for authenticated encryption 256-bits or more are used. The only
issue is that browsers tell you the whole page is encrypted the same way
even though elements of the page use different sorts of encryption than the
body of the page.

---

From: Richard Fussenegger <[email-masked]>
Date: Wed, 22 Oct 2014 20:42:15 +0200

I noticed that you all try to dictate your believes of security to 
others, which is actually very interesting to read so please don't stop 
(there's **really** no sarcasm in this sentence, but maybe you should 
rename the thread then because this discussion is otherwise not going 
anywhere). But you just mentioned a *very* important thing: 128-bit are 
sufficient today for generic web applications.

Do we want a fully encrypted web? **Yes!**
When do we want it? **Now!**

The essence of my previous message (partly quoted below) was, that it is 
important to ensure within the RFC that a ticket that is storing the 
state of a SUPER-CRYPTO-9999 cipher isn't going to be encrypted with a 
GENERIC-CIPHER-128 key. This would simply downgrade the security of the 
whole agreed upon cipher. But on the other hand if an administrator 
decided that his web service is only delivering cat photos and that 
GENERIC-CRYPTO-128 is sufficient in terms of computing power for his 
server and for his clients, than it doesn't make sense to encrypt the 
ticket with SUPER-CRYPTO-9999.

Of course if the same administrator decided to support both, 
GENERIC-CRYPTO-128 and SUPER-CRYPTO-9999, then he'll require the 
SUPER-CRYPTO-9999 for all tickets. Viktor Dukhovni already mentioned 
that OpenSSL is actually supporting different key strengths, but for 
instance nginx isn't exposing this setting to administrators. But the 
RFC would most certainly compel them to do so in the future, which is a 
good thing. After all, the cat-photo-admin may continue to use fast and 
insecure ciphers (but still protecting clients and his services from 
script kiddies) and the nice whistleblower from our neighborhood may use 
the best available cipher available.

Rich Salz said that the RFC should stay silent on which crypto to use 
and I agree for above reasons and everything you guys brought up. 
Stating that crypto-X is sufficiently secure is like saying that god is 
for real; maybe it is true but science and research will eventually 
prove the opposite in the future. I stated that (the former not the 
latter, I'd never say such a thing) and made a mistake by doing so. But 
I hope that this message clarifies my intentions and also that some of 
you have an opinion about the actual proposal of mine.

Regards
Richard

On 10/22/2014 6:44 PM, Ryan Carboni wrote:
> Quantum cryptography would result in key-sizes effectively being 
> halved, and in 15 to 40 years a quantum computer could potentially be 
> built by a nationstate to enhance known cryptographic attacks and 
> reduce keyspaces substantially.
>
> It's unlikely though that the NSA will devote quantum computing to 
> breaking the encryption of cat videos.
>
> I suggest an advisory that for unauthenticated encryption, 128-bits 
> are used, and for authenticated encryption 256-bits or more are used. 
> The only issue is that browsers tell you the whole page is encrypted 
> the same way even though elements of the page use different sorts of 
> encryption than the body of the page.
>
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Ryan Carboni <[email-masked]>
Date: Wed, 22 Oct 2014 11:47:01 -0700

On Wed, Oct 22, 2014 at 11:42 AM, Richard Fussenegger <
[email-masked]> wrote:

> I noticed that you all try to dictate your believes of security to others
>
>
It's all speculative really.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 22 Oct 2014 19:09:37 +0000

On Wed, Oct 22, 2014 at 08:42:15PM +0200, Richard Fussenegger wrote:

> Viktor Dukhovni already mentioned that
> OpenSSL is actually supporting different key strengths, but for instance
> nginx isn't exposing this setting to administrators.

For the record OpenSSL makes it possible for applications to use
some other block cipher than aes-128-cbc, but this is not as easy
as it sounds.  The application needs to register appropriate
callbacks and take over key life-cycle management.  So simply using
some other cipher-suite is not a trivial exercise, rather only once
one is already managing key rotation via the callbacks, making the
cipher configurable is trivial:

The code for this is roughly:

    #define TLS_TICKET_NAMELEN      16      /* RFC 5077 ticket key name length */
    #define TLS_TICKET_IVLEN        16      /* RFC 5077 ticket IV length */
    #define TLS_TICKET_KEYLEN       32      /* AES-256-CBC key size */
    #define TLS_TICKET_MACLEN       32      /* RFC 5077 HMAC key size */

    typedef struct TLS_TICKET_KEY {
	unsigned char name[TLS_TICKET_NAMELEN];
	unsigned char bits[TLS_TICKET_KEYLEN];
	unsigned char hmac[TLS_TICKET_MACLEN];
	time_t  tout;
    } TLS_TICKET_KEY;

    #define NOENGINE				((ENGINE *) 0)
    #define TLS_TKT_NOKEYS	-1		/* No keys for encryption */
    #define TLS_TKT_STALE	0		/* No matching keys for decryption */
    #define TLS_TKT_ACCEPT	1		/* Ticket decryptable and re-usable */
    #define TLS_TKT_REISSUE	2		/* Ticket decryptable, not re-usable */

    static int ticket_cb(SSL *con, unsigned char name[], unsigned char iv[],
			      EVP_CIPHER_CTX * ctx, HMAC_CTX * hctx, int create)
    {
	static const EVP_MD *sha256;
	static const EVP_CIPHER *ciph;
	TLS_TICKET_KEY *key;
	int     timeout = ((int) SSL_CTX_get_timeout(SSL_get_SSL_CTX(con))) / 2;

	if ((!sha256 && (sha256 = EVP_sha256()) == 0)
	    || (!ciph && (ciph = EVP_get_cipherbyname(var_tls_tkt_cipher)) == 0)
	    || (key = tls_mgr_key(create ? 0 : name, timeout)) == 0
	    || (create && RAND_bytes(iv, TLS_TICKET_IVLEN) <= 0))
	    return (create ? TLS_TKT_NOKEYS : TLS_TKT_STALE);

	HMAC_Init_ex(hctx, key->hmac, TLS_TICKET_MACLEN, sha256, NOENGINE);

	if (create) {
	    EVP_EncryptInit_ex(ctx, ciph, NOENGINE, key->bits, iv);
	    memcpy((char *) name, (char *) key->name, TLS_TICKET_NAMELEN);
	} else {
	    EVP_DecryptInit_ex(ctx, ciph, NOENGINE, key->bits, iv);
	}
	return (TLS_TKT_ACCEPT);
    }

Plus additional supporting functions to fetch encryption/decryption
keys, subject to appopriate key rotation policies, (in the above
case tls_mgr_key() whose implementation is rather application
specific).

Perhaps I'll donate a variant of this code to OpenSSL, and then we
can ask users to just provide algorithm name, and either a key
lifetime for automatic in memory keys or callbacks to access
externally managed keys.

-- 
	Viktor.

---

From: Richard Fussenegger <[email-masked]>
Date: Wed, 22 Oct 2014 21:24:12 +0200

> lifetime for automatic in memory keys or callbacks to access
That would be great and exactly what the world needs. It's also the 
reason for my proposed changes that should be made during merge of 
RFC5077, so that OpenSSL will finally implement proper configurable 
rotation and configurable ticket ciphers. Applications like nginx 
wouldn't have to start implementing cryptographic stuff (which is a 
dangerous game), rather simply exposing the configuration options of 
OpenSSL which handles everything internally.

A nice to have above this would be some warning that is emitted if 
ciphers are configured that are actually stronger than the key used for 
the tickets. But that's already implementation specific stuff and has 
nothing to do with the RFC.

Richard

---

From: Nico Williams <[email-masked]>
Date: Wed, 22 Oct 2014 14:46:46 -0500

> cipher configurable is trivial:

Polite words fail me.  (Not a reference to your code, Viktor.)

This sort of thing should be expressible in a much simpler way: as a
one-liner or with local configuration/policy.

Nico
--

---

From: Hubert Kario <[email-masked]>
Date: Thu, 23 Oct 2014 15:48:47 +0200

> cipher configurable is trivial:
<snip>
> lifetime for automatic in memory keys or callbacks to access

I'd really like to see such code in OpenSSL. It would certainly help to make 
sure that the TLS 1.3 implementation meets the goals of TLS 1.3 charter.

-- 
Regards,
Hubert Kario