Re: [TLS] [ALU] Re: extending the un-authenticated DTLS header

"Kraus Achim (INST/ESY1)" <Achim.Kraus@bosch-si.com> Wed, 16 November 2016 10:21 UTC

Return-Path: <Achim.Kraus@bosch-si.com>
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 047391296F3 for <tls@ietfa.amsl.com>; Wed, 16 Nov 2016 02:21:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 rmFyNiQk_yz1 for <tls@ietfa.amsl.com>; Wed, 16 Nov 2016 02:21:14 -0800 (PST)
Received: from smtp6-v.fe.bosch.de (smtp6-v.fe.bosch.de [IPv6:2a03:cc00:ff0:100::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2DD0129537 for <tls@ietf.org>; Wed, 16 Nov 2016 02:21:13 -0800 (PST)
Received: from vsmta14.fe.internet.bosch.com (unknown [10.4.98.54]) by imta24.fe.bosch.de (Postfix) with ESMTP id EDEBCD801DB for <tls@ietf.org>; Wed, 16 Nov 2016 11:21:10 +0100 (CET)
Received: from imbvw2exc01.bosch-si.com (vsgw23.fe.internet.bosch.com [10.4.98.23]) by vsmta14.fe.internet.bosch.com (Postfix) with ESMTP id 66C2EA40CAE for <tls@ietf.org>; Wed, 16 Nov 2016 11:21:10 +0100 (CET)
Received: from IMBPW2EXD01.bosch-si.com ([fe80::d052:f355:928e:e5ba]) by imbvw2exc01.bosch-si.com ([::1]) with mapi id 14.03.0319.002; Wed, 16 Nov 2016 11:21:41 +0100
From: "Kraus Achim (INST/ESY1)" <Achim.Kraus@bosch-si.com>
To: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] [ALU] Re: extending the un-authenticated DTLS header
Thread-Index: AQHSPw8nFDjstdrZ902zFk9/+RE1u6DbZUXA
Date: Wed, 16 Nov 2016 10:21:41 +0000
Message-ID: <BC36447FF5C62E46BEF3F124D3C1E8925E201730@imbpw2exd01.bosch-si.com>
References: <1479128315.2624.62.camel@redhat.com> <058f1681-9ecf-22db-1b88-2313491c7b72@cs.tcd.ie> <CABcZeBNGFGx60gjp41YV8a9G0GOPfbdhAQuzqpBrFjRq6WnogA@mail.gmail.com> <CABkgnnU=7tn3Y9JUsW7YtiKyCWMN0OF0HLT+JRJ817UYNcCeoQ@mail.gmail.com> <D450640D.75E17%thomas.fossati@alcatel-lucent.com>
In-Reply-To: <D450640D.75E17%thomas.fossati@alcatel-lucent.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.22.83.125]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22700.006
X-TMASE-MatchedRID: qo4kGEUleplLfdwP+8LWGxmiTJb38WRepfVcx39Kq+4wFVxto+mLMHkp Nl+k3Px70i41U+l4JIhPqT/xzbGJfWTFilzGBdRxqJst3mlmdq4YlE/kjooKo7J3rmpkUU+TWU4 PVaxZEWP+cTYjc30iLS83Rst4LUB+mNrlAIQG7r/bNDWQseUeZcmZx4YdgiXB/9WTKGBWZFOoAb qESdJED3si3gD9jR5He4C1EulbDB1CMOF2vSwLTPHkpkyUphL9IcCiCHZJTlep7t/yrVnxkCZ9x AZfX8Ihakml/g8mox3DBBlXSY941TItqiewRFZO8lHxQZgd6ADNbZoHWAcdk1pbYq2f4jz+WbzY 4GA2m4u4f1A2F1rkO7Bdb9rysz6qW9DaXGhRJeDwtZfBooJ6awuK1hIitSIH51ONI4UL++qjxYy RBa/qJSw7AP50bcPJQs9S/5dKsKXdB/CxWTRRuyUIayx+Skid
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/l8c-Zs8uC_VwlVEreQBAJ41Nvn0>
Subject: Re: [TLS] [ALU] Re: extending the un-authenticated DTLS header
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, 16 Nov 2016 10:21:17 -0000

Hi,

I'm still wondering, why the "clashing" calculations (section 4) are only based on the number of clients and not also on the length of the hash chain.
As I understood the hash chain, the DTLS server and client calculates a list of CIDs. Though the client chose one, the server has to prepare for the (left) list of CIDs. So even assuming that in average half of the list is already used, I think the length of that list has influence on the clashing.

Mit freundlichen Grüßen / Best regards

Achim Kraus

Bosch Software Innovations GmbH
Communications (INST/ESY1)
Stuttgarter Straße 130
71332 Waiblingen
GERMANY
www.bosch-si.de
www.blog.bosch-si.com 

Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B
Executives: Dr.-Ing. Rainer Kallenbach; Michael Hahn



-----Ursprüngliche Nachricht-----
Von: TLS [mailto:tls-bounces@ietf.org] Im Auftrag von Fossati, Thomas (Nokia - GB)
Gesendet: Dienstag, 15. November 2016 08:08
An: Martin Thomson <martin.thomson@gmail.com>; Eric Rescorla <ekr@rtfm.com>
Cc: Hannes Tschofenig <Hannes.Tschofenig@arm.com>; tls@ietf.org
Betreff: Re: [TLS] [ALU] Re: extending the un-authenticated DTLS header

On 15/11/2016 03:51, "TLS on behalf of Martin Thomson"
<tls-bounces@ietf.org on behalf of martin.thomson@gmail.com> wrote:
>On 15 November 2016 at 10:16, Eric Rescorla <ekr@rtfm.com> wrote:
>>> I'd be interested in an analysis of the potential privacy impacts of 
>>> this. Isn't this more or less the same as doing SPUD-for-DTLS? (If 
>>> not, sorry for dragging in controversy:-)
>>
>>
>> It would no doubt depend what you put there.
>
>Which is why I'm interested in seeing Nikos' (unpublished?) draft.

Published:
https://tools.ietf.org/html/draft-mavrogiannopoulos-tls-cid-00


Working copy:
https://thomas-fossati.github.io/draft-tls-cid/

Slides for today, "DTLS Optimizations for IoT Deployments":
https://www.ietf.org/proceedings/97/slides/slides-97-tls-dtls-optimizations
-for-iot-deployments-00.pptx

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls