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

From: Mounira Msahli <[email-masked]>
Date: Wed, 26 Sep 2018 17:57:28 +0200 (CEST)

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 Certificate verify. 

We are soliciting your feedbacks. 

Regards 
Mounira

----- Mail original -----
De: "Hubert Kario" <[email-masked]>
À: "tls" <[email-masked]>
Cc: "Mounira Msahli" <[email-masked]>, "Ilari Liusvaara" <[email-masked]>
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

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 26 Sep 2018 22:29:16 +0300

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
  endpoints.

-Ilari