IETF Logo Mail Archive

Re: [saag] openconnect (ssl) vpn protocol

Eric Rescorla <ekr@rtfm.com> Tue, 18 October 2016 13:55 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE2A12948C for <saag@ietfa.amsl.com>; Tue, 18 Oct 2016 06:55:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 qq39PT2x4Ypm for <saag@ietfa.amsl.com>; Tue, 18 Oct 2016 06:55:25 -0700 (PDT)
Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (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 7F1961294AB for <saag@ietf.org>; Tue, 18 Oct 2016 06:55:24 -0700 (PDT)
Received: by mail-yw0-x22c.google.com with SMTP id t192so139216926ywf.0 for <saag@ietf.org>; Tue, 18 Oct 2016 06:55:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7w6/FoN5BFoIu+9Pp4DqwxxjecAyw3j+3Cp9XcwSco4=; b=qgv4hKf9jv4cQzjhxS5dSXIMblA7bHp/iJLl7OchBJYtMHgjuaUdKz5M6JSX+Z2WQh Cz+095PJn1am2g+GS3vh0MgS42DUP4NE0/fIdwRRlkA0yjpdaMvNR0RHfQMuaV8omz4m nl3DZelyAhe58PIxiXiDkArKvs6ZZHMPclsxRlvdHpYyfltGaW+/WyMjOOCyPaB8TvrX t83i6qAEwiT2QHn+02GzgSYNlos2WmtPhOWPWuv0D3CN7zh+otj1DUNjbHQZKf5Sw2ZR hD920PfAmRvM2/O4sG6A8h276PRjp7IXqaFYOUVQtDUAlW3aSouOfj25i8AH4k78fKA4 LRBA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7w6/FoN5BFoIu+9Pp4DqwxxjecAyw3j+3Cp9XcwSco4=; b=XxvKzQDSazZZJGwvD40996MQWRZtTM6Ndfv8rVvOP2gSitaUwkktkYit9Scd7jQyHo ANUlM+w+LprChv7mNWd8r89K0dSGlux5Mdm2DBcG81xneOQZV7MuPW45Cd4iGphp45gn byoCEv5vLlSlxoVbTGZkMN95lajLw8xUpGSQa3jPlD7B6hEsnMKXf4jUDuU8qTBj11b1 dpF3XeEeeCFDVyPMhIL5q+MYP5K6C/PrN98P4Dbf33kiOTHu/QBGbIZUiamy4UVsODPi xnpITqGPGG2yqpH+sH2Ke50HOveju7nqpVg8KwNNDw38hF/zUz6ZO3YpccfDhI3APkgn 8NVQ==
X-Gm-Message-State: AA6/9Rn4VzTS8vAzPZeAdnjz+KBJQumcbtDKz/1cHgVU/YWbfJRMp4qiDwpNm313v7Q8HLbfDEyoNqLsJ/JynA==
X-Received: by 10.129.125.198 with SMTP id y189mr625146ywc.234.1476798923747; Tue, 18 Oct 2016 06:55:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.75.212 with HTTP; Tue, 18 Oct 2016 06:54:43 -0700 (PDT)
In-Reply-To: <CAJU7zaLmX+o_iuLoPOGYXRRrnB6927iyUX8f3kYA-fsnnzcg-g@mail.gmail.com>
References: <CAJU7za+Hb0uOTXOCzaO+eu+JW8EvP-+zwJTzV9FaYjVTbvCn-g@mail.gmail.com> <1474625071.45169.131.camel@infradead.org> <CABcZeBMX1-Msp67J3TRxOM69wtMpsPB3DLy0cQaRWdPxuo7_=Q@mail.gmail.com> <CAJU7zaLmX+o_iuLoPOGYXRRrnB6927iyUX8f3kYA-fsnnzcg-g@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 18 Oct 2016 09:54:43 -0400
Message-ID: <CABcZeBO=YFhPjzqLQ2DNc+0LYV-f4D6hw2GG-YzR8tkXpjXx+g@mail.gmail.com>
To: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Content-Type: multipart/alternative; boundary="001a114926a0418b5a053f240b3f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/z-3paakG6cikf07QV5bUUlQBG5k>
Cc: IETF SAAG <saag@ietf.org>
Subject: Re: [saag] openconnect (ssl) vpn protocol
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Oct 2016 13:55:27 -0000

On Mon, Oct 17, 2016 at 4:46 PM, Nikos Mavrogiannopoulos <
n.mavrogiannopoulos@gmail.com> wrote:

> On Mon, Oct 17, 2016 at 3:34 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> >> >  The last few weeks together with David Woodhouse have improved the
> >> > openconnect VPN protocol quite significantly and eliminated any legacy
> >> > constructs arising from the pre-DTLS era, and pre-TLS-PSK era. Even
> >> > though it still provides backwards compatibility with the cisco's
> >> > anyconnect protocol, it has been greatly simplified, making it one of
> >> > the simplest SSL VPN protocols I'm aware of. It is described at:
> >> > https://tools.ietf.org/html/draft-mavrogiannopoulos-openconnect-00
> >> > We would appreciate any feedback on the protocol and approach.
> >> Did I catch a suggestion that using PSK in (D)TLSv1.3 is going to
> >> require us to pre-agree a hash algorithm for the hello_finished?
> > Yes. The reason is that there's no guarantee that it's safe to derive
> using
> > different
> > hash-based KDFs from the same underlying key (which is not to say that
> there
> > is
> > an actual attack on concrete hash algorithms). Note: this issue also
> applies
> > to TLS 1.2,
> > it's just that we didn't have the benefit of having it pointed out by
> > cryptographers.
>
> Is there more information on that attack that you describe (pointers
> or the discussion behind it)?


As I said, it's not an attack, it's just not a property that is guaranteed
by KDFs.


As far as I understand, that can be
> summarized as use only ciphersuites with a fixed PRF on PSK rather
> than mixing them. That can also seen as an argument for TLS to have a
> unique PRF for the finished messages (at least for the plain PSK
> ciphersuites).


Well it's not just the finished messages, but any use of the PSK. Any way,
I don't think restricting it in TLS is the answer; implementations can
restrict
themselves to a single KDF if they want.

-Ekr



Otherwise managing and mapping PSKs to user interfaces
> becomes quite more complex. For the PSK usage of openconnect that is
> not issue as PSKs are uniquely generated per session.
>



>
> regards,
> Nikos
>

v2.23.0 | Report a Bug | By Email