Re: [TLS] draft-ietf-tls-tls13 posted
Kazuho Oku <kazuhooku@gmail.com> Thu, 27 October 2016 05:41 UTC
Return-Path: <kazuhooku@gmail.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 93BA6129BF1 for <tls@ietfa.amsl.com>; Wed, 26 Oct 2016 22:41:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 BrGPAmVmzgrY for <tls@ietfa.amsl.com>; Wed, 26 Oct 2016 22:41:57 -0700 (PDT)
Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 AB390129BE4 for <tls@ietf.org>; Wed, 26 Oct 2016 22:41:56 -0700 (PDT)
Received: by mail-wm0-x22d.google.com with SMTP id 140so9890367wmv.0 for <tls@ietf.org>; Wed, 26 Oct 2016 22:41:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nIjFGYaDbeI/wi3YTg4bM9B+0l9pKLy4NWjqJ+jYunk=; b=lWRIVgS7ZTQJaBcTM3d6UOHg7ICtQmeRFn6dFgoalKMzgAaq3wLRNYr96rMLhIH3PI WGEynIiuQ8Ob5vJQVRrzSet/QDEeB02ZjHTlDUfnCK0Q5FadQAM94jxnIlgjHpfEbd6n GzVIqr2GV4AoFIlSDlsYDuoRAxSkAEjiZw+AMwAlZKe+SQInkAXP5X0OXa5cxS3rRyVM iUUrVssTNS3xPsrUXZOWfON/f/M2pneI3wBxW89HgaN2iV4z9ju/H7/zx/xsvvF+KFMQ h1PkHh6yJz51VPOqPXcj7OMqD9k3DXwc5hUh1AV8rfZ4auu2vJ3OHBN/pTNVb5s24jxm JW5w==
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:from:date :message-id:subject:to:cc; bh=nIjFGYaDbeI/wi3YTg4bM9B+0l9pKLy4NWjqJ+jYunk=; b=l8eqbHWhacGlFcyiAYkQw9hTb0CMwkXSg5v8dORBRDbwHlGmbibMF58CN0qpxQ9LjO yj1lnWE/PQ3InrNMtNp03kcUiPkC2cZzsWVATwrrpcsRC+KPUrtb606Bm9JcsPVdNi2J M05idJLDKz4qH5QV7fVo15q2SvpJC9KHTPJFvDO8QMqpgHua8wMGv5J75Tng6bzjcb0V rFVYBT9/mlDfblM2NayTv4suXfYJGaZNH40fy6WQE0Kx/XbkN83Mp8dFG2Fwx3QalWUZ rqIunTjkmubx0RDRefzuY/UC7oq2Ds/Fcesuhq4MCxYbNcCxgGHkP1iM97dtw9ss1ydo dXdA==
X-Gm-Message-State: ABUngvcqQMP32rNu/v0SfaOYrSj+qNrrZr+DzrIhZ64E3dPkPyN8WVMdSvOKnS+x/VUm4fdds2ojkyL7YHo25w==
X-Received: by 10.194.177.230 with SMTP id ct6mr5021424wjc.145.1477546915198; Wed, 26 Oct 2016 22:41:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.163.69 with HTTP; Wed, 26 Oct 2016 22:41:54 -0700 (PDT)
In-Reply-To: <CABcZeBOc5phUGGVvzk_xExXgVTZZhhiiHLrza4KypdL=vE-YNA@mail.gmail.com>
References: <CABcZeBMRNf3EEtKMus9Rhy=h0y7jjxm8w1AumU=0bwY1zyiXQQ@mail.gmail.com> <CANatvzwtsDJdxzM0rEwrDK5XCdnjFPT7nx5bi5YLpjDSS+xLyQ@mail.gmail.com> <CABcZeBOc5phUGGVvzk_xExXgVTZZhhiiHLrza4KypdL=vE-YNA@mail.gmail.com>
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Thu, 27 Oct 2016 14:41:54 +0900
Message-ID: <CANatvzzbL+-hok4ByCyM2r45dZ9EWLKyu_XMj9aosy18F9zPmQ@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/p8s8StgJD_rOTAowzubCX4VYAyg>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] draft-ietf-tls-tls13 posted
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: Thu, 27 Oct 2016 05:41:58 -0000
2016-10-27 14:30 GMT+09:00 Eric Rescorla <ekr@rtfm.com>: > > > On Thu, Oct 27, 2016 at 4:27 PM, Kazuho Oku <kazuhooku@gmail.com> wrote: >> >> Hi, >> >> Thank you for posting draft-18, and thank you for the simplification of >> RMS. >> >> I have finished implementing resumption and early-data in picotls. The >> effort started just before draft-17 was published, so it would be fair >> to say that my effort is solely based on the up-to-date specification. >> >> I am happy to report that all I have found is one minor issue. >> >> The issue I saw is discordance between PSKIdentity.identity and >> NewSessionTicket.ticket. >> >> In draft-18, PSKIdentity.identity is defined as <0..2^16-1>. OTOH >> NewSessionTicket.ticket is <1..2^16-1>. >> >> Is there any reason to only allow a zero-length identity for the former? >> >> My understanding is that when resuming a session, the value of >> NewSessionTicket.ticket is sent as PSKIdentity.identity. So to me, it >> seems more natural if the permitted range of the two arrays were >> equal. >> >> Please forgive me for the fuss if the difference is intentional. > > > Well, you could have an external PSK which I suppose might be zero length. > > But I also wouldn't argue if we required this to be nonzero length. Thank you for the clarification. Yes, having a zero-length external PSK makes sense. And for the same reason, I would argue that having a zero-length session identifier makes sense as well. For a client-server pair that only talk to the other, a zero-length session identifier would work well. So if we are going to align the ranges of the two arrays, it might make more sense to allow zero-length for both of them, instead of disallowing it. Please forgive me for the nit-pick. > -Ekr > >> >> 2016-10-26 14:43 GMT+09:00 Eric Rescorla <ekr@rtfm.com>: >> > Folks, >> > >> > I have just posted draft-ietf-tls-tls13-18. >> > >> > The only wire format change from -17 is that I removed the extra key >> > derivation stage computing resumption_psk from RMS. This was a >> > holdover from when we also had a resumption context. Now PSK for >> > connection N+1 = RMS from connection N. Thanks to Kazuho for >> > suggesting this simplification. >> > >> > This draft also makes a number of minor editorial changes that >> > should make for easier reading. >> > >> > The two remaining open technical issues I am aware of are both >> > requirements issues: >> > >> > 1. Can you resume with a different SNI than the one that the >> > connection was initiated with [current answer is "no"]? >> > >> > 2. Do you need an application profile to do post-handshake >> > client auth [current answer is "no"]? >> > >> > There has been a bunch of discussion of these on the list but no >> > consensus declarations from the chairs. These are easy to change >> > in the draft once the chairs make the call. >> > >> > As always, comments welcome. >> > >> > -Ekr >> > >> > P.S. NSS will be skipping draft-17 and going right to -18. This >> > should happen before Seoul. >> > >> > >> > _______________________________________________ >> > TLS mailing list >> > TLS@ietf.org >> > https://www.ietf.org/mailman/listinfo/tls >> > >> >> >> >> -- >> Kazuho Oku > > -- Kazuho Oku
- [TLS] draft-ietf-tls-tls13 posted Eric Rescorla
- Re: [TLS] draft-ietf-tls-tls13 posted Kazuho Oku
- Re: [TLS] draft-ietf-tls-tls13 posted Eric Rescorla
- Re: [TLS] draft-ietf-tls-tls13 posted Kazuho Oku
- Re: [TLS] draft-ietf-tls-tls13 posted Martin Thomson