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

"Valery Smyslov" <smyslov.ietf@gmail.com> Tue, 12 December 2017 20:05 UTC

Return-Path: <smyslov.ietf@gmail.com>
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 EEB12126CE8 for <tcpinc@ietfa.amsl.com>; Tue, 12 Dec 2017 12:05:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.261
X-Spam-Level:
X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 D0E1zyYzzI_P for <tcpinc@ietfa.amsl.com>; Tue, 12 Dec 2017 12:05:43 -0800 (PST)
Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (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 21421126B7E for <tcpinc@ietf.org>; Tue, 12 Dec 2017 12:05:43 -0800 (PST)
Received: by mail-lf0-x230.google.com with SMTP id f20so81129lfe.3 for <tcpinc@ietf.org>; Tue, 12 Dec 2017 12:05:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-transfer-encoding:importance; bh=Y/pBx5bnX3/LucOuxJMGF94ybow9jRtuI9pP5WeE488=; b=dP6v7A77M+pyuN+Hd3azk+mgEIYOFsJ66GlGnwwoOTDkvuXZU9XaDHKIiYw7B6crV9 ScOKe0owMLuSoj0BsKVjkGccnIR5SYn8QUyQiqrPPCawCN2NL8A9X6jVbZIX/f6vHu26 nzFjvWOSemgnnbQ7zcoJTTUHa7cjvsY9qqR8YO+f9Ic2RrTwtex4wx/dt2BcNdP8ByNe /vogXSvtNAyeoZUOlNzmu45JXfEjTWfDBXC5k6Rix0v4L92+yR7rq1uMhLCnZDZov9WR 4axlwkXanJW+Mkxsi7uCKShJ9PG1O5of4dwxuT6+vQBXe0pzqZXr1uYR507oyAqz6BJS EWiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:from:to:cc:references:in-reply-to :subject:date:mime-version:content-transfer-encoding:importance; bh=Y/pBx5bnX3/LucOuxJMGF94ybow9jRtuI9pP5WeE488=; b=BxxAM57dbtoyn+EkcmZaMAyMm3ZSJsX5j2t3fWrxOizVp/SivW5tAI5fCFJZikYoh4 do3vpeTs/VSI/Z9G02/Dm55picxBndp7MxV0HQppgcWmQx7szs3eV0xYkuWK+r/fhMr4 PU7AqjGd5bP2p5owfo8woyLcQRdHm6VmrU6MZPRGWA8dVWplJ8VVnF89Y2xdqcTQ9Uj+ Mgw4trcJltXnByx2e1IXNh1MEXlMR4h+o+t8t+s2OJGYrwVH2D61yZrXbX/Ig1Y4WDuG GKqTVN/Nc4GDTNetE/PnTjF+IuTEq84APLoXupKMxb8gLTQgcevkQmUA31K7SWGs1mLZ LJDw==
X-Gm-Message-State: AKGB3mLyxglNhmM5RFSwmZGHBLJcNRKdFix0pqknk+2zNn8+oOi6253v EpOccXVfWodXroifRG7DY2Y=
X-Google-Smtp-Source: ACJfBovCiuAtpKye8mws6+55n36DQCUuqUMY4jHVY/KjAmdquqBXjTTENDm3j7K5MJ8gClUdDc7r3Q==
X-Received: by 10.25.214.10 with SMTP id n10mr19280lfg.49.1513109141469; Tue, 12 Dec 2017 12:05:41 -0800 (PST)
Received: from chichi (ppp83-237-171-154.pppoe.mtu-net.ru. [83.237.171.154]) by smtp.gmail.com with ESMTPSA id j20sm3364683lfk.63.2017.12.12.12.05.38 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 12 Dec 2017 12:05:40 -0800 (PST)
Message-ID: <B035098B65EA4F01A2BCB369750D765B@chichi>
From: Valery Smyslov <smyslov.ietf@gmail.com>
To: Tero Kivinen <kivinen@iki.fi>, Valery Smyslov <svanru@gmail.com>
Cc: '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>
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>
In-Reply-To: <23088.12114.962463.320939@fireball.acr.fi>
Date: Tue, 12 Dec 2017 23:05:35 +0300
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 16.4.3528.331
X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/lKNuc_YzrFPs8Ab1R2ZT4s0jTY0>
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: Tue, 12 Dec 2017 20:05:45 -0000

>> my point was: if VM systems are designed in such a way, that they can
>> force the inside software to reset existing cipher states in case of VM resumption
>> IN ALL cases, then we are on the safe side. Your examples below bring
>> me to a conclusion, that IN SOME (or even in most) cases these tricks work.
>> Still not sure they work always.
> 
> 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.

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.