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

Colm MacCárthaigh <colm@allcosts.net> Mon, 14 March 2016 16:15 UTC

Return-Path: <colm@allcosts.net>
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 CD0AF12DAE3 for <tls@ietfa.amsl.com>; Mon, 14 Mar 2016 09:15:20 -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=allcosts-net.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 dkx3KkfpxNQi for <tls@ietfa.amsl.com>; Mon, 14 Mar 2016 09:15:19 -0700 (PDT)
Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (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 389A112DA88 for <tls@ietf.org>; Mon, 14 Mar 2016 09:15:18 -0700 (PDT)
Received: by mail-yw0-x22c.google.com with SMTP id d65so173561333ywb.0 for <tls@ietf.org>; Mon, 14 Mar 2016 09:15:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=KelSatOdjkt8sHCnKZRMAi1il8geuDNcrVhaMCHC6fM=; b=bxuhhlfnt8Kvk2Pac1ZrycvgaUwYBYj3jMeGLf2/Ydtl9AziuDTZYZ42SfVWso3c41 7O1yKLayBvwCgqSnTQgxEBveGw9KwDnwcvF66mcTQX9/5EFiKj8Hv/b52VkuW9Wu7iYg e3H8iTvtI3apjC+vy6unD16vJ+0yR8kHDFXHfQOf3hvd6pl1/J4xhXdNWGksPFdXJjVn O//auuhBywaRbqBxicKLrVRgdwVlaWJ+JBf9NOPx9uqsmjSeNQhvlYIljblR+nGiCg5g WZyDsQ3OpoPla4wV3E0hd1RWgXdJKvDeVNUJMe32/5Cmzk3m8Bulr9VNgynIIXpJP0aW 8OJA==
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=KelSatOdjkt8sHCnKZRMAi1il8geuDNcrVhaMCHC6fM=; b=a8/Eir4LznUNxGXDygozI9hHR9QMCzPw6xkHoDPBHzGar22ucvPds/LlF5QAFDYhWg BiVvDdwZDnds2+REd+z5tDex8KQJ/CMoVWtrgKwNllPghD7PKymPZ6RikdIFRUBcb9Pu ih6AQPCd/uv0boiAzsD775cCSOxDpJzvgUdQjD5CPbTeNhSqQDwi1av2x6QZmhJiOXnq xLlebo0gejw1+AiZsLZOQs2TEVfORy1BbBwOQG/LQ0bMHN4erjEOE/NLacVLwjBTicBu gpk+ZoDaeMuYanEwmSOJaSLeXdPitnMbXXUXdVvjzzrCeGS2wwb5FqRHlyl0IR2CSwny WqDw==
X-Gm-Message-State: AD7BkJJq+kWaaxHX+pppXw0M2FpfqK+crmG+l+FH9ZSqAj3HorO5zKQ2vtSvzPE+RCFkREAY5SnGclv4sTcjLA==
MIME-Version: 1.0
X-Received: by 10.129.155.151 with SMTP id s145mr12155788ywg.24.1457972117298; Mon, 14 Mar 2016 09:15:17 -0700 (PDT)
Received: by 10.129.32.196 with HTTP; Mon, 14 Mar 2016 09:15:17 -0700 (PDT)
In-Reply-To: <CABcZeBP+1vmfNmmAr1+CcXUkNA0yS6CGa7La7ekQgtyFkiFtSQ@mail.gmail.com>
References: <56E54B85.4050204@cs.tcd.ie> <CAAF6GDeOFNgNt_+O=gkBedqP55qdnOpKKQ9-HOQ6i7fYpLanqw@mail.gmail.com> <CABcZeBP+1vmfNmmAr1+CcXUkNA0yS6CGa7La7ekQgtyFkiFtSQ@mail.gmail.com>
Date: Mon, 14 Mar 2016 09:15:17 -0700
Message-ID: <CAAF6GDfcrZyeLo_n9LEPHzXTPSXv8iRWBiNebARYYAKp9CfQmQ@mail.gmail.com>
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= <colm@allcosts.net>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: multipart/alternative; boundary=94eb2c0b8da82546de052e0496ad
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/J3b4q4Zy2_mSe7A1geVVIdGaKCA>
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 16:15:21 -0000

On Mon, Mar 14, 2016 at 4:32 AM, Eric Rescorla <ekr@rtfm.com>; wrote:

> For 1. Raw data throughput could be improved by envelope encrypting the
> early data; and transferring the envelope key only once the session has
> been fully authenticated
>

1. Client generates a random secret and uses it to derive encryption and
mac keys.
2. Client encrypts its early data using this key. Sends more-or-less per
0-RTT in the existing draft.
3. Post-handshake; the client sends a new message - encrypting using the
regular session key - which has the early data encryption and mac keys in
it.
4. Server uses those keys to decrypt the early data; which it buffered.
5. Client and server both erase and forget the ephemeral early data keys.

Useful if you want to upload a software update to Mars; maybe not to useful
to others; it just helps you make the most of the TCP window. So it
improves throughput, but not latency so much.

Can you expand on this. Cryptographically, this is effectively how both the
> DHE and PSK
> modes work: you get a key in session N (which is authenticated) and you
> use it
> in session N+1.
>


Makes sense!

-- 
Colm