[TLS] PR #699: Simplify traffic key expansion
Eric Rescorla <ekr@rtfm.com> Mon, 17 October 2016 20:09 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 EE8901298AB for <tls@ietfa.amsl.com>; Mon, 17 Oct 2016 13:09:15 -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 7bpf5HNGHATP for <tls@ietfa.amsl.com>; Mon, 17 Oct 2016 13:09:14 -0700 (PDT)
Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (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 798C91298A4 for <tls@ietf.org>; Mon, 17 Oct 2016 13:09:14 -0700 (PDT)
Received: by mail-yw0-x233.google.com with SMTP id t192so125276450ywf.0 for <tls@ietf.org>; Mon, 17 Oct 2016 13:09:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=dEUJyDvDlrmCoxorPftnNbnM3zG9yR1PkqShY0z2nqQ=; b=yJYFmiO7w0+v2y2cxY/U5xlelfmC8Skc5QMHDqB9qrQpCeG7Z+wbfL6umqVMRy5H5F Vqm7LlUQn91eUzssuBoXlK2PokEOhWeg1ax+8OZJJ8+c04SP4WyjdzyTpVrTtljqpn+t J3uo5/pFUtQVv9CjAh4gQ0D5IFGEh+VgnxZyjsJoXNQpLbHgtVhsq+4ps2auZEz5qqCb AQ33r2axKk61jc2fWotABu9pWLwnhvi6DCErDXbMx/+iB8DJ1sXRcxf5+IEH97ZVo1qJ Qhg0tySI7hz9v70OVzBrb5bLzlxXwluuqoZU5+WKwLrt5j/VWqyvtTosfvWhxLQnij11 3I+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=dEUJyDvDlrmCoxorPftnNbnM3zG9yR1PkqShY0z2nqQ=; b=bVphhOp9iW4+e5BQJazuKzYPXBpPXMyi606cPtSY3PjcvhbQkjCrBEjc3rNDGJ7LiW fZicSCRl5dEhtIIS+uZTXHXE0HRoa9o6pnhNo3DD10N9e0ICbmrQQ1QBNXSCwaNQiEUq +KOHOZMlsKe3yrxu53/UASpUuR/iCuYCEoHWCUU1l9bAJIVSQPC1RJgpHzkQnmkwh4Kd QRomf1v/YjUELIpMH7ZEYWCpvq+ScIDGDDlRdo6isojk9C/RpAoE0UjMBUAeGuZMK6+y xOmAJGYZCz5ODOUl3hFKpHsWy7uAZrHHVzEChjUz5fWLNB1alc8KZPdH0w3bOz4Ff3Fu SPlQ==
X-Gm-Message-State: AA6/9RmDx1cgULafCw54yndAK3XM4a575VhTKUKXdA8PZ2f5ZVtWBAet1PVCtTYeve79GaTVKCkJ8+qkyM5u1w==
X-Received: by 10.129.53.206 with SMTP id c197mr25218866ywa.205.1476734953548; Mon, 17 Oct 2016 13:09:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.75.212 with HTTP; Mon, 17 Oct 2016 13:08:33 -0700 (PDT)
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 17 Oct 2016 16:08:33 -0400
Message-ID: <CABcZeBPC2tbnFeGPKXMPCkiBW7HVNVwLaYeJTKXsCEznJXGtzw@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a11421a26559fcb053f1526aa"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Bj_RajAinznUoBAtor-Z_espMR0>
Subject: [TLS] PR #699: Simplify traffic key expansion
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 17 Oct 2016 20:09:16 -0000
Hi folks, https://github.com/tlswg/tls13-spec/pull/699/files A while back Steven Valdez pointed out that now that we have the PSK binder change and dual key ladders, each set of traffic keys is generated from a different base secret which has a label folded in [0], so we don't need to have the "phase" parameter in the traffic key calculation in Section 7.3, which simplifies things a bit. Due to an oversight, this didn't make it into the PR, but it seems straightforward. Please let me know ASAP if I have missed something here or you otherwise object. -Ekr [0] client_early_traffic_secret, [sender]_handshake_traffic_secret, [sender]_traffic_secret_N respectively
- [TLS] PR #699: Simplify traffic key expansion Eric Rescorla
- Re: [TLS] PR #699: Simplify traffic key expansion Kazuho Oku
- Re: [TLS] PR #699: Simplify traffic key expansion Martin Thomson
- Re: [TLS] PR #699: Simplify traffic key expansion Kazuho Oku
- Re: [TLS] PR #699: Simplify traffic key expansion Martin Thomson