IETF Logo Mail Archive

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

Bill Cox <waywardgeek@google.com> Mon, 14 March 2016 19:16 UTC

Return-Path: <waywardgeek@google.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 55A2C12D72A for <tls@ietfa.amsl.com>; Mon, 14 Mar 2016 12:16:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 4AHr6uh7HnxF for <tls@ietfa.amsl.com>; Mon, 14 Mar 2016 12:16:36 -0700 (PDT)
Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (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 E452C12D722 for <tls@ietf.org>; Mon, 14 Mar 2016 12:16:35 -0700 (PDT)
Received: by mail-ig0-x231.google.com with SMTP id ig19so70196994igb.0 for <tls@ietf.org>; Mon, 14 Mar 2016 12:16:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=sORh9VLrOt+icdNShwwDCKvMGnus1rpfVfkhmLnaWk4=; b=pMgrk6kbeRVpANfUPO53ByFOa+vNyGjQA/phTPD/rgdI1/4LvpvOZy77sxTeTJKvZQ ALjfJQldWABKuM3ataJe9HdHB1n7LxpggH/oazjeFBe28yzBUjsgarZNJYp9mOX7BBa1 0zGrnZ7fhHEMN+GtSNh+Om+U0Y6Mca+ZG2yurIINe9hpmo7a/aQt+ynnvBxyNKGqy932 YJJJlQSPvlyxo6pNn/RZ28VZ/QyfhrWI2syTi/5x8KjScARnqdNXjCq1qfqy6s2Z70UW vkcGdYIqr6uQtOl+LWnWVutjEb5eXwXyVM9Ev2n1qy+1tOFyMp6yRBRHo1y1y/kcXsMk 4wtw==
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:date :message-id:subject:from:to:cc; bh=sORh9VLrOt+icdNShwwDCKvMGnus1rpfVfkhmLnaWk4=; b=UEASwMgdN6jKM9Lm/miOQPqcjCwF2+gJjdi7KhBCHjtkQ2zScQxZuxxD4rFXCyXa3C vOa25ItxTI4OWeClYRaL7zpSk1vK9ybZXZAbVXEfvinABxXzTLYXxrR7KAQXSa4hEzU0 prOXafdWXTV0IRsjdPVfnPU82jryE61P72AErA+xc/abX2QR/wJDSLVcT2iplBwmQoOd kPbtllx2eEqbi6ul1/wxCkzrj7zr/8a/JUmYVEQxRI+6fkwJN47nTvb3r/92rNrWv53S aDLKVF4r52B1Shj0/TYx1V5tLpsk0CoyjgFI0DjsshIxBbBU/oX1t4BjYgpw9qIb3FGq EuwQ==
X-Gm-Message-State: AD7BkJJ/kaoYhy7jXXxoMCpu7kApj1Sr3eMotOGy1B2oOGCIpVJO39orYcpEQV6vU27+bXVeGXaiuDHhT9HLTzy3
MIME-Version: 1.0
X-Received: by 10.50.70.39 with SMTP id j7mr19294984igu.40.1457982995174; Mon, 14 Mar 2016 12:16:35 -0700 (PDT)
Received: by 10.107.183.141 with HTTP; Mon, 14 Mar 2016 12:16:34 -0700 (PDT)
In-Reply-To: <CAAF6GDcLuDy+QEWXw8s=oCipKqoi7s=i52BfXH7G=ir7Z4gYaA@mail.gmail.com>
References: <56E54B85.4050204@cs.tcd.ie> <CAAF6GDeOFNgNt_+O=gkBedqP55qdnOpKKQ9-HOQ6i7fYpLanqw@mail.gmail.com> <CABcZeBP+1vmfNmmAr1+CcXUkNA0yS6CGa7La7ekQgtyFkiFtSQ@mail.gmail.com> <CAAF6GDfcrZyeLo_n9LEPHzXTPSXv8iRWBiNebARYYAKp9CfQmQ@mail.gmail.com> <20160314184153.GA14692@LK-Perkele-V2.elisa-laajakaista.fi> <CAAF6GDcLuDy+QEWXw8s=oCipKqoi7s=i52BfXH7G=ir7Z4gYaA@mail.gmail.com>
Date: Mon, 14 Mar 2016 12:16:34 -0700
Message-ID: <CAH9QtQG0Tdnd3rcv4O=_54Exkw3unR7nEA7GsFSgLtthxMBfNg@mail.gmail.com>
From: Bill Cox <waywardgeek@google.com>
To: Colm MacCárthaigh <colm@allcosts.net>
Content-Type: multipart/alternative; boundary="047d7b3a93c68476d4052e071e9d"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/1ElZKwH7MQ_U8znrBSdT2qHLbp8>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data
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, 14 Mar 2016 19:16:38 -0000

On Mon, Mar 14, 2016 at 11:57 AM, Colm MacCárthaigh <colm@allcosts.net>
wrote:

>
>
> On Mon, Mar 14, 2016 at 11:41 AM, Ilari Liusvaara <
> ilariliusvaara@welho.com> wrote:
>>
>> (Also, with regards to my comment about cryptographic screwedness,
>> such screwedness is not inherent in DH-0RTT, but is consequence of
>> the current implementation).
>>
>
> This is interesting ... is there a way to do it that would preserve
> forward secrecy?
>

Replay resistance requires server-side state.  If that state includes
session decryption keys and we want PFS, then these keys need to be
encrypted using keys held by the client, which is not possible in DH
0-RTT.  Therefore the session keys cannot be saved on the server, and the
0-RTT data cannot be encrypted using anything but the server's static
keyshare, which is not fully PFS.  I see no way to implement real PFS in
the existing DH 0-RTT scheme.  However, I consider a few days of non-PFS to
be good enough.

Bill

v2.23.0 | Report a Bug | By Email