Subject: [Emu] Issue 59 - Key Update

From: Joseph Salowey <[email-masked]>
Date: Sun, 11 Apr 2021 19:40:48 -0700

Please review the following proposal and discuss issues on this thread.

Alan's review pointed out the following

Section 2.1.1 says:
>    TLS 1.3 introduced the Post-Handshake KeyUpdate
>    message which is not useful and not expected in EAP-TLS.
> Q: What does it mean that the message is "not expected"?  This seems
> like a source of implementation-defined behavior, which experience
> shows has been a source of interoperability and security issues.

This does seem to require some more specification.  Here is a proposal.

"TLS 1.3 introduced the Post-Handshake KeyUpdate message which is not
useful and not expected in EAP-TLS.  Implementations SHOULD NOT send a
KeyUpdate message.  If a KeyUpdate message is received then an
implementation SHOULD ignore the message and it SHOULD NOT send a KeyUpdate
message in response."

I think this is better than "implementations MUST NOT send this message and
MUST fail upon reception".  The problem here is that the EAP TLS
implementation may not have control over this behavior.

Thanks,

Joe

---

From: Alan DeKok <[email-masked]>
Date: Mon, 12 Apr 2021 07:58:30 -0400

On Apr 11, 2021, at 10:40 PM, Joseph Salowey <[email-masked]> wrote:
> "TLS 1.3 introduced the Post-Handshake KeyUpdate message which is not useful and not expected in EAP-TLS.  Implementations SHOULD NOT send a KeyUpdate message.  If a KeyUpdate message is received then an implementation SHOULD ignore the message and it SHOULD NOT send a KeyUpdate message in response."
>
> I think this is better than "implementations MUST NOT send this message and MUST fail upon reception".  The problem here is that the EAP TLS implementation may not have control over this behavior.  

  It looks like key update messages are explicitly requested by either party.  From OpenSSL:

  https://www.openssl.org/docs/man1.1.1/man3/SSL_key_update.html

  If the KeyUpdate message is sent only when requested, it would make sense to forbid sending it.  EAP-TLS has no reason to just randomly change the encryption keys used for TLS.  EAP-TLS is using TLS for authentication, and not for bulk data transfer.

  If the underlying TLS library randomly sends it (or sends it subject to unknown criteria), then the EAP-TLS implementation (peer or authenticator) should be able to detect it via a callback:

https://www.openssl.org/docs/man1.0.2/man3/SSL_set_msg_callback.html

  There appears to be no way for the application to tell the TLS library to ignore the message.

  The safest thing would seem to be:

a) forbidding EAP-TLS implementations from explicitly requesting it

b) noting that TLS libraries may still do key updates

c) noting that EAP-TLS implementations can often detect key updates, and

d) leaving it to the implementation to decide what to do.

  i.e. "We don't know why you'd use it.  But if someone else does use it, and it works, great.  Otherwise, buyer beware".

  Alan DeKok.

---

From: Joseph Salowey <[email-masked]>
Date: Mon, 12 Apr 2021 21:40:29 -0700

On Mon, Apr 12, 2021 at 4:58 AM Alan DeKok <[email-masked]>
wrote:

> > I think this is better than "implementations MUST NOT send this message
> and MUST fail upon reception".  The problem here is that the EAP TLS
>   If the KeyUpdate message is sent only when requested, it would make
> sense to forbid sending it.  EAP-TLS has no reason to just randomly change
> the encryption keys used for TLS.  EAP-TLS is using TLS for authentication,
> and not for bulk data transfer.
>
>   If the underlying TLS library randomly sends it (or sends it subject to
> unknown criteria), then the EAP-TLS implementation (peer or authenticator)
> should be able to detect it via a callback:
>
>   i.e. "We don't know why you'd use it.  But if someone else does use it,
> and it works, great.  Otherwise, buyer beware".
>
>
[Joe] OK, this sounds reasonable to me.  How about text like the following:

"EAP-TLS implementations MUST NOT explicitly request key updates.  It is
possible that a TLS library implementation may automatically send a key
update message so an implementation detecting the reception of a keyUpdate
message MAY process or ignore the message since only a minimum amount of
application data is exchanged in the channel."

---

From: Alan DeKok <[email-masked]>
Date: Tue, 13 Apr 2021 06:18:43 -0400

On Apr 13, 2021, at 12:40 AM, Joseph Salowey <[email-masked]> wrote:
> "EAP-TLS implementations MUST NOT explicitly request key updates.  It is possible that a TLS library implementation may automatically send a key update message so an implementation detecting the reception of a keyUpdate message MAY process or ignore the message since only a minimum amount of application data is exchanged in the channel."   

  That's great, thanks.

  Alan DeKok.