Re: [Curdle] SSH/QUIC draft

denis bider <denisbider.ietf@gmail.com> Wed, 05 August 2020 03:29 UTC

Return-Path: <denisbider.ietf@gmail.com>
X-Original-To: curdle@ietfa.amsl.com
Delivered-To: curdle@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6E633A07BE for <curdle@ietfa.amsl.com>; Tue, 4 Aug 2020 20:29:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 6vrmrhZkz3-c for <curdle@ietfa.amsl.com>; Tue, 4 Aug 2020 20:29:38 -0700 (PDT)
Received: from mail-ot1-x342.google.com (mail-ot1-x342.google.com [IPv6:2607:f8b0:4864:20::342]) (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 E6BC33A07B5 for <curdle@ietf.org>; Tue, 4 Aug 2020 20:29:37 -0700 (PDT)
Received: by mail-ot1-x342.google.com with SMTP id v21so24991199otj.9 for <curdle@ietf.org>; Tue, 04 Aug 2020 20:29:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ts9Q9OjDr/JRCv3ja2XgcEcKBahgOae2TXsJqTZ/YtU=; b=Fe88GNHlxdUsQQ6cBxNiuZ4skWbVcdOx497xdxj5PTgh9HhaGXPYkO4cwdZNhLGlTD ZZ8dUyZnhR66vR1QeFn4QaWvyLrOK5dNq3f+XiXAcznggd4YzykPh/EtqT12r5VqiYC5 uInPiW44up1UBKe/quESk8rxAJLs9gyLW84SGXiD7TUH06tq1lg2qQrvmzsdNkFj7E8Z SIX949z4dU+K+U0zy6kGlz6yntDRHsWTs9U63NzoDILR2oY0YYDSPJxXH2zfOz2brIuJ 1Y+yY+u8fNirFC0R+0ssWyuh4UOncqgheJwIZI10qhO4eahL7Dlm2jUOgUBY84T2nEFS GN0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ts9Q9OjDr/JRCv3ja2XgcEcKBahgOae2TXsJqTZ/YtU=; b=BR+LkMmyNQ4D/zBSjXSmGT9HR3JNofAF/vb6+BGZBlRi/Xxi1YJDkFkcZ5AVRnYV5X PrW2lGtZqKTbqq2wT33x397GKVcuGKD0OxrjSJymeYzdyegUmvwTS31FE0OtLHTZoC+p pSqxmiTFH8qpyQl9W2W4aO208uAk+/9cvSphZc5zpYwhd+xYATgU3HHv3+TnXoOQD1/U yMK4b8uXzY2TItwEazqeA9FGMrAcEwz8TFp9ifSYjJShfillehbrnVfQzphtC8mQvjAk 15prRnKee7FbLYn7uDNWKL0pX60kVZYZluKn1eTmlFfjK7D+HdirhJaAVbFk41Oy4WDC UJ7A==
X-Gm-Message-State: AOAM53078EVnq/asHJgnHp9v5c0j9o1a9L1u17TFRX74bmfzzR8rKW3i wCQoolelGaBaGmww/H27JGpdpbREKLGZfuCnK8g=
X-Google-Smtp-Source: ABdhPJyJ6s5bFIN2juIV1MpdTHaDvI1sNnMx2ZE0rwer2LmL81Cf4Gm2BD83M6KCqLKzbZR7Y2yWvQ2u0y16apsp3u8=
X-Received: by 2002:a9d:77cd:: with SMTP id w13mr971561otl.146.1596598177212; Tue, 04 Aug 2020 20:29:37 -0700 (PDT)
MIME-Version: 1.0
References: <CADPMZDDEYZ7aTv=NUY+4+BmMnN=JxFUHUwM7=SYq=EK5v_r1oA@mail.gmail.com> <20200711193524.GA239102@LK-Perkele-VII> <CADPMZDDz-_KDY1NbhakTkP3CKhCOTKGUzaQZHYA=nn+-8X7X2Q@mail.gmail.com> <20200804214038.GV92412@kduck.mit.edu>
In-Reply-To: <20200804214038.GV92412@kduck.mit.edu>
From: denis bider <denisbider.ietf@gmail.com>
Date: Tue, 4 Aug 2020 22:29:25 -0500
Message-ID: <CADPMZDDdB+NsL7WYigREjCz3_TVYeouRYLTf99mBVw+1Qv8CCQ@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: Ilari Liusvaara <ilariliusvaara@welho.com>, curdle <curdle@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000033aa6e05ac18fb12"
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/eiBKk0F9IUgAvXMCPo1iiBYQgHc>
Subject: Re: [Curdle] SSH/QUIC draft
X-BeenThere: curdle@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of potential new security area wg." <curdle.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/curdle>, <mailto:curdle-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/curdle/>
List-Post: <mailto:curdle@ietf.org>
List-Help: <mailto:curdle-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/curdle>, <mailto:curdle-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Aug 2020 03:29:40 -0000

Benjamin:

Security of SSH signatures, both client and server-side, hinges on the
security of the exchange hash H. The manner in which H is calculated is
specified independently by each class of SSH key exchange method, but it
generally follows the same concept in all cases.

For example, Diffie Hellman key exchange is defined here:

https://tools.ietf.org/html/rfc4253#section-8

Each version of DH key exchange specifies a hash function that's used with
it. This hash function is used to calculate H as a digest of the following:

string V_C, the client's identification string (CR and LF excluded)
string V_S, the server's identification string (CR and LF excluded)
string I_C, the payload of the client's SSH_MSG_KEXINIT
string I_S, the payload of the server's SSH_MSG_KEXINIT
string K_S, the host key
mpint  e, exchange value sent by the client
mpint  f, exchange value sent by the server
mpint  K, the shared secret

For straightforward, one-roundtrip key exchanges such as DH – and same for
ECC, which is similar – the SSH/QUIC proposal instead replaces the
calculation of H as a digest of the following:

string Unencrypted "obfs-payload" content of SSH_QUIC_INIT
string Unencrypted "obfs-payload" content of SSH_QUIC_REPLY, excluding the
entire field "server-kex-alg-data"
The fields of "server-kex-alg-data", excluding signature field
mpint  K

https://www.ietf.org/id/draft-bider-ssh-quic-05.html#figure-9

For a cross-protocol attack, you'd want to manipulate one of these formats
to be not necessarily valid, but practically tolerated, by some reasonable
implementation, as an encoding of the other. This is a priori impossible
for implementations that meet the requirements to insert random data that
exist both in SSH (the KEXINIT cookie field) and in SSH/QUIC (section 2.6 -
Random Elements). However, let's consider an implementation that does not
meet this requirement because of resource constraints, for example software
that is running on a clothing tag.

In this case, the formats (for encoding data to calculate H) will not
collide because in SSH, the encoded blob starts like this:

00 00 00 nn 'S' 'S' 'H' '-' ...

The "nn" is the length of the SSH version string, and "SSH-" is a required
prefix of the SSH version string that will appear here.

On the other hand, in SSH/QUIC, the encoded blob starts like this:

00 00 jj kk 01 ...

The byte at offset 4 will have value 1, which is the packet number for
SSH_QUIC_INIT.

As far as I know, no SSH implementation will interoperate with one whose
version string does not start with "SSH-", and no as per the SSH/QUIC spec,
no implementation should interoperate with one that uses a value other than
specified for the SSH_QUIC_INIT packet number. Therefore the encodings are
strictly distinct.

Each side also performs the encoding of the binary blob to calculate H
separately, i.e. the encoding is not done by one side and blindly accepted
by the other. Therefore, there is no way to generate an encoding for SSH
that would also be accepted by a reasonable implementation in SSH/QUIC, or
vice versa.

While this does hinge on possibly non-obvious properties of the content
that's being encoded, these properties are fundamental enough that I don't
expect that they would be missed. If someone has concerns though, it's easy
enough to add a few non-zero bytes to the start of the SSH/QUIC encoding of
the blob to calculate H. For example, if we insert:

byte[8] "SSH/QUIC"

... before the other fields, then the distinctness of the encodings will be
even more obvious.

I will update the draft to insert that. While not strictly necessary, it's
good hygiene.

denis


On Tue, Aug 4, 2020 at 4:40 PM Benjamin Kaduk <kaduk@mit.edu> wrote:

> On Sat, Jul 11, 2020 at 09:02:50PM -0500, denis bider wrote:
> > Ilari:
> >
> >
> > > I presume server authentication should be done using the TLS server
> > certificate.
> >
> > Server authentication needs to happen using existing SSH host keys with
> no
> > change for users. Users should be able to update to new SSH software
> > versions that support SSH/QUIC and everything should work out of the box
> > without the user noticing a difference. Server admins may need to open a
> > UDP port in the firewall, and that's it.
> [...]
> >
> > > For client authentication, one probably should use SSH-layer mechanisms
> >
> > For client authentication, we use the exact same mechanisms currently
> used
> > in SSH.  Anything less than "no change for the user" does not fly.
>
> I'd be interested in hearing what (if anything) Ilari has to say about the
> potential for cross-protocol attacks when reusing ssh host and client keys
> for this related-but-not-exactly-the-same protocol.  On the face of it it
> seems like something that "requires careful analysis" and quickly skimming
> draft-bider-ssh-quic didn't give me enough context to be able to say
> anything useful.
>
> -Ben
>