Subject: [TLS] draft-ietf-tls-extractor-05 WGLC comments

From: Alfred Hönes <[email-masked]>
Date: Wed, 11 Mar 2009 13:00:29 +0100 (MEZ)

Hello,

First of all, I want to confirm that most of the changes I had
proposed in the past now have been incorportated into the most
recent 'TLS extractor' draft version, draft-ietf-tls-extractor-05.

An iterated review unveiled the following flaws left in / added newly:

(1)  collateral damage of change in term "extractor" --> "exporter"

There's a linguistical problem with the 1:1 replacement performed.

For "extractor", the active entity is the recipient, for "exporter",
the active part is the one giving something away.

Therefore, the schematic replacement has caused a few semantical
contortions of the text that should be corrected, to avoid confusion.

In sentences stated originally with 'the application' in mind as the
active role, it might be better to now talk about "import" in order
to give back the active role to the application entity, or change the
sentence otherwise, giving the active role to TLS/DTLS when using
"export".

Also, typical use is (and was in the draft)   "extract _from_" ; for
the 'economical picture', it is  "export by/to" or "import to/from".

To correct the semantics in an unambiguous way, I suggest to apply
at least the following two textual changes:

(1a)  Section 3, 1st paragraph

OLD:
                  vvvvvvvvv                  vvvvvvvvvvvvvv
|  In addition to exporting keying material, an application using the
   keying material has to securely establish the upper-layer context
   where the keying material will be used.  [...]

As mentioned above, the _application_ does not 'export' the keying
material, as alluded by this sentence, which would be clearly
forbidden for security reasons (binding the secret to the
application context).  Thus, it would be much preferable to say:

NEW:
                  vv
|  In addition to importing keying material, an application using the
   keying material has to securely establish the upper-layer context
   where the keying material will be used.  [...]

(1b)   Section 3, last bullet

OLD:

   o  The upper-layer protocol can include its own handshake which can
|     be protected using the keys exported from TLS.
                                  ^^^^^^^^
NEW:

   o  The upper-layer protocol can include its own handshake which can
|     be protected using the keys imported from TLS.
                                  ^^

(2)  Nits

(2a)  Section 3, 1st paragraph, last sentence

s/At minimum,/At a minimum,/   (or use "At least").

(2b)  Section 6, last paragraph

In the prose:  s/RF5226/RFC 5226/ .

(3)  Section 4

It looks like an important clause has been dropped inadvertantly after
the first paragraph, making the flow of reasoning unintelligible.

OLD:

   The output of the exporter is intended to be used in a single scope,
   which is associated with the TLS session, the label, and the context
   value.
|
   o  A disambiguating label string
   o  A per-association context value provided by the application using
      the exporter
   o  A length value

!  It then computes:

   [...]

The "then" does not make sense any more, because the indication of
what happens with the items in the 3 bullets has been lost.
I suggest to restore the clause from earlier draft versions,
with the appropriate change in terminology applied,
and modify the punctuation and capitalization within the bullets:

NEW:

   The output of the exporter is intended to be used in a single scope,
   which is associated with the TLS session, the label, and the context
   value.
|
|  The exporter takes three input values:
|
|  o  a disambiguating label string,
   o  a per-association context value provided by the application using
|     the exporter, and
|  o  a length value.

   It then computes:

   [...]

(4)  Section 6

(4a)
As discussed off-list in the past, the label "master secret"
contained in the list of initial registrations plays a specific
role.  It is *not* intended to be used by the mechanism described
in the draft; it has been entered for the sole purpose to avoid
registering this value in the future and thereby causing possible
confusion with the unrelated use of that string in RFC 5246.

Note: The algorithm in Section 3 starts with the master_secret,
  but in contrast, the algorithm in RFC 5246 making use of the
  label "master secret" does so in constructing the master_secret
  (from the premaster secret).

Thus, the role of the entry for "master secret" is quite different
than the other entries; it it NOT to be used with a formula like the
one given in Section 3; thus, this is in fact a _reserved_ entry.

The label "key expansion" is used in RFC 5246 (section 6.3) in a
formula closely resembling the formula in setcion 3 of the draft,
but without the 'context related components.
Hence, this label needs to be protected to avoid possible confusion,
and the entry is to be regarded as a _reserved_ entry as well, not
for actual use according to section 3 of the draft.

The other labels from RFC 5246, "client finished" and "server finished",
are not used in any way for keying material derivation and are to be
reserved as well.

To make that fully clear to readers of the document and the (future)
IANA registry, I suggest to amend the table by a note indicating that.

(4b)
Furthermore, RFC 2716 has been Obsoleted by RFC 5216; the Reference
in the table should be changed accordingly.  Section 8 anyway does not
contain an entry '[RFC2716]' ; an entry for RFC 5216 should be added.

(4c)
Taking (4a) and (4b) together, I suggest to change, including some
small facelifting to the table heading:

OLD:

|     Value                          Reference
|     -----                          ------------
|     client finished                [RFC5246]
|     server finished                [RFC5246]
|     master secret                  [RFC5246]
|     key expansion                  [RFC5246]
|     client EAP encryption          [RFC2716]
      ttls keying material           [RFC5281]
      ttls challenge                 [RFC5281]

NEW:

|     Value                          Reference  Note
|     -----------------------------  ---------  ----
|     client finished                [RFC5246]  (1)
|     server finished                [RFC5246]  (1)
|     master secret                  [RFC5246]  (1)
|     key expansion                  [RFC5246]  (1)
|     client EAP encryption          [RFC5216]
      ttls keying material           [RFC5281]
      ttls challenge                 [RFC5281]
|
|     Note(1): These entries are reserved and MUST NOT be used for
|              the purpose described in RFC XXXX, in order to avoid
|              confusion with similar, but distinct use in RFC 5246.
|
|  [ RFC Editor: Please replace 'XXXX' above by the RFC number assigned
|    to this document and delete this remark. ]

(5)  Section 8.1

As indicated in (4b) above, an entry for RFC 5216 should be added.

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 11 Mar 2009 08:12:04 -0700

At Wed, 11 Mar 2009 13:00:29 +0100 (MEZ),
>    where the keying material will be used.  [...]

Sure.

> |     be protected using the keys imported from TLS.

I prefer "exported by" here, actually.

> s/At minimum,/At a minimum,/   (or use "At least").

Sure.

> In the prose:  s/RF5226/RFC 5226/ .

Sure.

>    o  a per-association context value provided by the application using

Agreed. My bad.

> small facelifting to the table heading:

This seems fine.

> As indicated in (4b) above, an entry for RFC 5216 should be added.

This too.

-Ekr