Keying Material Exporters for Transport Layer Security (TLS)
draft-ietf-tls-extractor-07

[Ballot comment]
I've vote Yes on this document, as I believe it is very important.

However I have a couple minor comments and would like to see an email response to them and/or RFC Editor notes:

1). In Section 4 and similar text in Section 6:

  Labels here have the same definition as in TLS, i.e., an ASCII string
  with no terminating NULL.

Ideally I would like to see ABNF here.
But anyway, did you mean: any CHAR character which is not a CTL:

  CHAR          =  %x01-7F
                    ; any 7-bit US-ASCII character,
                    ; excluding NUL

  CTL            =  %x00-1F / %x7F
                    ; controls

(as defined in in Appendix B.1 of RFC 5234)?

[Ballot discuss]
This is an excellent document and I will vote Yes. However, before
this I would like to discuss one issue. I think this is just an
oversight and you actually intended to be stricter here. Section 3
says:

  This specification does not mandate a single mechanism for agreeing
  on such context; instead, there are several possibilities that can be
  used (and can complement each other).  For example:

  o  One important part of the context -- which application will use
      the exported keys -- is given by the disambiguating label string
      (see Section 4).
  o  ...

However, I believe that using distinct distinguishing labels is actually
central to the security of this mechanism. When I read the rest of the
document, this seemed to be the intention, but AFAICT it was never
explicitly stated. The above text excerpt appears to say that the
label is just one of the example ways. May I suggest the following
formulation:

  This specification does not mandate a single mechanism for agreeing
  on such context; instead, there are several possibilities that can be
  used (and can complement each other).  For example:

  o  ... all the examples except the first one ...

  No matter how the context is agreed, it is required that it has one
  part that indicates which application will use the exported keys.
  This part is the disambiguating label string (see Section 4).

[Ballot comment]
I've vote Yes on this document, as I believe it is very important.

However I have a couple minor comments and would like to see an email response to them and/or RFC Editor notes:

1). In Section 4 and similar text in Section 6:

  Labels here have the same definition as in TLS, i.e., an ASCII string
  with no terminating NULL.

Ideally I would like to see ABNF here.
But anyway, did you mean: any CHAR character which is not a CTL:

  CHAR          =  %x01-7F
                    ; any 7-bit US-ASCII character,
                    ; excluding NUL

  CTL            =  %x00-1F / %x7F
                    ; controls

(as defined in in Appendix B.1 of RFC 5234)?

2). In Section 4:

  The context value allows the application using the exporter to mix
  its own data with the TLS PRF for the exporter output.  One example
  of where this might be useful is an authentication setting where the
  client credentials are valid for more than one identity; the context
  value could then be used to mix the expected identity into the keying
  material, thus preventing substitution attacks.  The context value
  length is encoded as an unsigned 16-bit quantity (uint16)

I think a reference to Section 4.4 of RFC 5246 would help a reader
who is not active in the TLS WG.

  representing the length of the context value.

IANA comments:

Upon approval of this document, IANA will create the following
registry at http://www.iana.org/assignments/TBD

Registry Name: TLS Exporter Label
Registration Procedures: Specification Required

Note: The value label is a string consisting of printable ASCII
characters. IANA MUST also verify that one value label is not a
prefix of any other value label. For example, labels "key" or
"master secretary" are forbidden.

Initial contents of this registry will be:

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]


We understand the above to be the only IANA Action for this document.

Posted related IPR disclosure: Certicom's Statement about IPR related to draft-ietf-tls-rfc4347-bis, draft-rescorla-tls-suiteb, draft-ietf-tls-extractor, draft-green-secsh-ecc, draft-ietf-avt-dtls-srtp, draft-igoe-secsh-suiteb, draft-ietf-smime-3851bis, draft-ietf-smime-3850bis, dra...

Posted related IPR disclosure: Certicom's Statement about IPR related to draft-ietf-smime-3278bis, draft-ietf-smime-sha2, draft-ietf-smime-multisig, draft-ietf-smime-3850bis, draft-ietf-smime-3851bis, draft-igoe-secsh-suiteb, draft-ietf-avt-dtls-srtp, draft-green-secsh-ecc, draft-ie...

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

I, Joe Salowey, co-chair of the TLS working group, am the Document
Shepard for draft-ietf-tls-extractor-05. I have reviewed the document
and I believe it is ready for forwarding to the IESG for publication.


(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The document has been reviewed by key working group members that
understand TLS. The document has also been reviewed by members of the
cryptographic community that are experts in key derivation.


(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

The document deals with cryptography and has had cryptographic review.


(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or

has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

The document shepherd has no concerns with the document. There is an
IPR disclosure that lists this document:
https://datatracker.ietf.org/ipr/1004/. There has been some discussion
of this disclosure on the TLS list. In general the disclosure only
discusses the use of the draft with ECC technology. Some members are
worried that this leaves a loop hole for later assertions to be made by
the owner of the #1004 disclosure or that another third party may try to
assert claims. No new evidence about these existence of additional
claims has been provided to the working group so the document shepherd
has decided to move forward with progressing the draft on standards
track. In addition the submitters of the IPR disclosure have clarified
their position on the list.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

The consensus behind this document is strong with decent support and
participation from the working group.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme

discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

There are a few nits with respect to references in the document. There
is also one instance of "MUST not" that should be replaced by "MUST
NOT".


(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

The Document has split references. In the current version some of the
references are out of date or missing. A informative reference to RFC
5216 should be added in place of 2716. The reference to RFC 5281 should
be informative. The reference to the DTLS-SRTP draft should be
rectified in the text.


(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

Yes

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

Yes

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary

A number of protocols wish to leverage Transport Layer Security (TLS) to
perform key establishment but then use some of the keying material for
their own purposes. This document describes a general mechanism for
allowing that.


Working Group Summary

There was significant consensus in the working group supporting this
document. The largest controversy was over the name.

Document Quality

The approach is planned for use in several protocols. The document has
been reviewed by cryptographers who are experts in the area of key
derivation.

Posted related IPR disclosure: Certicom's Statement about IPR related to RFC 4346, RFC 5246, RFC 5289, RFC 4492, RFC 2409, RFC 4306, RFC 4754, RFC 4753, RFC 4869, RFC 4253, RFC 2633, RFC 3278, RFC 4347, RFC 4366, RFC 4109, RFC 4252, RFC 3850, RFC 3851, RFC 5008, draft-ietf-tls-rfc43...