Re: [TLS] draft-jay-tls-psk-identity-extension-01

David Woodhouse <dwmw2@infradead.org> Wed, 21 September 2016 19:16 UTC

Return-Path: <BATV+2953c840cc985df65dd1+4777+infradead.org+dwmw2@bombadil.srs.infradead.org>
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 8C9D312BBC4 for <tls@ietfa.amsl.com>; Wed, 21 Sep 2016 12:16:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.516
X-Spam-Level:
X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no
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 rpKEYxh5sFt1 for <tls@ietfa.amsl.com>; Wed, 21 Sep 2016 12:16:34 -0700 (PDT)
Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (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 19D4912BBEF for <tls@ietf.org>; Wed, 21 Sep 2016 12:16:30 -0700 (PDT)
Received: from [2001:8b0:10b:1:841b:5eff:0:f69] (helo=shinybook.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1bmn0M-0000WY-Ma; Wed, 21 Sep 2016 19:16:27 +0000
Message-ID: <1474485375.24595.250.camel@infradead.org>
From: David Woodhouse <dwmw2@infradead.org>
To: Raja ashok <raja.ashok@huawei.com>, Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Date: Wed, 21 Sep 2016 20:16:15 +0100
In-Reply-To: <FDFEA8C9B9B6BD4685DCC959079C81F5E18F6DA9@BLREML509-MBX.china.huawei.com>
References: <1474098807.2070.10.camel@gmail.com> <1474270465.144982.206.camel@infradead.org> <FDFEA8C9B9B6BD4685DCC959079C81F5E18F6DA9@BLREML509-MBX.china.huawei.com>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-8hL4AWp/JRIDhBbknXk4"
X-Mailer: Evolution 3.18.5.2 (3.18.5.2-1.fc23)
Mime-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by bombadil.infradead.org. See http://www.infradead.org/rpr.html
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/xhxMpdIVnyx4ihm1wDvndE9ZQI0>
Cc: "jayaraghavendran@gmail.com" <jayaraghavendran@gmail.com>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] draft-jay-tls-psk-identity-extension-01
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: Wed, 21 Sep 2016 19:16:36 -0000

On Wed, 2016-09-21 at 17:46 +0000, Raja ashok wrote:
> [ashok]  : PSK Identity extension specified in our extension differs
> from the extension specified in TLS1.3. 

Agreed. I suspect it just makes sense to add a sentence to that effect,
to the draft?

> [ashok] : I feel sending the selected ID is better, otherwise while
> process "server hello" msg, client has to maintain the PSK ID list in
> the same order in which it sent. Already there was a discussion in
> TLS1.3 group for sending selected ID instead of index. 

Yes, I agree. In TLS1.3 it kind of makes sense, because the PSK
identifiers there can be huge — they are the full session ticket from
RFC5077. So it makes some sense to send back only an index. But in
TLS <= 1.2 when you're not (ab)using PSK for session resumption, that
motivation goes away and returning the identity itself seems
reasonable. But again, it's just worth calling out the differences
between TLSv1.3 for clarity.

There is also discussion of supporting only a *single* PSK identity in
TLSv1.3. If that happens, is there a real need for the extension to
permit more than one identity in TLS <= 1.2. 

-- 
dwmw2