Re: [TLS] Consensus for AEAD IV
Michael StJohns <msj@nthpermutation.com> Mon, 27 April 2015 18:48 UTC
Return-Path: <msj@nthpermutation.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6AD1A90BF for <tls@ietfa.amsl.com>; Mon, 27 Apr 2015 11:48:11 -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=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVqf3bE3i4sM for <tls@ietfa.amsl.com>; Mon, 27 Apr 2015 11:48:09 -0700 (PDT)
Received: from mail-vn0-f42.google.com (mail-vn0-f42.google.com [209.85.216.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9755F1A6F17 for <tls@ietf.org>; Mon, 27 Apr 2015 11:48:09 -0700 (PDT)
Received: by vnbg7 with SMTP id g7so13141891vnb.11 for <tls@ietf.org>; Mon, 27 Apr 2015 11:48:08 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0keAlSQgDmSFOwUqETgkNq60JoHOtt0eXaUcBQEAK2g=; b=GP5Ct/tqdn1472qMyfawCiRITNOta/kBfuhmuz050K9h8BMrK30Ua5sFPIn6J9fvDJ 18hYvYhgVyNrYfMhD/j7UO4hk69Km3NmI+60D74spINlJ7l4Wqm3LQnGErulzOMkKG5O j4teG4fyL9xInZck5z5t+NM3nMwG3TbU+gZf0qRXLngB/2XV2IaPc+Z+28CYYjf+K5Pu CAzTl3mEqvsZI6s8rmOa80nUq7JCLCfqn3XeriHjzFFvj6dyUx+JYsrIJTJDs13jRHsn 2b793ZLlrTP996bO2HopwuQ+xGuyEB2dao5AXk46bCwSZ6W/pNamgZR06mVzlQ5wTSyM 8bUQ==
X-Gm-Message-State: ALoCoQkGbbXiRXhQTQN6mXoABtHPRPiXlzjXG8vPFE5OqLolrPZpVzuTHdLFT882CSodv0yncJcg
X-Received: by 10.52.228.130 with SMTP id si2mr11521820vdc.13.1430160488692; Mon, 27 Apr 2015 11:48:08 -0700 (PDT)
Received: from ?IPv6:2601:a:2a00:84:8d57:b850:1714:c34a? ([2601:a:2a00:84:8d57:b850:1714:c34a]) by mx.google.com with ESMTPSA id jk10sm27211314vdb.13.2015.04.27.11.48.07 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Apr 2015 11:48:08 -0700 (PDT)
Message-ID: <553E8468.6070205@nthpermutation.com>
Date: Mon, 27 Apr 2015 14:48:08 -0400
From: Michael StJohns <msj@nthpermutation.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Yoav Nir <ynir.ietf@gmail.com>
References: <CAOgPGoC14uhjrZAQvDHFQrJoyoVNELpNNd4+Hh==zwf9ipyY5g@mail.gmail.com> <CABkgnnU50pvH+LFsN3BL9LfvYhZOxmJV1JYzODeC=-JpZSh8Lw@mail.gmail.com> <CAOgPGoDNuhmnNpZ7ELCfBHS4rKuj+3j1+YiuxLkST+z1J+tOKQ@mail.gmail.com> <553C59B2.6050000@nthpermutation.com> <7E7D3069-2021-4691-AEA6-70DD1AB4476C@gmail.com> <553D27D0.7040209@nthpermutation.com> <20150426182025.GA3549@LK-Perkele-VII> <553D5898.3090902@nthpermutation.com> <3E5464E9-80BF-4D2E-A6C1-EF4E47A99268@gmail.com> <553D7397.9090000@nthpermutation.com> <25BAE048-8AF0-4F36-88FD-CFB4D577265E@gmail.com>
In-Reply-To: <25BAE048-8AF0-4F36-88FD-CFB4D577265E@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/-31UjDEN9Bi-3qBQow_w8uYKM6U>
Cc: tls@ietf.org
Subject: Re: [TLS] Consensus for AEAD IV
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 27 Apr 2015 18:48:11 -0000
On 4/27/2015 3:51 AM, Yoav Nir wrote: >>> The ChaCha20-Poly1305 for IPsec draft does the same thing, and in fact so does RFC 5288 (AES-GCM for TLS 1.2) >> > >> >Citing your own draft as proof of your own argument is a bit.... well… > That WG draft is in WGLC now, so it it’s doing something that is wrong, now would be a good time to say why. It’s also doing the exact same thing that IPsec has been doing with AEADs since 4106 and TLS since 5288. All of these combined a 64-bit explicit IV with a 32-bit salt that is derived as part of the keying materials (KEYMAT for IPsec, key_block for TLS) and never ever transmitted. See below: Basically getting your nonce/IV material from the same key stream production of your keys is problematic. You'd be better off specifying a different mechanism for producing such material, even if it differs from what is done throughout IPSEC. But that's a side show and rat hole we need not go down for TLS. > >> >In any event, I note that your IPSEC draft doesn't actually describe the ESP payload format, so without that, I'd make the assumption that the IV is included before the payload as is described in the IPSEC ESP document. >> > >>> >> >>> >>So no, that salt (and by extension, the proposed 96-bit value) need not be secret, but it’s never transmitted. >> >In which of the above? Maybe in the chacha20 draft... but not in the other two. >> > >> >And RFC5288 does it the wrong way - getting IV (session nonce) material from the same key stream as key material. That hopefully will be fixed with TLS1.3. It would have been much more preferable to use a zero session nonce than extract it from the key stream. > You are saying that this is wrong. Why? Because TLS1.2 had eliminated the IV production as part of the key expansion from the master secret phase. The AEAD suites added it back in. Without the IV production, it would have been somewhat easier to secure some of the TLS HSM functionality. And given that zero session nonces are completely acceptable and secure, that would have been a fine fixed choice instead of the one that was made. > >>> >> This also shows that there is good precedent for generating such a doesn’t-really-need-to-be-secret value from the key_block or KEYMAT. >> > >> >I'm pretty sure it doesn't. It just shows a continuous misunderstanding of the problems with doing it this way. > And those problems are…? > Let me try this one last time. I must just not be speaking the same language as the rest of you. The generic definition of a KDF both in TLS and IPSEC looks something like: Key_Stream = KDF (MasterSecret, Mixins, Length Of KeyStream) The above is deterministic - if you call the same KDF repeatedly with the same master secret, mixins and length, you will get the exact same key stream. The details of how you get that key stream differ between the two, but you still end up get a block of pseudo-random bytes of a certain length. E.g. pretend I've derived a keystream of 20 octets for IPSEC: 0x112233445566778899aabbccddeeff0011223344 In both TLS and IPSEC, the key stream is then broken down into parts that are assigned to secret keys, and unfortunately to values that are not secret (e.g. IV's nonces, etc). For example, a new KEYMAT is generated for each GCM key and broken down into the key and salt (per RFC4106 section 8.1). However, the split in the key stream is under user control. For both TLS and the IPSEC, I can call the appropriate function and assign any part of the key stream to secret or public status. While the IPSEC spec says to generate 20 octets for a 128 bit GCM key, and to assign 4 octets of that to the salt, if I instead assign 0 octets to a key and 20 octets to a salt, I've managed to move what I thought was secret into a public part. E.g. the first call gets me an AES key of 0x112233445566778899aabbccddeeff00 with a salt of 0x11223344; the second call by the attacker gets him only a salt of 0x112233445566778899aabbccddeeff0011223344 which coincidentally has the exact same value as the generated key stream. This is important because calling sequences for HSM versions of these KDFs have no way of knowing - FOR A SPECIFIC CALL - the *real* purpose of a desired key. The user may make a call to do the split along the 16/4 lines, but an attacker can use the same exact call with different key targets to get the 0/20 split and extract the derived AES key. Mixing the production of secret and not-secret data in the same call to a KDF without a way of cryptographically isolating the result means that you can never be sure of the secrecy of the derived keys in an HSM. There are ways to mitigate this: mandatory mixins of the length and types of material to be produced to the key stream production phase. That way, changes to the keystream to key assignments result in completely different keystream material and avoid this problem. An HSM can enforce the keystream to key assignments and even allow non-key material to be produced IF that is appropriately mixed in. All of this is generally not a big issue for software only implementations because all memory is outside of any assurance boundary and the treatment of any stream of bytes as public or secret are matters of convention rather than enforced policy. I'm going to stop talking on this set of threads now. My head hurts. Mike
- [TLS] Consensus for AEAD IV Joseph Salowey
- Re: [TLS] Consensus for AEAD IV Martin Thomson
- Re: [TLS] Consensus for AEAD IV Joseph Salowey
- Re: [TLS] Consensus for AEAD IV Martin Thomson
- Re: [TLS] Consensus for AEAD IV Russ Housley
- Re: [TLS] Consensus for AEAD IV Michael StJohns
- Re: [TLS] Consensus for AEAD IV Yoav Nir
- Re: [TLS] Consensus for AEAD IV Michael StJohns
- Re: [TLS] Consensus for AEAD IV Ilari Liusvaara
- Re: [TLS] Consensus for AEAD IV Brian Smith
- Re: [TLS] Consensus for AEAD IV Michael StJohns
- Re: [TLS] Consensus for AEAD IV Ilari Liusvaara
- Re: [TLS] Consensus for AEAD IV Michael StJohns
- Re: [TLS] Consensus for AEAD IV Michael StJohns
- Re: [TLS] Consensus for AEAD IV Yoav Nir
- Re: [TLS] Consensus for AEAD IV Michael StJohns
- Re: [TLS] Consensus for AEAD IV Yoav Nir
- Re: [TLS] Consensus for AEAD IV Michael StJohns
- Re: [TLS] Consensus for AEAD IV Yoav Nir
- Re: [TLS] Consensus for AEAD IV Eric Rescorla
- Re: [TLS] Consensus for AEAD IV Nikos Mavrogiannopoulos