Subject: Re: [saag] openconnect (ssl) vpn protocol

From: Eric Rescorla <[email-masked]>
Date: Sun, 16 Oct 2016 18:34:42 -0700

On Fri, Sep 23, 2016 at 3:04 AM, David Woodhouse <[email-masked]>
wrote:

> On Fri, 2016-09-23 at 11:57 +0200, Nikos Mavrogiannopoulos wrote:
> > Hi,
> >  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.

-Ekr

>
> --
> dwmw2
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>
>

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 17 Oct 2016 22:46:38 +0200

On Mon, Oct 17, 2016 at 3:34 AM, Eric Rescorla <[email-masked]> wrote:
> 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,

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

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 18 Oct 2016 09:54:43 -0400

On Mon, Oct 17, 2016 at 4:46 PM, Nikos Mavrogiannopoulos <
[email-masked]> wrote:

> there
> applies
> 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
> 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