IETF Logo Mail Archive

Re: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates

Mounira Msahli <mounira.msahli@telecom-paristech.fr> Tue, 28 August 2018 08:14 UTC

Return-Path: <msahli@enst.fr>
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 21449130DC1 for <tls@ietfa.amsl.com>; Tue, 28 Aug 2018 01:14:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=telecom-paristech.fr
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 TKt1Lfsq0zcM for <tls@ietfa.amsl.com>; Tue, 28 Aug 2018 01:14:33 -0700 (PDT)
Received: from zproxy130.enst.fr (zproxy130.enst.fr [IPv6:2001:660:330f:2::c2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 262A9129C6B for <tls@ietf.org>; Tue, 28 Aug 2018 01:14:33 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by zproxy130.enst.fr (Postfix) with ESMTP id 822C7120771; Tue, 28 Aug 2018 10:14:31 +0200 (CEST)
Received: from zproxy130.enst.fr ([IPv6:::1]) by localhost (zproxy130.enst.fr [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id ko_wcGcKy-Zk; Tue, 28 Aug 2018 10:14:30 +0200 (CEST)
Received: from localhost (localhost [IPv6:::1]) by zproxy130.enst.fr (Postfix) with ESMTP id 55A8F120770; Tue, 28 Aug 2018 10:14:30 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.10.3 zproxy130.enst.fr 55A8F120770
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telecom-paristech.fr; s=A6AEC2EE-1106-11E5-B10E-D103FDDA8F2E; t=1535444070; bh=3iBNO1ty/RwC4aUQE29zXgU6C+6uQ/R7sMXQF1fBUQ4=; h=Date:From:To:Message-ID:MIME-Version; b=cN6p64V+RohlrMpSvj14RpWJos3j0LFX7Tgcr1LWEHJl+KfgNTCyESBnazCeycMXr AX8/bgnkPR3bBrrxTl2NMy+t5A0I4oSahe+zjqmnPfDyS3r03ab4OYXrQTg7bBu4Sl 5j3MdLXa9lWmUlIVitgipqS2zul4Jl+s1IPhnypg=
X-Virus-Scanned: amavisd-new at zproxy130.enst.fr
Received: from zproxy130.enst.fr ([IPv6:::1]) by localhost (zproxy130.enst.fr [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id T-B4eCUUOtO7; Tue, 28 Aug 2018 10:14:30 +0200 (CEST)
Received: from zmail112.enst.fr (zmail112.enst.fr [137.194.2.205]) by zproxy130.enst.fr (Postfix) with ESMTP id 18A43120771; Tue, 28 Aug 2018 10:14:30 +0200 (CEST)
Date: Tue, 28 Aug 2018 10:14:29 +0200
From: Mounira Msahli <mounira.msahli@telecom-paristech.fr>
To: Hubert Kario <hkario@redhat.com>
Cc: tls <tls@ietf.org>, Ilari Liusvaara <ilariliusvaara@welho.com>
Message-ID: <820448498.714156.1535444069960.JavaMail.zimbra@enst.fr>
In-Reply-To: <6170599.o3dyPvx8Gh@pintsize.usersys.redhat.com>
References: <1231917830.3727154.1535119783361.JavaMail.zimbra@enst.fr> <20180827163405.GA19628@LK-Perkele-VII> <235113009.594519.1535390674699.JavaMail.zimbra@enst.fr> <6170599.o3dyPvx8Gh@pintsize.usersys.redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: [2001:660:330f:cc:f9c7:bf8d:8c3b:8542]
X-Mailer: Zimbra 8.8.9_GA_3019 (ZimbraWebClient - FF61 (Linux)/8.8.9_GA_3019)
Thread-Topic: TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates
Thread-Index: 34tCbl3dqt+HJChBWGoQu9V0xufUTg==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/AJLgY_JHaCfBYuPqKeCp3rtg8qE>
Subject: Re: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.27
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, 28 Aug 2018 08:14:35 -0000

the draft doesn't change the order of messages, doesn't add new messages and 
doesn't change the place in which the relevant extensions are placed – so, 
what is the utility of duplicating the message flow from the TLS RFCs? 

>>>  The extension could be specified as RFC 7250 
>>> For the extension, TLS Client and Server Handshake Behavior shall be specified for two TLS versions.

Kind Regards 
Mounira 

----- Mail original -----
De: "Hubert Kario" redhat.com>
À: "tls" <tls@ietf.org>
Cc: "Mounira Msahli" , "Ilari Liusvaara" com>
Envoyé: Lundi 27 Août 2018 19:39:12
Objet: Re: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates

On Monday, 27 August 2018 19:24:34 CEST Mounira Msahli wrote: 
> One could abbrevate the handshake traces to just show the relevant 
> parts (which could also cut some clutter)? I think the relevant 
> messages always occur in the same order (clienthello, serverhello/ 
> encryptedextensions, certificate, certificate). 

the draft doesn't change the order of messages, doesn't add new messages and 
doesn't change the place in which the relevant extensions are placed – so, 
what is the utility of duplicating the message flow from the TLS RFCs? 

e.g. RFC 8449 and RFC 7685 don't, and they did define new extensions 

> The table in section 4.2. Extensions of [RFC 8446] (TLS 1.3) indicates the 
> messages where a given extension may 
> appear: 
> | client_certificate_type [RFC7250] | CH, EE | 
> | 
> | server_certificate_type [RFC7250] | CH, EE | 
> 
> But in RFC 7250 (TLS 1.2), the same extensions could appear in CH and SH. 

correct, this RFC 8446 table applies only to connections that negotiated TLS 
1.3 

-- 
Regards, 
Hubert Kario 
Senior Quality Engineer, QE BaseOS Security team 
Web: www.cz.redhat.com 
Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic

v2.23.0 | Report a Bug | By Email