Subject: [TLS] Working group last call on draft-ietf-tls-extractor-03

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 6 Nov 2008 10:16:06 -0800

This is a working group last call for review of the
draft-ietf-tls-extractor-03.  The last call will last until December 4,
2008, but it would be most useful if comments were received before the
TLS session at the IETF meeting in Minneapolis on November 20, 2008.
This will allow us to discuss issues in the meeting and resolve them in
a timely fashion. 

The document is available here:

http://tools.ietf.org/html/draft-ietf-tls-extractor-03

Thanks,

Joe
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: "Hugo Krawczyk" <[email-masked]>
Date: Thu, 6 Nov 2008 14:45:16 -0500

Hi,

I have a single "objection" to this document, namely, the use of the word
"extractor". Let me explain.

In the context of key derivation functions the notion of extraction refers
to a first phase where one starts with a somewhat weak source of randomness
(such as an imperfect RNG, a Diffie-Hellman value, etc) and extracts a first
cryptographically strong key K.

In a second phase, often called key expansion, one derives multiple keys out
of this K using a PRF exactly as the current document specifies. Since
master_secret is assumed to already be a cryptographically strong key, then
this specification is sound and correct (especially that it includes the
essential context information).

Thus I would like to see the name "extraction" changed into "expansion" or
even "key derivation" to avoid adding confusion in the field.
I would agree that in this application "expansion" may not be the most
representative qualifier so maybe the more genric "key derivation"
terminology could be used. Yet, personally, I would prefer to keep key
derivation for the whole process of extraction and expansion (which
includes, for example, the initial creation of master_secret in TLS plus the
derivation of further keys),

Other names could be possible. I am sure that Eric (or some other people in
the list) can come with creative names.
If not, please use key derivation and not key extraction.

Hugo

PS: I have written a detailed paper on the functionalities of key extraction
and key expansion.
http://www.ee.technion.ac.il/~hugo/kdf/kdf.pdf
The focus of the paper is mainly key extraction since it is the more
challenging part from a technical point of view. For those interested in the
differentiation between "extraction" and "expansion" reading the
introduction may be sufficient. The more theoretically-oriented can find
value in the security definitions in the appendix which  capture, for
example, the security considerations in this draft including the
independence/indistinguishability requirement under different (or even
adversarially-chosen) context labels.

---

From: <[email-masked]>
Date: Wed, 12 Nov 2008 14:14:39 +0200

<not wearing hats>

In general, the document looks good; I have only minor nits:

In Section 4, the context value is shown as "opaque
context<0..2^16-1>" (and Alfred pointed out that it probably should be
"context_value").  Now, if the PRF computation (slightly earlier in
Section 4) uses the normal TLS presentation language notation
(not an unreasonable assumption!), it would mean the length is included 
twice (two uint16). That's probably not the intention (but folks
have been confused about the exact number of length fields before,
and this did cause some interop problems around TLS 1.0 time). My 
suggestion would be just to delete the line "opaque context<0..2^16-1>"; 
it's not really needed, and without it, everything looks umambiguous.

It might be good to explicitly point out that designing a secure
mechanism that uses this extractor is rather difficult, and this
document does not tell how to do it (and IMHO does not need to).
The extractor gives you a key (that's easy), but the difficult part 
is securely agreeing on everything else in the "security assocation" 
or "application context". Although Section 3 gives some ideas on how 
this can be done, it's very far from "here's how you securely use 
this thing" instructions.

Editorial:
- Section 5: "MUST not" -> "MUST NOT" 
- Missing Reference: 'DTLS-SRTP' is mentioned on line 114, but not defined
- Missing Reference: 'RFC2716' is mentioned on line 211, but not defined
- Obsolete undefined reference: RFC 2716 (Obsoleted by RFC 5216)
- Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226)
- Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246)

Best regards,
Pasi

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of ext Joseph Salowey (jsalowey)
> Sent: 06 November, 2008 20:16
> To: [email-masked]
> Subject: [TLS] Working group last call on draft-ietf-tls-extractor-03
>