Subject: [TLS] PRF Negotiation - Finished "gotcha"

From: Michael StJohns <[email-masked]>
Date: Fri, 18 Apr 2014 11:05:26 -0400

As I was working through the "finished" message email I just sent, I 
realized something about PRF negotiation.   The client, when it sends a 
ClientHello, doesn't necessarily know which PRF it will be using 
(assuming there are multiple PRFs defined in the offered cipher suites) 
until it gets the ServerHello back.  I think that means that the client 
either needs to keep a copy of the ClientHello around (or the data to 
rebuild it), or needs to keep multiple HASH states - one for each PRF 
algorithm.

It may be useful to add a paragraph on PRF negotiation implications that 
provides this guidance.

Mike

---

From: Martin Thomson <[email-masked]>
Date: Fri, 18 Apr 2014 09:46:20 -0700

On 18 April 2014 08:05, Michael StJohns <[email-masked]> wrote:
> ClientHello, doesn't necessarily know which PRF it will be using (assuming
> there are multiple PRFs defined in the offered cipher suites) until it gets
> the ServerHello back.  I think that means that the client either needs to
> keep a copy of the ClientHello around (or the data to rebuild it), or needs
> to keep multiple HASH states - one for each PRF algorithm.
>

Indeed.

There is another way to avoid this problem: don't negotiate the hash
function used for the PRF.  SHA-256 might be good enough until we next
revise the protocol.

https://github.com/tlswg/tls13-spec/issues/26

---

From: Michael StJohns <[email-masked]>
Date: Fri, 18 Apr 2014 13:07:43 -0400

> https://github.com/tlswg/tls13-spec/issues/26

But I *really* want to be able to build a cipher suite that only needs 
AES encrypt....

---

From: Paul Lambert <[email-masked]>
Date: Fri, 18 Apr 2014 13:26:03 -0700

]But I *really* want to be able to build a cipher suite that only needs
]AES encrypt....

+1

Specifically for the data path. SHA-256 is appropriate key management, generation etc. 

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

---

From: Martin Thomson <[email-masked]>
Date: Fri, 18 Apr 2014 13:28:27 -0700

> Specifically for the data path. SHA-256 is appropriate key management, generation etc.

The PRF is only needed for key management, generation, extractors,
etc...  I think that (perhaps) Mike wants to go one further and be
able to ship a stack that doesn't even HAVE SHA-256.

---

From: Michael StJohns <[email-masked]>
Date: Sat, 19 Apr 2014 17:39:26 -0400

> able to ship a stack that doesn't even HAVE SHA-256.

Exactly.  There are a pile of cheap chips out there that implement AES 
but don't implement a hashing algorithm (and strangely vice versa).  On 
the software side, the tradeoffs between performance and space for the 
SHA functions are interesting choices.

On the other hand, I can't find any "standard" block cipher based 
hashing functions.  There are a number of proprietary and a number of 
"standards proposals" (e.g. to the SHA3 competition), but none that's 
showing up as a NIST/ISO/IEEE/IETF approved hashing function.

And please ignore my CMAC('0', data) suggestion.  It was pointed out to 
me (something that I used to know) that CMAC with a known key lacks 
collision resistance.

Mike