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