IETF Logo Mail Archive

Re: [saag] openconnect (ssl) vpn protocol

Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com> Mon, 17 October 2016 20:48 UTC

Return-Path: <n.mavrogiannopoulos@gmail.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 65E531299A6 for <saag@ietfa.amsl.com>; Mon, 17 Oct 2016 13:48:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level:
X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 fnK-JdhGpkYW for <saag@ietfa.amsl.com>; Mon, 17 Oct 2016 13:48:20 -0700 (PDT)
Received: from mail-qt0-f174.google.com (mail-qt0-f174.google.com [209.85.216.174]) (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 DB7FB129992 for <saag@ietf.org>; Mon, 17 Oct 2016 13:48:19 -0700 (PDT)
Received: by mail-qt0-f174.google.com with SMTP id m5so134139029qtb.3 for <saag@ietf.org>; Mon, 17 Oct 2016 13:48:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uNHUebR2zeNw2gKp7Mh0Zh/qkJ5tRg7iWGkYyC2ttTM=; b=t6Gl/4Y7Oa1JVrDKqUpW1FxmPHfnL+CpKCVlrMVK+qdXqJFONX2mYKIlRtLLulo6k5 egPobWKa5quegufH/xzRY0v6ZbBLH9773RELSAYRzA+JJBkGWJOxgP6SyQqLnla2ccFi CmVRaEflcnvh4t2ERY3D4t6MDDFhj2+AmxZ7DWg/+IASZxTRql6dH7s0bM/Nm+VDD5XA sQGDynNFUZZbpbZdnykIqJVV3cZcpcInrWSTq7I6u5UPmqb9pdNIdlwAPNCPCF7Wqofj eQur9RErDBjAHD7P2QIAwtoiHMDxqPTtFho2vSyBfQX4c5jX7RvIBFJqYoMDOXDRgl79 zJog==
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=uNHUebR2zeNw2gKp7Mh0Zh/qkJ5tRg7iWGkYyC2ttTM=; b=La2VQ5d3GAxCfzqwyKxRV/QLvGawod2w9ohmoO+u0npuDQN6HeRGtlPul3gGxQeP1B bh0oGrcR/0oUsNBKuyZj/5znKNix/70RcuvZwpQ2jkXSHwvwOqOTRQmIozk8FJaThlTY ER1Mpq6VDAgOaTr4Wlf/zAtr8CBtk4lorKcK2jqZgqx/kY8/g0LZAK0PF90bA2jR9cN0 fE2Yv4n+a4GWC92BEf6QqNmv1oCD15/sH4TxzjjFWrA0CC8gfMAMe7/sv/tHwCm0Aj02 qbw+gC9v4ynB6nOQTd2BMp65dSPg/XAdxXYCMomyfHbw9gOyqm3Mg+p60NnZx1Yo1iAD FWig==
X-Gm-Message-State: AA6/9Rlzw7kGWvu6Xj2tmLgB8Wb6mOS2Wb/n6U6El7Rilr7O4PRkUyttbm6tcQNFEW8R+z8o6Q8g2AYEDEIlZA==
X-Received: by 10.200.50.215 with SMTP id a23mr27352655qtb.79.1476737238968; Mon, 17 Oct 2016 13:47:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.169.91 with HTTP; Mon, 17 Oct 2016 13:46:38 -0700 (PDT)
In-Reply-To: <CABcZeBMX1-Msp67J3TRxOM69wtMpsPB3DLy0cQaRWdPxuo7_=Q@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>
From: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Date: Mon, 17 Oct 2016 22:46:38 +0200
Message-ID: <CAJU7zaLmX+o_iuLoPOGYXRRrnB6927iyUX8f3kYA-fsnnzcg-g@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/Ht_1_VqUHjhljPFX0gUnMMaaj9U>
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: Mon, 17 Oct 2016 20:48:21 -0000

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 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). 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