IETF Logo Mail Archive

[TLS] extending the un-authenticated DTLS header

Nikos Mavrogiannopoulos <nmav@redhat.com> Mon, 14 November 2016 12:58 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 52BEC129522 for <tls@ietfa.amsl.com>; Mon, 14 Nov 2016 04:58:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.419
X-Spam-Level:
X-Spam-Status: No, score=-8.419 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.497, SPF_HELO_PASS=-0.001, 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 vttxrLfJU3_d for <tls@ietfa.amsl.com>; Mon, 14 Nov 2016 04:58:37 -0800 (PST)
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 BC61C12940A for <tls@ietf.org>; Mon, 14 Nov 2016 04:58:37 -0800 (PST)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (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 6FBEDF806B; Mon, 14 Nov 2016 12:58:37 +0000 (UTC)
Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.3.106]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uAECwZK8002174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 14 Nov 2016 07:58:36 -0500
Message-ID: <1479128315.2624.62.camel@redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: "tls@ietf.org" <tls@ietf.org>
Date: Mon, 14 Nov 2016 13:58:35 +0100
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.26
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Mon, 14 Nov 2016 12:58:37 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/hEQ-xqaAoSSNA1Q3PVfk-q3lCOs>
Cc: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Subject: [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: Mon, 14 Nov 2016 12:58:41 -0000

Hi,
 For draft‐mavrogiannopoulos­‐dtls­‐cid­‐00 and we needed to extend the
DTLS un-authenticated part of the DTLS record header with an additional
field. That works well if this is the only draft ever extending the
DTLS record header. If not, modification order would be undefined.

Would it make sense to introduce an extension header for DTLS 1.3 in
the lines of the IPv6 extension headers? That would allow TLS extension
negotiation to add more items on the un-authenticated header, and
potentially also remove redundant headers. 

What do you think?

regards,
Nikos

v2.23.0 | Report a Bug | By Email