Re: [TLS] TLS1.3 + PSK with multiple identities

David Woodhouse <dwmw2@infradead.org> Mon, 19 September 2016 10:28 UTC

Return-Path: <BATV+e4a5c8c88c3adab274df+4775+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 674A812B2EB for <tls@ietfa.amsl.com>; Mon, 19 Sep 2016 03:28:12 -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=unavailable 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 iRH6zJvK90EJ for <tls@ietfa.amsl.com>; Mon, 19 Sep 2016 03:28:11 -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 B6F1A12B2D8 for <tls@ietf.org>; Mon, 19 Sep 2016 03:26:52 -0700 (PDT)
Received: from [2001:8b0:10b:1:841b:5eff:0:3b3] (helo=i7.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1blvmm-0008Gu-4Z for tls@ietf.org; Mon, 19 Sep 2016 10:26:52 +0000
Received: from dwoodhou by i7.infradead.org with local (Exim 4.87 #1 (Red Hat Linux)) id 1blvmk-000b3F-8r for tls@ietf.org; Mon, 19 Sep 2016 11:26:50 +0100
Message-ID: <1474278590.144982.255.camel@infradead.org>
From: David Woodhouse <dwmw2@infradead.org>
To: Nikos Mavrogiannopoulos <nmav@redhat.com>, Ilari Liusvaara <ilariliusvaara@welho.com>
Date: Mon, 19 Sep 2016 10:49:50 +0100
In-Reply-To: <1470648042.3026.44.camel@redhat.com>
References: <1470644260.3026.13.camel@redhat.com> <20160808082836.jgq7a4qqvis6msp5@LK-Perkele-V2.elisa-laajakaista.fi> <1470648042.3026.44.camel@redhat.com>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-eu/9+vK4ORfa0CbHh3RN"
X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24)
Mime-Version: 1.0
Sender: David Woodhouse <dwmw2@infradead.org>
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/Ly0AJgPUufVVXOCOYJL7UC7U1wo>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS1.3 + PSK with multiple identities
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: Mon, 19 Sep 2016 10:28:12 -0000

On Mon, 2016-09-19 at 10:29 +0200, Nikos Mavrogiannopoulos wrote:
> On Mon, 2016-08-08 at 11:28 +0300, Ilari Liusvaara wrote:
> > More compact and makes the option where server sends some bad option
> > more clear.

Note that if we really want to be more compact, we might also observe
that there is a redundant length field in the extension as sent by the
client:
           case client_hello:
               PskIdentity identities<6..2^16-1>;

Each extension has at least four bytes on the wire — the extension_type
itself, and the length field of the extension_data in a uint16.

If I am interpreting the spec correctly, then the data for the
PreSharedKeyIdentity extension in the ClientHello then follows that
with another uint16, which is *always* a value two lower than the one
which immediately precedes it.

e.g.

  0x00 0x29      // ExtensionType extension_type == 41
  0x00 0x14      // opaque extension_data<0..2^16-1>
    // This length field is entirely redundant:
    0x00 0x12      // PskIdentity identities<6..2^16-1>
                     // First identity:
      0x00 0x00      // PskKeyExchangeMode, PskAuthenticationMode
      0x00 0x04      // opaque identity<0..2^16-1>
        0x44 0x61 0x76 0x65 // "Dave"
                     // Second identity:
      0x00 0x00      // PskKeyExchangeMode, PskAuthenticationMode
      0x00 0x06      // opaque identity<0..2^16-1)>
        0x43 0x68 0x6c 0x6f 0xc3 0xab // "Chloë"
 
Do we care that the '0x00 0x12' bytes on my third line above are
entirely redundant on the wire? Or have I interpreted it wrong?

I also find it interesting to note that the total permitted length of a
single PskIdentity (65539 bytes) is such that you might not be able to
fit even *one* of them into the PreSharedKeyIdentity extension at all,
let alone multiple such.

> > > 2. Why does the client send multiple identities? In TLS-SRP a single
> > > identity is sent, and the same in the existing TLS-PSK rfc. How is this
> > > envisioned to be used? A client sends: I'm probably one of Bob, Nikos,
> > > George, take a look on that list and tell me who I really am? In that
> > > case why not allow the server, to reply with a username outside that
> > > list (i.e., assign a new one to be used at the next session - see point
> > > 1).
> > You already need multiple if you try to "resume"[1] DHE-PSK session
> > (since "resumption" shares the PSK space).
> 
> That's very awkward. That way the protocol mandates code like:
> 
> if (!id_in_resumption_db()) {
>     if (!valid_ticket())
>       if (!try_find_user_in_psk_userfile())
>         proceed_with_random_psk(); /* hide the fact that username
> doesn't exist in db */
> }
> 
> which is not really sane code. Not only that, but servers who would
> like to prevent valid username testing in their PSK key file as above,
> would be forced to make resumption attempts with unknown or long-
> expired tickets fail.
> 
> A protocol must have clarity on the data sent on the wire and their
> purpose. Cross protocol attacks work by exploiting data which may be
> interpreted in multiple ways and such generic purpose identifiers seem
> to be like a good candidate for that.
> 
> I think at minimum identities known to the protocol (e.g., resumption)
> should be distinguishable from PSK usernames. The draft leaves that to
> the server implementor to do, but I do think such identifiers should be
> tagged at the protocol level since it affects all implementations.
> 
> > 
> > 3. The maximum size of the username is 2^16. Isn't that excessive
> > > 
> > > for a
> > > user name or a user identifier? Why not set 2^8? That would fit a
> > > uuid
> > > or anything similarly large.
> > If one wants to do the equivalent of tickets in TLS 1.2, one needs
> > pretty large usernames.
> 
> I find that, as another unfortunate side-effect of combining unrelated
> protocol fields.

Oh, it's more fun than that. RFC4279 §5.1 currently says that the PSK
identity MUST be a UTF-8 character string. Libraries such as OpenSSL
and GnuTLS already handle identities as NUL-terminated strings.

The current TLSv1.3 draft appears to relax that requirement without any
form of explicit compatibility note about it — I'd expect to see *some*
mention in the 'Major Differences from TLS 1.2" section.

Perhaps one way to resolve much of this is to put the traditional PSK
identities into one PreSharedKeyExtension and maintain the UTF-8
requirement there, and to put the "identity" used for session
resumption into a different extension. Perhaps allowing the latter to
appear multiple times in a ClientHello and for their contents to be
concatenated, which partly addresses the problem of their total size.

Is there no way the PSK identities for session resumption could be made
smaller? Of the data which RFC5077 suggests that we put into a session
ticket (and thus the PSK identity), is there *none* of it which could
be sent later in a ClientKeyExchange packet? Does the server need *all*
of it, for every session being offered for resumption by the client, in
the ClientHello?


My final comment on the PSK identities for now... I see the TLSv1.3
draft now contains a PskKeyExchangeMode which is absent from the
(once-)corresponding draft-jay-tls-psk-identity-extension. It's not
entirely obvious to me how this interacts with the selected cipher
suite, which itself may or may not use (EC)DHE.

Is it permitted, and what is the meaning, to request a cipher suite of
(e.g.) TLS_PSK_WITH_AES_256_CBC_SHA and set PskKeyExchangeMode in the
identity to 'psk_dhe_ke'? Or conversely, to use the cipher suite
TLS_DHE_PSK_WITH_AES_256_CBC_SHA with PskKeyExchangeMode set to
'psk_ke'?

This seems redundant to me at first glance (unless some combinations
really do mean that you end up doing DHE *twice*) and could probably do
with some clarification.

Or is the intent that when requesting offering both DHE and non-DHE
cipher suites, the client should offer *two* identities, one with each
possible value of PskKeyExchangeMode? In which case do we want a third
value for PskKeyExchangeMode which indicates that a given identity may
be used in either mode?

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation