Re: [TLS] TLS1.3 + PSK with multiple identities
Hannes Tschofenig <hannes.tschofenig@gmx.net> Wed, 05 October 2016 12:33 UTC
Return-Path: <hannes.tschofenig@gmx.net>
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 ED4BB1296C3 for <tls@ietfa.amsl.com>; Wed, 5 Oct 2016 05:33:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.597
X-Spam-Level:
X-Spam-Status: No, score=-5.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] 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 2AWSQGBzX7Bj for <tls@ietfa.amsl.com>; Wed, 5 Oct 2016 05:33:52 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DF6E1296AD for <tls@ietf.org>; Wed, 5 Oct 2016 05:33:51 -0700 (PDT)
Received: from [192.168.91.133] ([195.149.223.37]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M1FAK-1b2yBn2vf6-00t8hp; Wed, 05 Oct 2016 14:33:39 +0200
To: Andreas Walz <andreas.walz@hs-offenburg.de>, 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> <57F50825020000AC0011D029@gwia2.rz.hs-offenburg.de>
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <cc99eff5-0062-75ae-d71e-ce819e27c137@gmx.net>
Date: Wed, 05 Oct 2016 14:33:37 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <57F50825020000AC0011D029@gwia2.rz.hs-offenburg.de>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="qTHaijN7MrfAeRHuKdOIjkN8Opmhct94J"
X-Provags-ID: V03:K0:l8X/MMhHP3kOhKuqyfDdCZk2P+wnGGWROwPWrmAk0aTtzFMDUj0 5d0Fcd7aE3OqqxVl6gSdk2UyTRRqDe4BQZaAgC78JNJd8jlxJMwV5KlVSCOVOy2r5fFJ+z6 f/8iya6p2/vUQFJDIZiY6kjEkA57SxA3TikIOhfdjiPu2D5PUcYJnNEw3rYzETO4LPRGRsb bXTGtRdsnvLdazw8OsR6A==
X-UI-Out-Filterresults: notjunk:1;V01:K0:6igHGr43n80=:UkgCsM1zdOlL6uC0CRweVi sLKf86Aa3Jx9wtoTjFI8zt9BxPtTKZukXd8YFYjhRJIRhx9pNdtC60oJpgelFEFfx1gIQVD7A VPquKC5OMlyJcQhcciU0+tWiFvpfppVLUT9+g6F4gEeHSoeL2oyvlImNqDpEH5FFiUP5PeI+4 6C4D1aycDAf9oQCxafxFOPGU/obRBjzH21IF426XKuAnXYRabiYCXRBlQ0LbYbeS1XTLys4oa Lb7/sVX3U6372M8nMut1aUQc7YfGoZ4/Mk4KIlnxABJ1ewczH2tijzm5/OI+2wgL5+mFE5WuE ghH9J4EDNjpMNfzV5iKfPnfViO/Q1RDqWWXZ7NoQkGGZr/xnTzq1/Bx7vrnwK0XAt2EofBPeF 116L0c3cCFqELCSbkPdbe1ne3JpKlIqw78LFlWTekRJLt9yULvWIw8xXW5L+DlL3rqDNO6wu4 CAW+DOYuYgg5EQjQqsMb/J8zK92pmIqm4NZkgVc52MAhUfcM9f30ZeNsqfTh/wgAqvbfXveuX Qy5tRNOPwFTi7+MO2evdiFlOxseThlSLbGeFhvlcnEa0ZQGV2Ts3SpqjIu5XokdRbCtmrSUZq MCu6BEFmnPIEsJrTRvGpDu1N1TFUf4NAXdPb+OebI342fsgJlj0SFz6PBP8CyL+nYiUB6da4X yy68Gb6djFwefYZFYjy3ZGrbUSC03LObJvB4hwkDslycpYNzbVAgxBo9Or7FSLCUhHuk6kgf/ KWPtQm72K9M9OFZhqqVGwzLm1M4ufQp11SNLVyYw77UlLwIQY46rAIAltmE=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/s0wFNZx4KIYuHv3VN4_S16mJUv8>
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:33:58 -0000
Hi Andreas, I am not sure that people ignore the redundant length fields on purpose. I think that the strange syntax that TLS uses invites these types of mistakes and I had run into those myself as well. Ciao Hannes On 10/05/2016 02:03 PM, Andreas Walz wrote: > 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 23 Ticket Extension type 35 > 01 00 Length of extension contents (ticket) > FF FF .. .. Actual ticket > > > Best regards, > olivier > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > _______________________________________________ > 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