Re: [TLS] TLS1.3 + PSK with multiple identities
"Andreas Walz" <andreas.walz@hs-offenburg.de> Wed, 05 October 2016 12:03 UTC
Return-Path: <andreas.walz@hs-offenburg.de>
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 175D01296BF for <tls@ietfa.amsl.com>; Wed, 5 Oct 2016 05:03:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.995
X-Spam-Level:
X-Spam-Status: No, score=-4.995 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-offenburg.de
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 wVBs-5P8GQuX for <tls@ietfa.amsl.com>; Wed, 5 Oct 2016 05:03:22 -0700 (PDT)
Received: from mx.hs-offenburg.de (mx.hs-offenburg.de [141.79.11.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61DC51296B6 for <tls@ietf.org>; Wed, 5 Oct 2016 05:03:22 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mx.hs-offenburg.de (Postfix) with ESMTP id 8B534F42767 for <tls@ietf.org>; Wed, 5 Oct 2016 14:03:20 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-offenburg.de; h=content-type:content-type:mime-version:in-reply-to:references :subject:subject:from:from:date:date:x-mailer:message-id :received:received:received; s=default; t=1475668996; x= 1476532997; bh=swUFYeMvzx+pfJFOBWsN3BTDZfgGRYpE6GFS1Wh/Wws=; b=G nyXhtAeVHkwdHtv5I5oP8wjcUVg9xMtb29pOsoShKY/U2iTraB6waLFgYSZDLMhN lA90Xd4/3KnwSrMSpY26suSomDmSAeJpWlqo8TUPSY4Wfx2d6LYWGYF2Q+n+gkXo wqvnkb5HEyDxNa1c0amZ+goUo/M+pqssYU1RCSOlpE=
X-Virus-Scanned: amavisd-new at hs-offenburg.de
Received: from mx.hs-offenburg.de ([127.0.0.1]) by localhost (mx.hs-offenburg.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLfBQEbYy-jh for <tls@ietf.org>; Wed, 5 Oct 2016 14:03:16 +0200 (CEST)
Received: from gwia2.rz.hs-offenburg.de (gwia2.rz.hs-offenburg.de [141.79.10.30]) by mx.hs-offenburg.de (Postfix) with ESMTPS id 8F4FAF4275A for <tls@ietf.org>; Wed, 5 Oct 2016 14:03:16 +0200 (CEST)
Received: from gw_dom-gwia2-MTA by gwia2.rz.hs-offenburg.de with Novell_GroupWise; Wed, 05 Oct 2016 14:03:16 +0200
Message-Id: <57F50825020000AC0011D029@gwia2.rz.hs-offenburg.de>
X-Mailer: Novell GroupWise Internet Agent 14.2.1
Date: Wed, 05 Oct 2016 14:03:17 +0200
From: Andreas Walz <andreas.walz@hs-offenburg.de>
To: olivier.levillain@ssi.gouv.fr
References: <1470644260.3026.13.camel@redhat.com> <20160808082836.jgq7a4qqvis6msp5@LK-Perkele-V2.elisa-laajakaista.fi> <1470648042.3026.44.camel@redhat.com> <1474278590.144982.255.camel@infradead.org> <CABcZeBNfzzZXmtEiMptB3_eKsydvvsZ0gBMzLLPbQcBHtF_H+A@mail.gmail.com> <57F291BC.9010604@ssi.gouv.fr>
In-Reply-To: <57F291BC.9010604@ssi.gouv.fr>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part32049C15.0__="
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/6vq1QYLoHJCWG3g3do3B4LOtXkA>
Cc: 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: Wed, 05 Oct 2016 12:03:27 -0000
Hi Olivier, your findings are interesting as they pretty much match with what we have found when studying TLS implementations for embedded systems. In many implementations there is a tendency to ignore redundant length fields (or at least to not enforce consistency). There has been some discussion about this on the list, see thread "Suspicious behaviour of TLS server implementations". We are currently refining our study and in the process of writing a paper. I hopefully can give more details on results soon. Cheers, Andi ___________________________________ Andreas Walz Research Engineer Institute of reliable Embedded Systems and Communication Electronics (ivESK) Offenburg University of Applied Sciences, 77652 Offenburg, Germany >>> Olivier Levillain <olivier.levillain@ssi.gouv.fr> 10/04/16 5:51 AM >>> Hi list, I have been working in the labs at ANSSI (the French Network and Information System Agency) for several years and I just defended my PhD thesis on the TLS ecosystem (documents are available at http://paperstreet.picty.org/~yeye/2016/phdthesis-Levillain16/). >> 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? >> > Not enough to fix it, this is just the way TLS rolls. Sorry if I am a little late to the party, but I noticed that even if this is generally true, I believe it has not always been enforced in TLS extensions. In 2006, the IETF standardised the session tickets extension, allowing for session resumption without server-side state (RFC 4507). However, no TLS stack implements the specification correctly: even if the specification described the _content_ of the extension as a variable-length object (that is an opaque object prefixed by its length), every implementation ignores this second (useless) length field. The RFC 5077, published in 2008, fixes the gap between the specification and the implementations. RFC 4507 : The SessionTicket extension has been assigned the number 35. The format of the SessionTicket extension is given at the end of this section. struct { opaque ticket<0..2^16-1>; } SessionTicket; 00 23 Ticket Extension type 35 01 02 Length of extension contents 01 00 Length of ticket FF FF .. .. Actual ticket RFC 5077 The SessionTicket extension has been assigned the number 35. The extension_data field of SessionTicket extension contains the ticket. 00 23FF FF .. .. Actual ticket Best regards, olivier _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
- Re: [TLS] TLS1.3 + PSK with multiple identities Nikos Mavrogiannopoulos
- Re: [TLS] TLS1.3 + PSK with multiple identities Ilari Liusvaara
- [TLS] TLS1.3 + PSK with multiple identities Nikos Mavrogiannopoulos
- Re: [TLS] TLS1.3 + PSK with multiple identities David Woodhouse
- Re: [TLS] TLS1.3 + PSK with multiple identities Eric Rescorla
- Re: [TLS] TLS1.3 + PSK with multiple identities David Woodhouse
- Re: [TLS] TLS1.3 + PSK with multiple identities Eric Rescorla
- Re: [TLS] TLS1.3 + PSK with multiple identities David Woodhouse
- Re: [TLS] TLS1.3 + PSK with multiple identities Eric Rescorla
- Re: [TLS] TLS1.3 + PSK with multiple identities David Woodhouse
- Re: [TLS] TLS1.3 + PSK with multiple identities Eric Rescorla
- Re: [TLS] TLS1.3 + PSK with multiple identities David Woodhouse
- Re: [TLS] TLS1.3 + PSK with multiple identities Eric Rescorla
- [TLS] application-specific identifier was: TLS1.3… Nikos Mavrogiannopoulos
- Re: [TLS] TLS1.3 + PSK with multiple identities Olivier Levillain
- Re: [TLS] TLS1.3 + PSK with multiple identities Andreas Walz
- Re: [TLS] TLS1.3 + PSK with multiple identities Hannes Tschofenig