Re: [TLS] draft-urien-tls-keygen-00.txt

["Hugo Krawczyk" <hugo at ee.technion.ac.il>]

Pascal asked me to comment on this, especially in regards to Uri's questions.

Let me say that I did not read Pascal's document but I understand it
is based on the KDF scheme I have proposed and thoroughly analyzed in
the paper he cites, so I will respond on that basis.

Please refer to the page
http://www.ee.technion.ac.il/~hugo/kdf/
for details of the proposal, rationale, analysis etc.

As for Uri's questions.

I would have hoped that you would find answers to these questions in
the very detailed rationale in the paper. I suggest you read it
carefully.

The main reason for me to write such a paper is that the KDF subject
is non-trivial (even if it may seem that KDFs should be easy and
straightforward to build) and it raises many questions that one cannot
just answer in an email exchange.

Here are some points where using HMAC instead of the plain hash in
KDFs provides for a (much) better design:

- KDF functionality is a superset of PRF functionality (i.e., a KDF
needs to include the  PRF functionality for key expansion but it also
needs additional properties). Therefore, if one accepts that HMAC is
better as a PRF that a plain hash function such as SHA (and better
than the plain hash with a concatenated key) then the same is
certainly true for KDF which has more stringent requirements than PRF.

- HMAC as a mode of operation for hash functions preserves important
properties of the underlying hash function such as pseudo-randomness
(e.g. PRF), randomness (e.g. "random oracle"), and some important
extraction properties that are central (and crucial) for a good KDF.
Please refer to the paper for a comprehensive list of results on the
relevant cryptographic properties achieved by HMAC (and not by the
plain hash function). In particular, these results quantify the
quality of (pseudo) randomness output by the KDF as a function of the
assumptions on the underlying hash function.

- If you believe that SHA (or any other hash function) behaves as an
ideal random function then you can replace HMAC with the plain hash in
part of the KDF design (but even then you have to be careful, e.g. to
avoid extension attacks). But I do not think we should be in the
"mood" of over-trusting our hash functions. The last years have
reminded us of how shaky these functions can be so it is a prudent
engineering principle (and a sound theoretical methodology) to go for
designs that put as little trust as possible on the hash functions.
HMAC as a MAC and PRF is an example of such prudent methodology. There
is no reason not to apply the same principles to a basic primitive
such as a KDF.

- It is NOT true that you need to assume that the hash function is
"ideally random" to justify its use with HMAC in the KDF context. Much
weaker assumptions suffice for many applications and settings
(including instances of IKE and TLS). The paper explains these issues
in detail (maybe too much detail? :). The plain hash function does not
give you such guarantees. In particular, Merkle-Damgard iteration of
the compression function (e.g., plain SHA) does not preserve
pseudorandom or extraction properties even if the compression function
had them.

- If you follow the methodology of this proposal (what I call the
"extract-then-expand" paradigm), you can replace hash functions with
block ciphers if you prefer to trust those more than hash functions.

- There is no need to wait to see practical breakings of systems to
move to better designs, especially when the better designs have little
(if any) performance penalty (in the case of KDFs the extra block
hashed with HMAC is insignificant performance-wise).  It is enough
with the structural weaknesses and pitfalls presented by ad-hoc
schemes based on plain hash functions, and also discussed at length in
the paper,  to indicate that they are not the best designs we can wish
for.

I will stop here or I will start duplicating the many pages in my
paper (which hopefully is better written, and certainly more complete,
than anything said here).

Hugo

PS: I will be away for several weeks starting next week so I will not
be able to participate in discussions of these issues during that time
(but do not see that as a sign that I agree with everything that is
being said... :)


2008/6/25 Blumenthal, Uri <uri at ll.mit.edu>:
>>  In RFC 4306 (IKEV2) some PRF functions are already HMAC BASED
>
> This does not answer my question. What benefits over SHA does HMAC-SHA
> provide here?
>
> I suggest replacing HMAC-SHA with SHA for KDF, or providing rationale for
> using HMAC construct on top of SHA – and rationale better than "somebody
> else considered it a good idea". Showing how randomness of the output is
> measurably improved, or how an attack against key derivation mechanism is
> foiled by this mechanism could justify extra cost.
>
>
>
> At 21:48 24/06/2008, Blumenthal, Uri wrote:
>
> Content-Language: en
> Content-Type: multipart/alternative; boundary="_000_C486C7E8D23urillmitedu_"
>
> After a brief look, the algorithm seems OK. But why not just use straight
> hash (say SHA) instead of HMAC in key derivation function?
>
> If SHA (or whatever) hash function output possesses random properties –
> what's the advantage of employing HMAC construct? What does it add that
> hasn't been there already?
> If SHA does not produce pseudo-random output – how does HMAC improve the
> situation?
>
> (Yes I'm aware of HMAC advantages for MACing, but this is different. I've
> read < http://www.ee.technion.ac.il/~hugo/kdf/kdf.pdf
> <http://www.ee.technion.ac.il/~hugo/kdf/kdf.pdf> >,  and still am not
> convinced.)
>
>
> On 6/23/08 12:11 PM, "Pascal Urien" <Pascal.Urien at enst.fr
> <Pascal.Urien at enst.htm> > wrote:
>
> Hi All,
>
>   - There is a common point between the two proposals, i.e. use of
> TLS for key generation
>
>   - In draft-ietf-tls-extractor-01.txt the TLS PRF function is used
>   - In draft-urien-tls-keygen-00.txt a separate KDF function is used.
>     Krawczyk, H (one of the HMAC designer) wrote a very interesting
> paper about tthe design of KDF functions
>    "On Extract-then-Expand Key Derivation Functions and an HMAC-based
> KDF", http://www.ee.technion.ac.il/~hugo/kdf/, March 2008
>
>    - The point that is not addressed by
> draft-ietf-tls-extractor-01.txt, is the case for which keys are
> pushed by server and not computed by
>      both parties (client and server)
>
> Pascal
>
>
>
>
> At 14:20 23/06/2008, Simon Josefsson wrote:
>>It is a good idea to use different labels for different key usage.
>>Further, I would consider interactions between your document and the
>>following WG document:
>>
>> http://www.ietf.org/internet-drafts/draft-ietf-tls-extractor-01.txt
>> <http://www.ietf.org/internet-drafts/draft-ietf-tls-extractor-01.txt>
>>
>>You could refer to this for key label discussions.
>>
>>/Simon
>>
>>Pascal Urien <Pascal.Urien at enst.fr <Pascal.Urien at enst.htm> > writes:
>>
>> > Hi Mike,
>> >
>> >   I agree on that point.
>> >
>> >    Maybe the label used with KDF could be different according
>> >   to different uses
>> >
>> > Pascal
>> >
>> > At 20:24 22/06/2008, Mike wrote:
>> >>It might be better to use a label other than "key expansion" in the KDF
>> >>since that is already used in TLS.
>> >>
>> >>Mike
>> >>
>> >>
>> >>Pascal Urien wrote:
>> >>>Dear all,
>> >>>The draft
>> http://www.ietf.org/internet-drafts/draft-urien-tls-keygen-00.txt
>> >>>  proposes a  keying infrastructure based on the TLS protocol.
>> >>>  It suggests defining an additional Key Distribution Function (KDF)
>> >>>  in order to deliver a set of cryptographic keys.
>> >>>   In a peer to peer mode keys are directly produced as inputs of
>> >>> the KDF functions.
>> >>>   For centralized architectures they are delivered through containers,
>> >>>   secured with keys derived from the KDF function.
>> >>>   I will attend to the next IETF meeting in Dublin, and i hope to
>> >>> present
>> >>>   more precisely the scope of this proposal
>> >>>Best Regards
>> >>>Pascal
>> >>_______________________________________________
>> >>TLS mailing list
>> >>TLS at ietf.org <TLS at ietf.htm>
>> >> https://www.ietf.org/mailman/listinfo/tls
>> >> <https://www.ietf.org/mailman/listinfo/tls>
>
>
> _______________________________________________
> TLS mailing list
> TLS at ietf.org <TLS at ietf.htm>
> https://www.ietf.org/mailman/listinfo/tls
>
>
> --
> Regards,
> Uri
>
> _______________________________________________
> TLS mailing list
> TLS at ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
_______________________________________________
TLS mailing list
TLS at ietf.org
https://www.ietf.org/mailman/listinfo/tls