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

[Ilari Liusvaara <[e-mail]>]

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