Re: [TLS] Universal PSKs

Jonathan Hoyland <jonathan.hoyland@gmail.com> Mon, 18 June 2018 13:31 UTC

Return-Path: <jonathan.hoyland@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B50130F2C for <tls@ietfa.amsl.com>; Mon, 18 Jun 2018 06:31:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 pFYPBk6BTaPH for <tls@ietfa.amsl.com>; Mon, 18 Jun 2018 06:31:12 -0700 (PDT)
Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (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 8C9FE130EC6 for <tls@ietf.org>; Mon, 18 Jun 2018 06:31:08 -0700 (PDT)
Received: by mail-vk0-x229.google.com with SMTP id o138-v6so9522834vkd.3 for <tls@ietf.org>; Mon, 18 Jun 2018 06:31:08 -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=7W+7XjD1KYNc3hFoYy+BUp9HBx81CxnfAoo4elQL8no=; b=lIl5AyIelaM35fmdIZ3aylS0docGZrQNflr29TDG8SfPpTMI0/s4gqzd6Ey94JjTVq AHOCLUIlA443udx6eiE0+QOaHqrcebefrRx8MZiZ/i39ZhJujjTWlJOi25PRcXo6QdkG 9cK9moBYUyuVSx51hmWRkxydYm5YMPQtryavO/FDYEA9wurBLKYPaAPldUpqkLB1JFyX x/yK8clTXdGAr/H1nK0kET7RITZlwn5fbr4p/hponIod2ZDJL3vgOFaX/zBRmcrnDq6J TeTzK2qfNypXlEYrtAr3w+kFfwOdOaz+ZpqTqwzsHk1ZeQeuxB9V4EBpWonAgKGzgqkr 4otA==
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=7W+7XjD1KYNc3hFoYy+BUp9HBx81CxnfAoo4elQL8no=; b=Eaq63Fe++5kAqClU3QspAjkcaGp91ErId6LbVWYvl9ACuzaEUTDDO1HsPbagmf4CXt axEuU9gLGgg4TxryC1DusyZHuraKdWNB31y/PoelfDOpSKyrpHOWJJ1EQWmHvI7F9xm2 W41s6bPOy8A5ppETEdsp7n4bjnW5Q9SNmg7oXYm+q4g0hlPJ8UimdCRJWTAdnk93Y9Ha 0pjCIYx43t+g7CF3nW+h3BYqjhl0pDCbL/3IUGxVP8kNmKDwzg8t8jGmzd/2glO5Q+s0 bLMVwUS16A8tivjiT2mRgF2TPQFMxczGI8YwrRxvIhXx0zRb30cVA99GefNJfzxY6aMJ k6BQ==
X-Gm-Message-State: APt69E0gs1jqoYpiyJhn2uJFd19D9zGIX/j7iTuioCpDsj7ApOH4T7TQ GtsKeit22f7ba1gvfaWb4J6d1b/ZIJ8e5YPsrccZXQ==
X-Google-Smtp-Source: ADUXVKLHlV7LovIX5g6rqccj5VRqULijpyOi7+GbSKt9vLxmeznZDyVaq5nZ3bJj5KZlbSEIBwD8saXK9rsl/4ONFic=
X-Received: by 2002:a1f:eb44:: with SMTP id j65-v6mr7005747vkh.14.1529328667418; Mon, 18 Jun 2018 06:31:07 -0700 (PDT)
MIME-Version: 1.0
References: <CAF8qwaB3GH8WbXD=snEwjA==Jx02gtWejyNTXXO6nVW0Cp1YHA@mail.gmail.com> <2132206.KQKFhKinhY@pintsize.usersys.redhat.com> <7BE4BC91-5324-42A6-8AB7-084439ED9527@akamai.com> <4207179.CySPfdG7iZ@pintsize.usersys.redhat.com> <CACykbs0w_N=ZeVPbnamSFKCOP0K9f7Ssn1gObwM5hmSpJPo-Wg@mail.gmail.com> <f85a88279d53880dd2ece06399bbefc6c152fd0b.camel@redhat.com>
In-Reply-To: <f85a88279d53880dd2ece06399bbefc6c152fd0b.camel@redhat.com>
From: Jonathan Hoyland <jonathan.hoyland@gmail.com>
Date: Mon, 18 Jun 2018 15:30:55 +0200
Message-ID: <CACykbs2oERJsFbNQOF4wT6y3Thfp_cNo3CX9HCMh=sGu0WCh5g@mail.gmail.com>
To: Nikos Mavrogiannopoulos <nmav@redhat.com>
Cc: Hubert Kario <hkario@redhat.com>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f76544056eea93c8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/hgZwZ2Kkek--TXi6yW4UzyGDrG8>
Subject: Re: [TLS] Universal PSKs
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Jun 2018 13:31:16 -0000

Given that channel bindings are generally the output of a hash transcript
there seems to be minimal risk of PSK enumeration.
If I send a PSK that the server recognises, alongside one it does not,
would a server sometimes pretend to accept the PSK it does not recognise to
avoid enumeration attacks?
That behaviour would seem strange to me.

If it's only the behaviour when all PSKs are unrecognised then this
shouldn't be an issue if the unmodified PSK is sent as a less secure
fallback option.
If all PSKs including the unmodified one are unrecognised then negotiation
failure is the correct response.

On the other hand, I have no objection in principle to an extension.

Regards,

Jonathan






On Mon, 18 Jun 2018 at 14:18 Nikos Mavrogiannopoulos <nmav@redhat.com>;
wrote:

> On Mon, 2018-06-18 at 13:56 +0200, Jonathan Hoyland wrote:
> > The issue with the current draft is that it leaves a single PSK with
> > two potential interpretations.
> > If the draft also changed the PSK identity value then each PSK would
> > have a single interpretation.
> > If the draft changes the identity then it can also change the PSK key
> > without having to change the manner in which the binder is computed.
> > In that case universal PSKs and regular PSKs do not need to be
> > distinguished, because they are both validated in the same way.
> >
> > A server unaware of universal PSKs would simply see an unrecognised
> > PSK identity.
> > If both the unmodified and the modified PSKs are sent, then it can
> > simply select the unmodified version, ignoring the other.
> > A server that recognises both values can choose which to use.
> >
> > If the modified PSK identity was a channel binding, then the modified
> > version would have stronger security properties, and thus presumably
> > would be preferable.
> > In this case the hash function used for the binder remains
> > selectable.
> >
> > Would that resolve your issue?
>
> That may not be sufficient. A server which sees an unrecognized PSK may
> chose to pretend it recognized it to avoid user enumeration attacks
> similarly to TLS1.2 (optional) behavior. Hence a modified username
> would cause negotiation  failure with such a server.
>
> A new extension seems to be necessary to eliminate any interoperability
> issues with servers that will not follow the universal psk draft.
>
> regards,
> Nikos
>
>