Re: [TLS] draft-ietf-tls-tls13-21 posted

Eric Rescorla <ekr@rtfm.com> Thu, 06 July 2017 04:18 UTC

Return-Path: <ekr@rtfm.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 60A59129AF7 for <tls@ietfa.amsl.com>; Wed, 5 Jul 2017 21:18:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 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_NONE=-0.0001] 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 uNJfTRdgjAId for <tls@ietfa.amsl.com>; Wed, 5 Jul 2017 21:18:44 -0700 (PDT)
Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::22b]) (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 A38A2129ADC for <tls@ietf.org>; Wed, 5 Jul 2017 21:18:44 -0700 (PDT)
Received: by mail-yb0-x22b.google.com with SMTP id 84so2433195ybe.0 for <tls@ietf.org>; Wed, 05 Jul 2017 21:18:44 -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=2lCa/xNen1Wkq2+0WBQYPFJ5N4YbUrrH4eHiahJKOmc=; b=0e9d8TWVNrcyXaRSSTgtNzJX0QxDlobIJGVQZ7M6yluWjHYk9VZqDxEeAo77ky96DO aXWVTDJGgGNk+nVfAeE7s7WAZueDVxYzvlCCjFiQGoT/XNxsHmWghI22oPf+Ovoc0BaE Imoe9asZ+4L7YiuEBOdGI/dOAxcP/OamnsKiBJ4QaPHYauxtDgAVfBDwM8AoJCPRB1qC slaQd4Uo91MKO6qMP7k58mmFpWPLNCKDK2k5D2HR8CDTPE5d5DCf9/8j+wflkzp660d1 hUav8vvnSvzKROq8Dkv/5cpKihBErnCREzfiP+6OfoCGu5O9mk2LeJ9bvFWyeQno+X+F C7Bw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2lCa/xNen1Wkq2+0WBQYPFJ5N4YbUrrH4eHiahJKOmc=; b=Al4wnjTEuRDZkb+0qhx/j3vZB036UEUaqlNiEEkoAIzIKjtg9vQpc24M2WZXMMofwz w/Izcy0iqEgfWZhjpFww7k5HnuqQ8cGKuvhUBCtTjAl3gluI7IWbmdqC7XalwLhuUlJf itDMy1Gfo+ggsytx/9bVHMZxLPTMhuH6zJeAov36WW37ucqVUD9LA+BrYxqN1pCWTbSI znYugPNsj0SGAjxCNl8afAFb83tlpQM5ttb4uUbhlZG7HQqpnC7dQDu6spF7kXmjLOtL TwODXqsIvfu7DICSpJ2nPQpGupwFZOTdNOVvwsscT7ZHb1tr1d4wrnWA1jgJvkU//BXU dzlg==
X-Gm-Message-State: AIVw110QkbGsdpjodNKlGJhlIOtylHGaKQkhHHTlSby60a24AWqU3zM+ LTFYm1raEderavzcp84NmNVUfYftpO/0
X-Received: by 10.37.162.104 with SMTP id b95mr1025080ybi.29.1499314723872; Wed, 05 Jul 2017 21:18:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.215.9 with HTTP; Wed, 5 Jul 2017 21:18:03 -0700 (PDT)
In-Reply-To: <CABkgnnXXTVdvb+073VBvH7wXWYzpercrdBiHa8550Cpf_brGMw@mail.gmail.com>
References: <CABcZeBMgYNAfjD6_mDCQ4OmvifEXXP6R_FzA6o5BCRPm78kj0Q@mail.gmail.com> <20170706.111918.990342802355467009.kazu@iij.ad.jp> <CABkgnnUpUXWTcYgjr7Wd5T9KZ=c+cpEUfrm9V_Vtwgi-RVgGGw@mail.gmail.com> <20170706.130627.753481879086572434.kazu@iij.ad.jp> <CABkgnnXXTVdvb+073VBvH7wXWYzpercrdBiHa8550Cpf_brGMw@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 05 Jul 2017 21:18:03 -0700
Message-ID: <CABcZeBPPMSKa6OQh1OUQ=s9QtCZKOJV2r8wFyO8YJPJ94CX11Q@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Kazu Yamamoto <kazu@iij.ad.jp>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c19fcf885f05e05539e69e6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/MlxJBSOeuAA86xP_Flr-Pg7EZm0>
Subject: Re: [TLS] draft-ietf-tls-tls13-21 posted
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 06 Jul 2017 04:18:46 -0000

On Wed, Jul 5, 2017 at 9:11 PM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> We need the length field so that calling the function with different
> lengths results in different outputs.  Not that anyone should be doing
> that, of course.
>

The reason for this is that an adversarial application might do so.

Say you have the secret in an HSM that has some sort of access control
capability
that doesn't let you exfiltrate keys. If the application can make a key
that is a prefix
of another key, then you can exhaustively search the keys by first
extracting a
one-byte key and searching that, etc. (IIRC Mike St Johns pointed out this
attack to me).
Now it's not a great an attack, but it is still sort of an attack.

-Ekr


> On 6 July 2017 at 14:06, Kazu Yamamoto <kazu@iij.ad.jp> wrote:
> >>>        HKDF-Expand-Label(Secret, Label, *Value*, Length) =
> >>>             HKDF-Expand(Secret, HkdfLabel, Length)
> >>>
> >>>        struct {
> >>>            uint16 length = *Value.length*;
> >>>            opaque label<7..255> = "tls13 " + Label;
> >>>            opaque hash_value<0..255> = *Value*;
> >>>        } HkdfLabel;
> >>
> >> Length is the size of the output, so you don't want to assign
> >> Value.length to that field in the struct.
> >
> > Yes. I would remove the "length" field, too.
> >
> >> Also, you forgot to rename hash_value in the struct.
> >
> > You are right.
> >
> > --Kazu
> >
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>