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

[William Whyte <[e-mail]>]

Hi Ilari,

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

You're right, it uses the 1609.2 data structure. The rationale is as
follows:

Software:

Most 1609.2 libraries offer only a high-level API for signing and
verification, where:

On signing: the input is the data, a handle for the key, and a set of
options, and the output is a 1609.2 signed data.

On verification: the input is the Ieee1609Dot2Data output by signing, the
certificate, and some options, and the output is either “valid” or an error
code.

As such, using a 1609Dot2Data in the Signature field doesn’t require any
software changes to 1609.2 libraries. It does require an additional change
to the TLS library, which is to check if a 1609.2 certificate is being used
and if so to send the Signature field to a 1609.2 verification engine
rather than a “raw” ECDSA verification engine, but the TLS library is being
changed anyway and this approach allows the changes to be confined to a
single codebase.

Philosophy:

1609.2 certificates are by intent more tightly coupled to the signing
mechanism than X.509 certificates. 1609.2 specifies consistency between a
certificate and the PDU that it signs in terms of validity period,
(optionally) geographic location, and application permissions (PSID and
SSP), and it would be unfortunate to create a setting in which they can be
less tightly coupled. In particular, since a certificate can contain more
than one PSID, it’s useful to state the PSID which the certificate holder
is intending to assert in a given context. The most natural way to do this
is to use an IEEE1609Dot2Data.

A rationale for continuing to use the raw signature field would be to make
the change to TLS as minimal as possible. This is a reasonable rationale,
but we would argue that allowing the signature format to depend on the
certificate type does not break the TLS model as much as allowing a
different entry point to 1609.2 cryptographic processing breaks the 1609.2
model. Since one or the other has to be changed, and since the TLS
implementation is being changed already, we prefer to keep the changes to
the TLS.

If it would help, we could add this rationale to the Security
Considerations section.

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

1609.2 currently only supports SHA-256 for message hashing -- it's
extensible, in that it has a hash algorithm identifier that can in
principle be extended with additional identifier values, but currently only
SHA-256 is defined for message hashing. The hardcoding of SHA-256 in this
draft should be read as informative text about a constraint that exists
anyway in 1609.2. If 1609.2 is extended to support additional hash
algorithms we'll circle back and change this part of this draft.

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

I accept that this is a valid concern in general and complicates the TLS
signing/verification logic. As described above, we reluctantly decided that
this was a preferable approach to using raw signatures with 1609.2
certificates, because when you're using 1609.2 certificates it's because
you want the tighter binding to owner permissions that you get from 1609.2
and as such it's important to use 1609.2 certificates accompanied by the
1609.2 signed data structure. I don't think this is a direct security
concern, but I acknowledge that the additional complexity in TLS
implementations is regrettable.

>> And
  what about TLS 1.2, which does not use CV for server side, and has
  different format CV for client side?

I'll be honest, when I drafted this part of the document I was thinking
only about TLS 1.3. I don't have a strong feeling that 1609.2 certificates
should be usable in TLS 1.2. We'd be happy to take guidance about how this
could be integrated into TLS 1.2.

Note re the comment about existing implementations above that if you're
focusing on TLS 1.3, then there are fewer and less well-established
existing implementations than there are with TLS 1.2, so I think the
existing implementations concern is also diminished.

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

Agreed, but also agreed that it's a hack :-)

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

Again, this is a constraint of using the full 1609.2 processing: the 1609.2
verification process requires that a generation time is available so that
the verifier can check that the generation happened during the validity
period of the certificate. Historically, this requirement came in because
1609.2 is in general used to authenticate broadcast messages, and so the
generation time is the only way to guarantee freshness. In the TLS setting,
freshness is guaranteed by the live protocol, so this doesn't add value,
but 1609.2 libraries aren't configurable to turn this check off and
including the generation time isn't a lot of overhead.

The draft doesn't propose that the TLS handshake process makes any use of
the generation time other than the use (which isn't explicitly stated but
is implicit in the use of 1609.2 verification) to ensure the handshake was
valid when generated; in other words, there's no stated requirement for
consistency between the client and server clocks, the requirement is for
consistency between the signer's clock and its use of its own certificate.

Does this make the proposal seem more palatable?

Cheers,

William






On Wed, Sep 26, 2018 at 3:29 PM Ilari Liusvaara <[e-mail]>
wrote:

> 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
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>


-- 


PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS:
[e-mail]