Re: [TLS] Consensus for AEAD IV
Michael StJohns <msj@nthpermutation.com> Sun, 26 April 2015 23:24 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 0C89D1ACD39 for <tls@ietfa.amsl.com>; Sun, 26 Apr 2015 16:24: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 XBCdaRRaT2jY for <tls@ietfa.amsl.com>; Sun, 26 Apr 2015 16:24:09 -0700 (PDT)
Received: from mail-vn0-f45.google.com (mail-vn0-f45.google.com [209.85.216.45]) (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 7903F1ACD38 for <tls@ietf.org>; Sun, 26 Apr 2015 16:24:09 -0700 (PDT)
Received: by vnbf190 with SMTP id f190so9959193vnb.1 for <tls@ietf.org>; Sun, 26 Apr 2015 16:24: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=KHJNTuaeRWBDDvhz7meo+w4N+Xwi81xJioqSWTcqsHk=; b=S5xkcCWDe29l/+OgVhdSHUrvTGr68GPop/UTwd2Aop8YLG3ZGIDJHKmNPcaDUfw6Fk 7iQvs5GYgBTeBlWRXKZ2w7qV3l7OKsDB2w67+WQEshEesquSjDrxZ3t5pXwFUhOSAxh9 KOAUtNrqbuGQs77WSvvpmV6giipOhU06m+wO2FVbn+X5Y2ChWTc77SCD0ecflWshnQKb WmitHhb6XO7Xr8RQpAEoFbCifU3X9J6LPYe6QdOV8n8qDItRYxYg6qpNqmCEoacJXUbi k93kHQr+gVELcpFLaZbRmeBbmjVtf9q3IBeGcwh/7WioQJAEGJubDL3CwqQBvrgfeLgz pmYA==
X-Gm-Message-State: ALoCoQkwGgTUJto7gaIVHajQT42ty8DuLTQkt/c8TT4hnsx7pFLtXP7B9LqRH+01uxqKH7MbF42T
X-Received: by 10.52.143.233 with SMTP id sh9mr21544599vdb.26.1430090648514; Sun, 26 Apr 2015 16:24:08 -0700 (PDT)
Received: from ?IPv6:2601:a:2a00:84:cae:d6cf:19b5:13bc? ([2601:a:2a00:84:cae:d6cf:19b5:13bc]) by mx.google.com with ESMTPSA id mk16sm21237196vdb.12.2015.04.26.16.24.07 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Apr 2015 16:24:08 -0700 (PDT)
Message-ID: <553D7397.9090000@nthpermutation.com>
Date: Sun, 26 Apr 2015 19:24:07 -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>
In-Reply-To: <3E5464E9-80BF-4D2E-A6C1-EF4E47A99268@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/lp2TeP9R5NAX66a45CbyV1DTf8Y>
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: Sun, 26 Apr 2015 23:24:11 -0000
On 4/26/2015 6:26 PM, Yoav Nir wrote: > Both CCM and GCM use a concatenation of the explicit IV (which is obviously not secret and allowed to be predictable) with a salt that is derived from the keying material. This concatenation forms the nonce which is input to the AEAD. Which protocol are we talking about? CCM and GCM - as generic functions - use a per message Nonce. CCM defines a block formatting function (Appendix A of the Nist Document) that takes a nonce of 1-15 octets. David Mc Grew's RFC on AEAD functions APIs fixes the length of that nonce to 12 bytes because that's the most common length for GCM. That per message nonce (back to the generic again) can be created from the combination of a per-session nonce and a sequence number, randomly generated or derived from key material. HSMs generally implement the generic interfaces described in the base CCM and GCM documents, and David Mc Grew's RFC on AEAD is a subset of those possibilities and is therefor usable with the generic interfaces. > > RFC 4309 (CCM) says "The salt value need not be secret, but it MUST NOT be predictable prior to the beginning of the security association.” > RFC 4106 (GCM) says "The salt SHOULD be unpredictable (i.e., chosen at random) before it is selected, but need not be secret.” In IPSEC GCM, the IV is explicitly included in each packet (see section 3.1 of RFC4106) and hence is not secret in any way shape or form. In IPSEC CCM, the IV is also explicitly included in each packet - see section 3 and 3.1 of RFC 4309. Hence, also never secret in any way shape or form. > 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... 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. > 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. There are ways to mitigate this a bit - but they require ensuring complete cryptographic isolation from key generation and a method of non-secret but not disclosed information that can still be used with the generic interfaces. There was a good precedence for using RC4 and MD5 because they were fast and in wide use, but we've learned. Later, Mike > > Yoav > >> On Apr 27, 2015, at 12:28 AM, Michael StJohns <msj@nthpermutation.com> wrote: >> >> On 4/26/2015 2:20 PM, Ilari Liusvaara wrote: >>>> There is no reason to treat the 96 bit quantity as secret and no one else >>>>> does. >>> (To lesser extent, IPSEC, there the session nonce is 32 bits and secret). >>> >> This is directly from section 2.3 of the IPSec ESP RFC 4303 >> >> >>> With regard to ensuring the alignment of the (real) ciphertext in the >>> presence of an IV, note the following: >>> >>> o For some IV-based modes of operation, the receiver treats >>> the IV as the start of the ciphertext, feeding it into the >>> algorithm directly. In these modes, alignment of the start >>> of the (real) ciphertext is not an issue at the receiver. >>> >>> >>> o In some cases, the receiver reads the IV in separately from >>> the ciphertext. In these cases, the algorithm specification >>> MUST address how alignment of the (real) ciphertext is to be >>> achieved. >> And RFC4309 - CCM mode has this: >> >>> ESP Payload >>> >>> The ESP payload is composed of the IV followed by the ciphertext. >>> The payload field, as defined in [ESP], is structured as shown in >>> Figure 1. >>> >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Initialization Vector | >>> | (8 octets) | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | | >>> ~ Encrypted Payload (variable) ~ >>> | | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | | >>> ~ Authentication Data (variable) ~ >>> | | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> Again, newer modes may have done something else, but the above is strong indication that IVs were not generated as secrets as a general matter. >> >> Later, 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