Re: [TLS] What would make TLS cryptographically better for TLS 1.3

Robert Ransom <rransom.8774@gmail.com> Sat, 02 November 2013 21:51 UTC

Return-Path: <rransom.8774@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7C8C21E80E8 for <tls@ietfa.amsl.com>; Sat, 2 Nov 2013 14:51:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fkzl2UJyplzJ for <tls@ietfa.amsl.com>; Sat, 2 Nov 2013 14:51:19 -0700 (PDT)
Received: from mail-qe0-x22a.google.com (mail-qe0-x22a.google.com [IPv6:2607:f8b0:400d:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 1674521E80B7 for <tls@ietf.org>; Sat, 2 Nov 2013 14:51:18 -0700 (PDT)
Received: by mail-qe0-f42.google.com with SMTP id gc15so3363471qeb.15 for <tls@ietf.org>; Sat, 02 Nov 2013 14:51:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wkK1eyiH/lR3FVOCRC4t/02vOGjzslmpXGKYo4DZ0Uo=; b=d6a0HTltuMU/SS4Y+vlKpT92ILS7oTz5dnNe7DDNxlmgrbNIPWnacvs39q8XCgOWKa Ouju7nF/useCyDojdeApUJ6i65tliwiTLtfsaPq7jsIYmDHgBiZIuQIl7BmWsKf4azlO ApeIQLZwyRA6hq2+IzXttK7SJpppsWALeLb0QlG3Mx7CMz0aBzJopPSa++wvvRc4E6Z/ lZNQLAeXpmw9WG1AX2nldkXcWd0Dd/9gHUc6nufhmmCMMJUnqBqLtgljJqjsi5VwkQ0B iqL/bX3IVRULy9iDpLKJFz7cnr0+UlO4fWRUdgga9ov5xCiHR0gYF4AKZJ9MsWw5Tc4Q SI9w==
MIME-Version: 1.0
X-Received: by 10.49.95.135 with SMTP id dk7mr12647131qeb.3.1383429078396; Sat, 02 Nov 2013 14:51:18 -0700 (PDT)
Received: by 10.229.12.198 with HTTP; Sat, 2 Nov 2013 14:51:18 -0700 (PDT)
In-Reply-To: <20131102211441.GA11907@gmail.com>
References: <CACsn0cnS7LWo+AN1maw-KYGhWXY1BLNPNOjiL-Y3UU3zG-Je_Q@mail.gmail.com> <20131031230955.GB32733@gmail.com> <CABqy+sof-NtSmZwTNN-x9Ekppz4PYMu2Pr3KjaEUdT7Wzxe7mQ@mail.gmail.com> <4e1772ced74d9347c88a66b123f8878f.squirrel@www.trepanning.net> <20131101231342.GG32733@gmail.com> <7e7cd08953358f9e9344d0afdb2e37bf.squirrel@www.trepanning.net> <CABqy+sq=9ue=iNkUEzrddJLdYRdAWk5YRz43sR2DV2Xrv5CHBQ@mail.gmail.com> <e5081bc3784fe15976397ccf73eee71f.squirrel@www.trepanning.net> <CABqy+sq9pp3hVkDYhZ98AfkXAYcdt2j+fbrFSnCmLteGHYEETg@mail.gmail.com> <20131102211441.GA11907@gmail.com>
Date: Sat, 2 Nov 2013 14:51:18 -0700
Message-ID: <CABqy+spfmoEC4G1WRo2czitPcWTbDUBQpon57bUof0dvPeT4Wg@mail.gmail.com>
From: Robert Ransom <rransom.8774@gmail.com>
To: Nico Williams <nico@cryptonector.com>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 02 Nov 2013 21:51:19 -0000

On 11/2/13, Nico Williams <nico@cryptonector.com> wrote:
> On Fri, Nov 01, 2013 at 08:53:13PM -0700, Robert Ransom wrote:
>> Nico Williams proposed omitting all nonces from (EC)DHE handshakes and
>> shared secrets in a future version of TLS.  My objection to that
>> proposal was that servers need to ensure that *something* in the
>> handshake is fresh, and if that is not a nonce, they will need to
>> ensure that at least one of the DH keypairs is new.  I thought it was
>> obvious that the reason for that was to prevent an attacker from
>> replaying the client DH public key and causing the server to reuse a
>> session key.  (It was obvious to Nico.)
>
> If either party wants to reuse a DH key then all they have to do to make
> it safe is also send a counter for salting.  The counter would reveal
> some information, so it may have to look random -- like a nonce -- and
> anyways, the other party can't validate anything about that counter.
> BUT, a) it's optional (if you don't reuse DH keys, you don't reuse
> session keys), b) it's *small*, much smaller than 32 bytes.
>
> Large nonces and explicit random IVs form a great subliminal channel.
> Taking direct outputs from a Dual_EC DRBG-style RNG for 32 byte nonces
> in TLS handshake messages makes you vulnerable to attack via the RNG.
> While having tiny nonces (or no nonces if not reusing your DH key) and
> random-IV-free cipher modes makes such attacks much harder to mount
> because the total number of bits of subliminal channel becomes fixed and
> is way less than the number needed for that sort of attack.
>
> Clearly there's a trade-off here:
>
>  - no nonces -> no DH key reuse
>
>  - large nonces -> no constraints on DH key reuse
>
>  - small nonces -> limited number of DH key reuses
>
> And:
>
>  - large nonces facilitate some attacks via subliminal channels and RNG
>    attacks
>
>  - no nonces (and no explicit random IVs) -> no subliminal channels
>
>  - small nonces -> lower subliminal channel bandwidth
>
> There's no reason to pick one for all implementations.  And there's
> reason to avoid large nonces.

If your implementation is backdoored, you're screwed no matter what.
Avoiding nonces won't help you.


As for the nonce size tradeoff:

* no nonce: no DH keypair reuse, or a replay-detection cache
* 32-byte nonce: server can use a PRNG, or can use a keyed hash to
hide its key-use counter
* 16-byte nonce: server must disclose its key-use counter or use a
block cipher to hide it
* 8-byte nonce: server must disclose its key-use counter or use a
64-bit block cipher (e.g. 3DES or TEA) to hide it

32-byte nonces must be allowed.  There's no downside to using a
32-byte nonce field in all cases; the server can pad with zero bytes
(or PRNG output, or whatever it wants) if it uses AES to hide its
counter.


>> In any case, for the sake of security, performance, and simplicity,
>> ciphersuites should be able to rely on the handshake layer to not
>> generate the same session key twice.
>
> Then GCM and friends are out.  They fail catastrophically with key
> reuse.  But I think your concern is misplaced -- see above.

No.  The reason that ciphersuites should be able to rely on the
handshake layer to not generate the same session key twice is to
*allow* GCM and other stream-cipher-based constructions.


Robert Ransom