Return-Path: <karthik.bhargavan@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1])
 by ietfa.amsl.com (Postfix) with ESMTP id 1FDA41A0AFE
 for <tls@ietfa.amsl.com>; Sun,  3 Aug 2014 10:25:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level: 
X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_46=0.6,
 SPF_PASS=-0.001] autolearn=no
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 4OyCgbfwbxt9 for <tls@ietfa.amsl.com>;
 Sun,  3 Aug 2014 10:25:24 -0700 (PDT)
Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com
 [IPv6:2607:f8b0:400d:c00::235])
 (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
 (No client certificate requested)
 by ietfa.amsl.com (Postfix) with ESMTPS id 05AF91A0B00
 for <tls@ietf.org>; Sun,  3 Aug 2014 10:25:23 -0700 (PDT)
Received: by mail-qa0-f53.google.com with SMTP id v10so5914683qac.26
 for <tls@ietf.org>; Sun, 03 Aug 2014 10:25:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 
 h=content-type:mime-version:subject:from:in-reply-to:date:cc
 :content-transfer-encoding:message-id:references:to;
 bh=Q6jNw9HP1SFIkcxIo2fLgQv8zSUI0eSIEA0E3wBg/ko=;
 b=izJD69HaxcnvoMpq/WVQOfRAFskbmO3iATk3X/Y/el7l5Glv9OSJ/lBETNi+7e/CEI
 3xBC1RPrxBvN9raPYjmr0ITkNAA7+UvjkqWIm076pAORdSiGw+tOp2PJamoNWVei/Sbt
 xhTP4buQtMLEZqMznhdJL0JllPnEnclOppu1ACX0S2tgn66cJBIAQcDfNzkfCJlnfuWe
 4vrzEZh1q1yVtEx4pOWk60fcGUEZKXsoYTKj2KEF+u6jcogI2zqu6Wt0vBNoyWEQlkkt
 VFC3lYPGvKOSXmqqfl3smlL2thIk3OL2bIojOhk0xYzKa0uyGxKvLm5697O8tG87YYl6
 3XHw==
X-Received: by 10.229.225.131 with SMTP id is3mr29265959qcb.2.1407086723075;
 Sun, 03 Aug 2014 10:25:23 -0700 (PDT)
Received: from [10.0.1.3] (pool-72-92-130-2.burl.east.myfairpoint.net.
 [72.92.130.2])
 by mx.google.com with ESMTPSA id m20sm26839018qax.25.2014.08.03.10.25.21
 for <multiple recipients>
 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
 Sun, 03 Aug 2014 10:25:21 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Karthikeyan Bhargavan <karthik.bhargavan@gmail.com>
In-Reply-To: <CACsn0c=wUvV1M0kZ2y6OcC_UPoRtBRz1Nh_zb_sLYamozoPrpw@mail.gmail.com>
Date: Sun, 3 Aug 2014 13:25:17 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <1F069E66-C658-42F2-B334-AAC72F117F8C@gmail.com>
References: <CACsn0c=wUvV1M0kZ2y6OcC_UPoRtBRz1Nh_zb_sLYamozoPrpw@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6IekJXBVk2DasmFCTGCSYuLBPc0
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] 0RTT?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Sun, 03 Aug 2014 17:25:26 -0000


> The PMS that gets used is PMS_interim=3D HMAC(old_PMS, nonce || =
refresh
> key): data encrypted as usual under the old ciphersuite follows.=20

I guess I don=92t understand what this means. Is the new application =
data encrypted
under (a) the old MS? (b) a new MS derived from PMS_interim (and the old =
randoms)?=20


>=20
> On receiving this a server looks up the anti-replay nonce and checks
> it is fresh. To make this easier we include UTC time since the epoch (
> midnight of 1 January 1970) and mandate some degree of synchronization
> and a window. To avoid tagging with clock drift we truncate some low
> order bits after adding a random small offset.
>=20
> If the nonce is not previously seem the server can send Application
> Data as normal.
>=20
> We now introduce a new handshake type: Rekey Finish, containing a new
> ticket and server key. CCS follows afterwards. These are sent
> encrypted.
>=20
> The new PMS will be HMAC(PMS_interim, ECDH(server, client keys)).
>=20
> The big limitation is ticket keys are going to need rotation. This
> also doesn't address the desire to put extra data in DNS to give some
> degree of forward secrecy, but I don't think you can change DNS that
> quickly without some problems.
>=20
> Furthermore, if we want rekeys without renegotiation, we can reuse
> Rekey Finish and add a Rekey Initiate handshake type that will send
> the client key.
>=20
> Open questions: how secure is this? We certainly need to hash the
> anti-replay nonce into the keys: is that all we need? (Not if we want
> to avoid attackers manipulating which method we use) Does noisy
> truncation work to prevent fingerprinting while reducing storage
> requirements?
>=20
> Sincerely,
> Watson Ladd
>=20
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls