Re: [TLS] draft-ietf-tls-tls13 posted

Kazuho Oku <> Thu, 27 October 2016 05:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D7114129B96 for <>; Wed, 26 Oct 2016 22:27:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Z8gu3ApFsJYK for <>; Wed, 26 Oct 2016 22:27:12 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F22341293F0 for <>; Wed, 26 Oct 2016 22:27:11 -0700 (PDT)
Received: by with SMTP id 140so9407676wmv.0 for <>; Wed, 26 Oct 2016 22:27:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hWas8up3caf4fjEjU2YJyKcRqe6vNQFvgaXnokCGgp8=; b=OymF/DI6hfQdhMkOyJ5uwcEzREXwySTdm6L09HSZTh9jtFn2I48Db6I+QETDYaPQ92 qswbtdn/I1Dgc9BjMUxPTOfiWdAT/ZXGHBJMKJm5saqBOmrxGRsSMfAjfmqQ7wh072FO hFExUDagVFz7CUiO8ZxHAeh5Q+nBS81+EmM9KLynZvBdALfDROnwXUdcTbpEfV0O8VcW JAC5AYJDym5lIoqmCO9DAPQlkA7ffDe+cKXzuZc05ggqGdaF4q1RRD3RhIzn4mc8fEsY 8QqpPNuvQ/TW4d0nuGlZ6ykz2thlN3dBqyZdZzWD3USJZDGWpsbd6DxgjvXVucCd34dy lPXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hWas8up3caf4fjEjU2YJyKcRqe6vNQFvgaXnokCGgp8=; b=VoJ0uuCKVo5LD+3z7iiWrE8DeSwdB2ZG1ViQxv+tUr098LQ/1NXMvVyLZV1Zcd/Tgo 52dMIFJLHYOrTopVrr56bkBXubhoehT6RLA/7Dp/7IciktZU9VneexLohuc39Q9uc3CW J/JfryUQSrpUajVm8ylnwfjT9VyNHmnMCwwsxd37/+ykXgbqDnckHF9SQMSgyqRf1Vdf 1Otz3A45GAp2uKPbnyVw0ph+My67P0vXO4xQJ0h0X8tSKIWos9n/kBOJBhWKXC3o02ix 5oyO/RGokIMiMsDPc7MlCwtz1VBMuGIcc2VQbRAPzejYIbWjcPLEi7rOywJYH9v0O+dw eUQQ==
X-Gm-Message-State: ABUngvdn+mP9rPVzPrC8/tky9JbAMQXk2AYhxU5uTOwG63hOWxFNnOAl2ViWmZJmK/FGYH4XQnWL3yldNOmpqA==
X-Received: by with SMTP id x15mr1775703wma.31.1477546030385; Wed, 26 Oct 2016 22:27:10 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 26 Oct 2016 22:27:09 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Kazuho Oku <>
Date: Thu, 27 Oct 2016 14:27:09 +0900
Message-ID: <>
To: Eric Rescorla <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] draft-ietf-tls-tls13 posted
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 27 Oct 2016 05:27:14 -0000


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

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

Please forgive me for the fuss if the difference is intentional.

2016-10-26 14:43 GMT+09:00 Eric Rescorla <>;:
> 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

Kazuho Oku