RE: Binary packet protocol rethink

Simon Tatham <anakin@pobox.com> Mon, 30 November 2015 09:11 UTC

Return-Path: <bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org>
X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com
Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F57C1B2D64 for <ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com>; Mon, 30 Nov 2015 01:11:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.485
X-Spam-Level:
X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.585] 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 gMuEa3DjNwVA for <ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com>; Mon, 30 Nov 2015 01:11:55 -0800 (PST)
Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (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 0629E1B2D62 for <secsh-tyoxbijeg7-archive@lists.ietf.org>; Mon, 30 Nov 2015 01:11:55 -0800 (PST)
Received: by mail.netbsd.org (Postfix, from userid 605) id 482C514A3DD; Mon, 30 Nov 2015 09:11:51 +0000 (UTC)
Delivered-To: ietf-ssh@netbsd.org
Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id B500814A3D6 for <ietf-ssh@netbsd.org>; Mon, 30 Nov 2015 09:11:47 +0000 (UTC)
X-Virus-Scanned: amavisd-new at NetBSD.org
Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 0UfdK4QPOJJo for <ietf-ssh@netbsd.org>; Mon, 30 Nov 2015 09:11:46 +0000 (UTC)
Received: from atreus.tartarus.org (atreus.tartarus.org [80.252.125.10]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id A210E14A3DB for <ietf-ssh@netbsd.org>; Mon, 30 Nov 2015 09:11:45 +0000 (UTC)
Received: from simon by atreus.tartarus.org with local (Exim 4.69) (envelope-from <simon@atreus.tartarus.org>) id 1a3KUL-000260-7F; Mon, 30 Nov 2015 09:11:13 +0000
Content-Type: text/plain; charset="UTF-8"
From: Simon Tatham <anakin@pobox.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Cc: Niels Möller <nisse@lysator.liu.se>, Damien Miller <djm@mindrot.org>, "\"Simon Josefsson\"" <simon@josefsson.org>, "ietf-ssh@netbsd.org" <ietf-ssh@netbsd.org>
Subject: RE: Binary packet protocol rethink
In-reply-to: <9A043F3CF02CD34C8E74AC1594475C73F4B9321A@uxcn10-5.UoA.auckland.ac.nz>
References: <87egfdxebo.fsf@latte.josefsson.org> <nny4dksr3i.fsf@armitage.lysator.liu.se> <1448554180-sup-7145@atreus.tartarus.org> <9A043F3CF02CD34C8E74AC1594475C73F4B857C7@uxcn10-5.UoA.auckland.ac.nz> <alpine.BSO.2.20.1511292228450.12629@natsu.mindrot.org> <9A043F3CF02CD34C8E74AC1594475C73F4B92EF0@uxcn10-5.UoA.auckland.ac.nz> <nn37vnsyoi.fsf@armitage.lysator.liu.se> <9A043F3CF02CD34C8E74AC1594475C73F4B9321A@uxcn10-5.UoA.auckland.ac.nz>
Date: Mon, 30 Nov 2015 09:11:13 +0000
Message-Id: <1448874084-sup-4376@atreus.tartarus.org>
User-Agent: Sup/git
Content-Transfer-Encoding: 8bit
Sender: ietf-ssh-owner@NetBSD.org
List-Id: ietf-ssh.NetBSD.org
Precedence: list

Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
> Why? The length just tells you how much to decrypt in one block, what
> you put inside it is up to you. At a lower level, the TCP headers
> already give length information, and if you can deal with that then
> you can just as easily deal with plaintext lengths.

Exactly.

And, at the same time, it's precisely the encrypting of the 'how much to
decrypt' length field which gives rise to all the previous protocol
flaws: an attacker either guesses the true length by correlating to the
TCP headers, or probes it by means of the byte-at-a-time dribbling
attack, or actively corrupts the cipher block containing the length and
waits to see when the resulting MAC failure is reported, and all of
those attacks (unless carefully defended against) give rise to some kind
of data you can use to attack the underlying cipher, like a (plaintext,
ciphertext) pair, or a partial XOR of a plaintext block and the previous
block in the CBC stream, or whatever.

So it simplifies matters enormously if you just don't try: accept that
the enemy _will_ be able to know the lengths of your encrypted blocks.
Then you can send them in clear to avoid all of those subtle
implementation goofs in trying to hide them, and instead, dedicate your
effort to arranging that it _doesn't matter_ if the enemy knows those
lengths, by making sure that the encrypted block boundaries do not also
reveal the length or position of any actually important data, such as a
particular SSH_MSG_anything. Hence, my original suggestion of separating
the two conceptual halves of the current monolithic BPP.

But it's looking so far as if there's not enough interest to pursue it.
Ah well.

Cheers,
Simon

-- 
for k in [pow(x,37,0x1a1298d262b49c895d47f) for x in [0x50deb914257022de7fff,
0x213558f2215127d5a2d1, 0x90c99e86d08b91218630, 0x109f3d0cfbf640c0beee7,
0xc83e01379a5fbec5fdd1, 0x19d3d70a8d567e388600e, 0x534e2f6e8a4a33155123]]:
 print "".join([chr(32+3*((k>>x)&1))for x in range(79)]) # <anakin@pobox.com>