IETF Logo Mail Archive

Re: [TLS] DTLS 1.3

Nikos Mavrogiannopoulos <nmav@redhat.com> Fri, 08 July 2016 09:06 UTC

Return-Path: <nmav@redhat.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 0528A12B04E for <tls@ietfa.amsl.com>; Fri, 8 Jul 2016 02:06:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.842
X-Spam-Level:
X-Spam-Status: No, score=-6.842 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] 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 6aiWhCFDyeYl for <tls@ietfa.amsl.com>; Fri, 8 Jul 2016 02:05:57 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9D7012B04D for <tls@ietf.org>; Fri, 8 Jul 2016 02:05:57 -0700 (PDT)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id ED72A720BD; Fri, 8 Jul 2016 09:05:55 +0000 (UTC)
Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.3.63]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u6895rBJ031951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 8 Jul 2016 05:05:55 -0400
Message-ID: <1467968753.3009.11.camel@redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: "Fossati, Thomas (Nokia - GB)" <thomas.fossati@nokia.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Date: Fri, 08 Jul 2016 11:05:53 +0200
In-Reply-To: <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> <D3A52886.6C06E%thomas.fossati@alcatel-lucent.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Fri, 08 Jul 2016 09:05:56 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/fjrzP7p6yJZ2LinYH8hE_5yKK04>
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:00 -0000

On Fri, 2016-07-08 at 08:59 +0000, Fossati, Thomas (Nokia - GB) wrote:

> > 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?

No, my question is much simpler. How would a server handling for
example 20000 clients, will figure to which chain a hash of H(x)
belongs to? Will it have to iterate through all the chains (client
states) and test for matching or there is something more clever than
that?

regards,
Nikos

v2.23.0 | Report a Bug | By Email