Hi Alan,
I reviewed draft-ietf-emu-tls-eap-types-02. Some minor comments:
- “The Type-Code is defined to be 1 octet for values smaller than 255.”
I think this should be “smaller than 254” as 0xFE = 254
- “Some implementations use the TLS "Finished" state as a signal that
application data is now available.
As there is no formal “Finished” state, maybe better to write out that this
happens after receiving and sending Finished messages (in any order). TLS 1.3
formally defines this state and calls it CONNECTED.
- The following five derivations were removed from draft-ietf-emu-eap-tls13. I
assume draft-ietf-emu-tls-eap-types should do the same
IV = TLS-Exporter("EXPORTER_EAP_TLS_IV", Type-Code, 64)
Enc-RECV-Key = MSK(0, 31)
Enc-SEND-Key = MSK(32, 63)
RECV-IV = IV(0, 31)
SEND-IV = IV(32, 63)
- OLD “EAP servers peers MUST NOT”
NEW “EAP peers MUST NOT”
- The document use “Type ID”, “Type code” and “Type-Code”. Likely one is
enough. I also notice that RFC 3748 use Code for a different purpose, does not
use ID, and talks about “EAP Type Values”, “Method Type Values”. Would it be a
good idea to change both draft-ietf-emu-eap-tls13 and
draft-ietf-emu-tls-eap-types to use the term “type value”?
- List formatting
“* EXPORTER: session key seed * EXPORTER: Inner Methods Compound Keys
* EXPORTER: Session Key Generating Function * EXPORTER: Extended
Session Key Generating Function * [email protected]”
- The draft mentions “commitment message” several times, but you are probably
aware of that.
Cheers,
John
_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu
