IETF Logo Mail Archive

Re: [TLS] DTLS 1.3

"Fossati, Thomas (Nokia - GB)" <thomas.fossati@nokia.com> Fri, 08 July 2016 09:06 UTC

Return-Path: <thomas.fossati@nokia.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 A9BDD12D52D for <tls@ietfa.amsl.com>; Fri, 8 Jul 2016 02:06:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.396
X-Spam-Level:
X-Spam-Status: No, score=-5.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] 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 5u9DsAsq6Z0n for <tls@ietfa.amsl.com>; Fri, 8 Jul 2016 02:06:12 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 4D98712D54C for <tls@ietf.org>; Fri, 8 Jul 2016 01:59:19 -0700 (PDT)
Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 7F05CB285D48F; Fri, 8 Jul 2016 08:59:15 +0000 (GMT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u688xHDp012241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Jul 2016 08:59:17 GMT
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u688xGk7017727 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Jul 2016 10:59:16 +0200
Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.136]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Fri, 8 Jul 2016 10:59:16 +0200
From: "Fossati, Thomas (Nokia - GB)" <thomas.fossati@nokia.com>
To: Nikos Mavrogiannopoulos <nmav@redhat.com>, "Fossati, Thomas (Nokia - GB)" <thomas.fossati@nokia.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Thread-Topic: [TLS] DTLS 1.3
Thread-Index: AQHR1sQr+VI2HyMN6kSrh/Fh10M/0KAJwrEAgAK9LICAABd0AIAAJdUAgAABJwCAAWqLgP//8e2AgAAU6gA=
Date: Fri, 08 Jul 2016 08:59:15 +0000
Message-ID: <D3A52886.6C06E%thomas.fossati@alcatel-lucent.com>
References: <577A38A2.2090209@gmx.net> <17444145.2646138.1467662059329.JavaMail.zimbra@redhat.com> <577AD00E.1000103@cs.tcd.ie> <367617282.2740434.1467726582647.JavaMail.zimbra@redhat.com> <577BC302.5050000@cs.tcd.ie> <1467879217.3426.17.camel@redhat.com> <577E22DE.2060805@cs.tcd.ie> <1467892378.3426.41.camel@redhat.com> <577E4392.6060408@cs.tcd.ie> <D3A51FC1.6C049%thomas.fossati@alcatel-lucent.com> <1467967459.3009.7.camel@redhat.com>
In-Reply-To: <1467967459.3009.7.camel@redhat.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.5.160527
x-originating-ip: [135.239.27.41]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <6208607B76A8394A9550085155EDD736@exchange.lucent.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/mWpVKrPrncQYUc1CnW9xgkvEl1E>
Cc: tls <tls@ietf.org>
Subject: Re: [TLS] DTLS 1.3
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: Fri, 08 Jul 2016 09:06:14 -0000

Hi Nikos,

On 08/07/2016 09:44, "Nikos Mavrogiannopoulos" <nmav@redhat.com> wrote:
>On Fri, 2016-07-08 at 08:34 +0000, Fossati, Thomas (Nokia - GB) wrote:
>> Hi Nikos, Stephen,
>> 
>> It seems to me that both your views (high resistance to traceability
>> and
>> low resource investment on server side) can be accommodated in a
>> single scheme.
>> Going back to the hash chain proposal that Stephen did a few emails
>> ago on
>> this same thread. If:
>> 1. the length of the hash chain is the shortest between the lengths
>> each
>> peer proposes, and
>
>Hi,
> How would the hash chain matching work for a server handling multiple
>clients?

Sorry, I'm not sure I understand the question.  Are you asking what
happens if there is an Id collision between two separate hash chains?  If
so, in general the nature of the keyed hash used to produce the chain
would help keeping the number of collisions low.  In case an Id is a dup,
the server can spot the condition and signal it back to the client.

Cheers, t

v2.23.0 | Report a Bug | By Email