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

Ilari Liusvaara <> Wed, 26 September 2018 19:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 74A0812872C for <>; Wed, 26 Sep 2018 12:29:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MMe8yrVsWoQ6 for <>; Wed, 26 Sep 2018 12:29:23 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 09B5F1274D0 for <>; Wed, 26 Sep 2018 12:29:22 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2B2A93A4DC; Wed, 26 Sep 2018 22:29:19 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id 1966SN02JuR8; Wed, 26 Sep 2018 22:29:18 +0300 (EEST)
Received: from LK-Perkele-VII ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id A791C28B; Wed, 26 Sep 2018 22:29:16 +0300 (EEST)
Date: Wed, 26 Sep 2018 22:29:16 +0300
From: Ilari Liusvaara <>
To: Mounira Msahli <>
Cc: tls <>
Message-ID: <20180926192916.GA31766@LK-Perkele-VII>
References: <> <20180827163405.GA19628@LK-Perkele-VII> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <>
Subject: Re: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 26 Sep 2018 19:29:25 -0000

On Wed, Sep 26, 2018 at 05:57:28PM +0200, Mounira Msahli wrote:
> Hi all, 
> Please find attached a new version of the draft. We took account of
> pevious TLS group comments.  William, editor of 1609.2, proposes to
> add the section certificate verify (section 4.3 in the draft). 
> It concerns the addition of IEEE 1609.2 signature for the the 
> ertificate verify. 

I took a brief look. The CertificateVerify changes look suspect:

- The construction looks like it mixes different kinds of structures:
  1609.2 Data of type signed versus TLS 1.3 signature. I do not think
  this is cryptographically kosher. In fact, I think the call for
  "extreme care" for certain kinds of modifications from TLS 1.3
  specification appiles here.

  That is, with 1609.2 what is passed to actual raw signature is not 
  TLS 1.3 signature structure, nor something compatible with it
  (the invariant part with dedicated context is only up to and
  including the zero separator). However, I do not think that
  changing the context and then hacking what comes afterwards
  (altough it seems cryptographically kosher) is a good idea for
  implemntation reasons.

- Bleh: Hardcoding SHA-256 in place that requires a strong hash. One
  more place to mind if SHA-256 someday breaks. The hash looks
  extraneous too, as what needs to be signed is not long.

- Changing CV format with certificate format could create problems with
  existing TLS implmentations, as there is no precendent for such
  change. In fact, there even isn't an extension that changes that
  (and such extension would require very careful analysis). And
  what about TLS 1.2, which does not use CV for server side, and has
  different format CV for client side?

- Nasty hack for psid that would not be crypographically questionable
  would be to throw it inside first certificate entry (just leave
  the overall entry length as 3 bytes to avoid trouble with certificate
  message parsing). 

- The timestamp looks very questionable. What is it for? What if the
  generating clock is wrong (clocks are wrong depressingly often)? It
  seems that TLS exchanges are occuring "now" from viewpoint of the