IETF Logo Mail Archive

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

Martin Thomson <martin.thomson@gmail.com> Tue, 15 November 2016 09:20 UTC

Return-Path: <martin.thomson@gmail.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 CEC0E129A30 for <tls@ietfa.amsl.com>; Tue, 15 Nov 2016 01:20:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Jkz6NH1fDUAV for <tls@ietfa.amsl.com>; Tue, 15 Nov 2016 01:20:05 -0800 (PST)
Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9043F1296CD for <tls@ietf.org>; Tue, 15 Nov 2016 01:20:05 -0800 (PST)
Received: by mail-qk0-x234.google.com with SMTP id n204so127993582qke.2 for <tls@ietf.org>; Tue, 15 Nov 2016 01:20:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=klgvfKCSveQlRGhx0fj8CMXC/jxH8kkmk83TI/bfgGo=; b=hYScunebJHfwV/1i11/LZ13+5t8qA3+oEgOpRnGaaiDkJiRJBBid8wtpqEIsMrVJjb 5B6jBu1vKpy7ra0ZjhZk4ivFlz05aHN6ZceKTj4pdxryJ211qiM3LWaOR//kAh0JnvS/ kR1R6jAJcEunSjoVMk0tK+QYf9A+z/+DFwMqAXrD5eLFO38Fqj02jwgP1k8DYI8olmG9 E8/IISVhmD5Fp5q7OSnO0tTbEmh8HQWRjBJz6gcARMBvkDl5gIQ85DsZEzHw2gClmfn9 nw5NTjHm8LbnLVmvIG9M4qpYrXqDFAEESyrv+Zp+gmK9FcgsqI36WoHN5NkKtqMQRwXU FqiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=klgvfKCSveQlRGhx0fj8CMXC/jxH8kkmk83TI/bfgGo=; b=b+lQBOGTwidxKxU8pvM3h40F4fTihmCgSHf3RP6/COXduwO9nAZ8a81Q7t+dPUmJXs d1MEHgxHbgYDdDya1qQV1WZCiCAw3IsIAGefvTZ6ra0TM4IwJCuLU75QUBHGNdmBj6rd P5L0uGPwJb+YgLPhX1N60mkIH8YOV4VNfaaUgAMeYTpkhjQJ8ykCPadgPfGusQVb519V AcIdd32Uj9lqU7BFqKEZ+kRZiEnce7zq2zwkjT5JRJ+UKCzgBnP+nj3m//DZV0M7fn+i dMVZNw1Y2LjNv3IdiCw0NqlaGGE1z0w4N5yzbCqyBjJnWMXsd8+DIFwG1tpXcXJr+7tQ jZSQ==
X-Gm-Message-State: ABUngvdTjGg8vE+9lCECFovKrYspToUakqv9+raBcr+GT87+VfJbxjjw788C1Jd5wUd2FwmLdHYU/fQjDSGtlw==
X-Received: by 10.55.99.141 with SMTP id x135mr20578382qkb.147.1479201604656; Tue, 15 Nov 2016 01:20:04 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.85.7 with HTTP; Tue, 15 Nov 2016 01:20:04 -0800 (PST)
In-Reply-To: <1479201097.12027.10.camel@redhat.com>
References: <D4506C55.75E31%thomas.fossati@alcatel-lucent.com> <CABkgnnXUK8e3wHbHSAHV=deryPY6Mfx4Q5PkFd74=KrP=O88ig@mail.gmail.com> <1479201097.12027.10.camel@redhat.com>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 15 Nov 2016 18:20:04 +0900
Message-ID: <CABkgnnWWMLDC1Bz==7hoyCv9K5Wd6DE4SBT=iqU5JeLD93Xrdw@mail.gmail.com>
To: Nikos Mavrogiannopoulos <nmav@redhat.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/I9DcP9URQBWB--lVtrjLoA0nAJg>
Cc: Hannes Tschofenig <Hannes.Tschofenig@arm.com>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] 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: Tue, 15 Nov 2016 09:20:07 -0000

On 15 November 2016 at 18:11, Nikos Mavrogiannopoulos <nmav@redhat.com> wrote:
>> I'm not seeing quite enough information here to implement this.  How
>> does a server know which of the many HOTP keys it has are in use?
>> Surely you can't use the same HOTP key with every client.
>
> Not sure I understand the question, but I'd suggest to read the text on
> generating the hotp keys.


OK, I re-read it.  It wasn't particularly clear from the overview.
But you generate the HOTP based on an exporter.  That means that the
server has no control over the contents of the CID, direct or
otherwise.  This means that you can guarantee privacy, but it forces
the server to do an exhaustive search of all of its active connections
(that is, O(N)) when it gets a 5-tuple mismatch.

There are probably designs that don't have this property.  For
instance, the server could propose an identifier or set of
identifiers.  That means that a bad server could willfully break the
privacy property, but it also means that it doesn't have the scaling
issues.

v2.23.0 | Report a Bug | By Email