IETF Logo Mail Archive

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

Martin Thomson <martin.thomson@gmail.com> Tue, 15 November 2016 09:10 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 8E8B91295EC for <tls@ietfa.amsl.com>; Tue, 15 Nov 2016 01:10:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, 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 C6-d0bl2By-E for <tls@ietfa.amsl.com>; Tue, 15 Nov 2016 01:10:06 -0800 (PST)
Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 CB8A5129450 for <tls@ietf.org>; Tue, 15 Nov 2016 01:10:05 -0800 (PST)
Received: by mail-qt0-x229.google.com with SMTP id w33so64195922qtc.3 for <tls@ietf.org>; Tue, 15 Nov 2016 01:10: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=vXA+wdJ/30q3WtOHIdNRWku7xRtjtZdBrGaJtVHQ9pI=; b=YSvYB2psmb9x0qg4SSCyhN3uZj4npmDai+3FifVb8HWG9FY9DY//5G3jH7tW9YHxWe SpasUGmpKD0fdbCGxcocnltTnBespHBBHeYD7v2nU6jWArDe/JTQ5jyHsHtC6WgdbSEt vXllwXNqCZ+1KY5hRhljBVbSI4ekUo0A2PQDUihK+FUW/+iER2G0kNpcp6w56f/nm1FR 8cw/1TDi71vVYqkr/BCRrAlKB7glTnmrzTCr3vfF1Tml2XeIOIcK8u142sgtpu3PkbIq AF8D4BqrI2N94K1xSOg0NL6Eog27JXeGMIz8AK1s94HQr0CTpMkEGuWfAarG9gEEL1rx 295Q==
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=vXA+wdJ/30q3WtOHIdNRWku7xRtjtZdBrGaJtVHQ9pI=; b=dhFEga0YhgiNx5GIBQv/6Vo1FFqlCYdps4vNNpoJshM68TTtEHJ/0iOZjwmvId4/hj HW7af1yzYQ6ezGIYWhBgEoUChfyOHimfjP6z9oFp+sT9uru8X72nna6iJGW0IHYzkzsN doVPC06E5O2PniAojlmiViCw5V8Gi9WiGl098KwVeQzU0/2gSzNDc5U7rO40Dwrcqq+O M9Jmys0GW/aYZwGxdKRFVvGtQjIh6wocwApLB0ROXVecBZJoszgeNIZlBxBH/NvBJ0Gd l2IL/EJivU5tkjqcAFVH52IMxd183DjR0eJjSWgMCRWiePDOA/3VPQLfcrWYTAbZLUII 5Frg==
X-Gm-Message-State: ABUngvd+K828TI+t4TTK/vTKA30kQ3fj9WqnOStjBAa2eI0jhnvNpcgVajrc3NgJb3QWCZSsVLj5Q4Fzwn2WFg==
X-Received: by 10.200.44.27 with SMTP id d27mr10551706qta.278.1479201004902; Tue, 15 Nov 2016 01:10:04 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.85.7 with HTTP; Tue, 15 Nov 2016 01:10:04 -0800 (PST)
In-Reply-To: <D4506C55.75E31%thomas.fossati@alcatel-lucent.com>
References: <D4506C55.75E31%thomas.fossati@alcatel-lucent.com>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 15 Nov 2016 18:10:04 +0900
Message-ID: <CABkgnnXUK8e3wHbHSAHV=deryPY6Mfx4Q5PkFd74=KrP=O88ig@mail.gmail.com>
To: "Fossati, Thomas (Nokia - GB)" <thomas.fossati@nokia.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/VgFubQUOphbGIPQdhpXesxsIG-c>
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:10:07 -0000

On 15 November 2016 at 17:34, Fossati, Thomas (Nokia - GB)
<thomas.fossati@nokia.com> wrote:
> The draft proposes two ways to allocate the identifier (see 3rd para of
> https://thomas-fossati.github.io/draft-tls-cid/#rfc.section.1):
> 1. Server decides unilaterally a value that is fixed for the duration of
> the session (SecAssocType.fixed);
> 2. Server and Client agree on a sequence of values generated using HOTP
> [RFC 4226] seeded by the session shared secret (SecAssocType.hotp); Client
> shifts to the next value when needed (e.g. on transport handover).
>
>
> At first this might not look particularly elegant, but there are good
> reasons for having both methods.

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.

v2.23.0 | Report a Bug | By Email