IETF Logo Mail Archive

Re: [tcpinc] Resumption safety (was "Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpcrypt-09: (with DISCUSS and COMMENT)")

Tero Kivinen <kivinen@iki.fi> Wed, 13 December 2017 00:13 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: tcpinc@ietfa.amsl.com
Delivered-To: tcpinc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A11D12711D for <tcpinc@ietfa.amsl.com>; Tue, 12 Dec 2017 16:13:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level:
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no
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 zthwOhvh1aRY for <tcpinc@ietfa.amsl.com>; Tue, 12 Dec 2017 16:13:57 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D286712704A for <tcpinc@ietf.org>; Tue, 12 Dec 2017 16:13:56 -0800 (PST)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id vBD0Dn8R017130 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 13 Dec 2017 02:13:49 +0200 (EET)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id vBD0DmqK025598; Wed, 13 Dec 2017 02:13:48 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <23088.28860.227581.172184@fireball.acr.fi>
Date: Wed, 13 Dec 2017 02:13:48 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: Valery Smyslov <smyslov.ietf@gmail.com>
Cc: Valery Smyslov <svanru@gmail.com>, 'Eric Rescorla' <ekr@rtfm.com>, 'Kyle Rose' <krose@krose.org>, "'Mirja Kuehlewind (IETF)'" <ietf@kuehlewind.net>, 'tcpinc' <tcpinc@ietf.org>, "'Black, David'" <David.Black@dell.com>
In-Reply-To: <B035098B65EA4F01A2BCB369750D765B@chichi>
References: <CAJU8_nUUHbmFcPA2obo6q3dLqL1MGE2iKen-0EQ82re=+gtTfw@mail.gmail.com> <CE03DB3D7B45C245BCA0D243277949362FD96B0D@MX307CL04.corp.emc.com> <23072.32691.892725.97892@fireball.acr.fi> <01bc01d36a71$45957db0$d0c07910$@gmail.com> <CABcZeBPN_XQc8np3CWi_-AtDUafW4ZPc8EnRje8yj57Rv-vxyw@mail.gmail.com> <B0FB25D40E23475C9259A4C204B327D2@chichi> <CE03DB3D7B45C245BCA0D243277949362FDD6E73@MX307CL04.corp.emc.com> <CAJU8_nW9fkn9E=NbKFZ3zy5uSY36WFqRcQpBYdyYuLwzAbqFHA@mail.gmail.com> <CAJU8_nX7NOSG8hkUYqG_GeqSyPzmhwsyA30Z0riqRmwK8SozpQ@mail.gmail.com> <073801d37315$90c89bd0$b259d370$@gmail.com> <23088.4472.814142.142233@fireball.acr.fi> <E7AF7C0A2811484F8C475C00F74FC97D@chichi> <23088.12114.962463.320939@fireball.acr.fi> <B035098B65EA4F01A2BCB369750D765B@chichi>
X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd)
X-Edit-Time: 4 min
X-Total-Time: 3 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/1C-mg077Vfjo61qHRwkh9R4C_vw>
Subject: Re: [tcpinc] Resumption safety (was "Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpcrypt-09: (with DISCUSS and COMMENT)")
X-BeenThere: tcpinc@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Working group mailing list for TCP Increased Security \(tcpinc\)" <tcpinc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpinc/>
List-Post: <mailto:tcpinc@ietf.org>
List-Help: <mailto:tcpinc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Dec 2017 00:13:59 -0000

Valery Smyslov writes:
> > Yep. They do not work always, but if we design tcpinc in same way than
> > TLS, i.e., resumption always guarantees that we have new keying
> > material, then solutions which work for TLS (i.e. forces TCP sessions
> > to be reset, and new TCP connections to be created) will work for
> > tcpinc too.
> 
> I agree that tcpinc resumption could (should?) have been designed better.
> No disagreement here.

Good. And this was the discussion point here, I think. The original
question was whether the resumption should have nonce or not, i.e.,
resumption safety.

> My point was more generic. If internal cipher state of any protocol
> using counter mode has a chance to survive VM resumption 
> and continue to work (even for a short time), then a counter re-use 
> (and thus a catastrophic lose of security) could happen.
> Nonce-misuse resistant modes (like GCM-SIV) would help in this case.

I agree on that, but I think it is outside the scope of this
discussion (subject line says "Resumption safety").
-- 
kivinen@iki.fi

v2.23.0 | Report a Bug | By Email