Subject: [TLS] Working Group Last Call draft-ietf-tls-extractor-05.txt

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 9 Mar 2009 00:02:06 -0700

This announcement is for working group last call on
draft-ietf-tls-extractor-05.txt.  Please send your comments to the list
by Tuesday March 17, 2009.  The previous draft (-04) had some errors
introduced in the editing process.  Please check any comments made
against the previous draft against the new draft and resubmit them if
they are still valid.  The draft and diffs can be found at:

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

Thanks,

Joe

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 09 Mar 2009 10:30:00 +0100

"Joseph Salowey (jsalowey)" <[email-masked]> writes:

> by Tuesday March 17, 2009.

I support publication of this document, but I have a question that I
believe would be useful to address in the document.

Is the construct safe if "context_value" contains confidential
information such as cryptographic keys?  Or, in other words, is there
any risk that the output leaks information about the context_value?

If yes, I suggest adding after this text:

   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 following NEW sentence:

   Another example is if the application wants to strengthen a
   cryptographic key; the context value could then be used to mix in the
   key.

If no, I suggest adding to the Security Considerations:

   The exporter function should not be used to mix information intended
   to be confidential, because the PRF output may leak some information
   about the confidential information.

This relates to discussions in the KRB-WG about how useful the PRFs are
in IETF protocols.  If the TLS Exporter function is not designed to deal
with confidential input, some protocols will need to design its own PRF.
This would be unfortunate, so it would be good to document what
applications we can safely use the TLS Exporter function for.

(Yes, I have some understanding about the answer to this question, but I
think some discussion would be useful now, to possibly avoid some
discussions later when this is published.)

Thanks,
/Simon

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 09 Mar 2009 08:06:56 -0700

At Mon, 09 Mar 2009 10:30:00 +0100,
> any risk that the output leaks information about the context_value?

It should be. It's part of the definition of the PRF that
iot doesn't (unless you know all the other values).

>    cryptographic key; the context value could then be used to mix in the

I would suggest that TLS-PSK would be a more appropriate use here.

But how about we compromise:
"Because the context value is mixed with the master_secret via
the PRF, it is safe to mix confidential information into the
extractor provided that the master_secret will not be known to
the attacker."

-Ekr

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 09 Mar 2009 15:51:57 +0100

> I would suggest that TLS-PSK would be a more appropriate use here.

Hmm.  Yes, sometimes, but not always; think for example where you need
to derive keys from a long term key and from the TLS secret by mixing
them together, and which long term key to use is chosen only after the
TLS handshake (possibly influenced by the application data passed in the
TLS session).

> extractor provided that the master_secret will not be known to

That would be great.

Thanks,
/Simon

---

From: <[email-masked]>
Date: Thu, 12 Mar 2009 18:13:21 +0100

<not wearing hats>

It seems my comments from the previous WG "last" call (for 
revision -03) were somehow missed:
http://www.ietf.org/mail-archive/web/tls/current/msg03037.html

Copying the comments here:

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)

Two new nits:
- Reference RFC5281 should be Informative
- Title of 8.2 should be "Informative References", not "Informational"

Best regards,
Pasi

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 12 Mar 2009 10:53:34 -0700

> http://www.ietf.org/mail-archive/web/tls/current/msg03037.html

They were indeed. Fire the editor!
 
I'll work to incorporate them.

-Ekr

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