IETF Logo Mail Archive

Re: [TLS] 0-RTT (Was: Re: 0-RTT and Anti-Replay)

Martin Thomson <martin.thomson@gmail.com> Wed, 13 May 2015 21:19 UTC

Return-Path: <martin.thomson@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 682DD1ACE64 for <tls@ietfa.amsl.com>; Wed, 13 May 2015 14:19:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
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 Pn1-GEe6TQ9J for <tls@ietfa.amsl.com>; Wed, 13 May 2015 14:19:00 -0700 (PDT)
Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) (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 3B30A1ACE52 for <tls@ietf.org>; Wed, 13 May 2015 14:19:00 -0700 (PDT)
Received: by yhda23 with SMTP id a23so17564642yhd.2 for <tls@ietf.org>; Wed, 13 May 2015 14:18:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=b3bP2T7iiWWtvBOxlvdpv/NrAWlnTURQnLQYIY1nW9o=; b=PhhautS0Eg3gFbo0OPRmuvDMD3YNgGdrcvOfLKjFlypJUiL1UM94CDMgx0e0Ao4Lay bX7nc/WH78DKYZlVkGGZnXd/W8pAh1pYgjTqQbMSLm+5mdjLKjYOrUIi6v3xPpPkhdpZ Qz/NTsc0ofCPQ64yo1MVyZ0tqoIoBKTzbRvJ+x2xvt8vqeQMt2OPnWAOa6zyMVK6BaM7 8NFUKbPhntZXW8ju2YkBuonHG9XAb1i3jzHOG/71n0xzzqvJUdBgFgx9pq2bAJ+g/G8V vFzsmGeLr2VO059ECSDZjb2Eupn3irfIxsw+XbBqhALLFa2ynNLhCxbMBrCvFQtDp7yZ yf/Q==
MIME-Version: 1.0
X-Received: by 10.170.44.208 with SMTP id 199mr940941ykm.101.1431551939630; Wed, 13 May 2015 14:18:59 -0700 (PDT)
Received: by 10.13.247.71 with HTTP; Wed, 13 May 2015 14:18:59 -0700 (PDT)
In-Reply-To: <20150513205817.GA24851@LK-Perkele-VII>
References: <CABcZeBP9LaGhDVETsJeecnAtSPUj=Kv37rb_2esDi3YaGk9b4w@mail.gmail.com> <20150412165542.GA19481@LK-Perkele-VII> <CABkgnnUr4wYkVwBGvH0MSmBnzNBd+T1s4aZJ5OvT_Gw3UyMSjQ@mail.gmail.com> <20150413181144.GA720@LK-Perkele-VII> <CABkgnnX6TqtUAV7zK8Cp6z25fJotiC22AXdkkXUhK6nnso9mBg@mail.gmail.com> <20150413191733.GB1016@LK-Perkele-VII> <CABkgnnVNFtri6sGMntEg7uNUMVsxbqReQ5-L5cTg=43FsOMr4A@mail.gmail.com> <20150413194605.GA1377@LK-Perkele-VII> <CABkgnnUiUXHxrUE+Hxi7Nzjpg0xUs6c3A7+WBnWJkvtU+W0BNg@mail.gmail.com> <20150414054606.GA7053@LK-Perkele-VII> <20150513205817.GA24851@LK-Perkele-VII>
Date: Wed, 13 May 2015 14:18:59 -0700
Message-ID: <CABkgnnX9WG01D4jkv6PdH6BfCiG1xvAg=Y_qwG5tt1e=Dh29mg@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/9gzn8ZnwiTZChVfzETUcrezxv9c>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] 0-RTT (Was: Re: 0-RTT and Anti-Replay)
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: Wed, 13 May 2015 21:19:01 -0000

On 13 May 2015 at 13:58, Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
> Suppose that client is willing to accept multiple of the three key
> exchange types (full-DHE, abbrevated and pure-PSK) at once. Now,
> all three are expected to use different keys. Under what keys does
> client encipher the 0RTT data?


Why wouldn't the client just choose and signal the option they chose?

BTW, it has been suggested that there might need to be some material
from the server contributed to this mix to prevent an unknown key
share attack.  So secret[x] + ClientRandom is not quite sufficient.

v2.23.0 | Report a Bug | By Email