Re: [Emu] Issue 59 - Key Update
On Apr 13, 2021, at 12:40 AM, Joseph Salowey wrote: > [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." That's great, thanks. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Issue 59 - Key Update
On Mon, Apr 12, 2021 at 4:58 AM Alan DeKok wrote: > On Apr 11, 2021, at 10:40 PM, Joseph Salowey wrote: > > 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. > > 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". > > [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." > Alan DeKok. > > ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Issue 59 - Key Update
On Apr 11, 2021, at 10:40 PM, Joseph Salowey wrote: > 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. 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. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Issue 59 - Key Update
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 ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
