Re: [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

On Mon, Jan 04, 2021 at 02:44:01PM +1100, Martin Thomson wrote:
> 
> I would instead either prohibit the use of application data outright or say that it carries no semantics unless otherwise negotiated.  The current design has the effect of rendering application data unusable, so perhaps the former is best.

The "rendering application data unusable" bit is something that bothered me
a lot as well.  While banning application data is okay for EAP-TLS itself
(AIUI), the document implies that other TLS-based EAP mechanisms do need to
convey application data, and I think that the responsible thing to do is
ensure that the machinery we use here would be compatible with those other
EAP mechanisms with no, or only minimal, changes.

> # Key Schedule
> 
> The other thing I observe is the way that this slices up the exporter output.  This was something that old versions of TLS did, but TLS 1.3 did away with.  Though RFC 5216 did this, EAP-TLS for TLS 1.3 doesn't need to.  This could - and should - do the same.  All it means is having more exporter labels.
> 
> I appreciate that this uses exporters now rather than abusing the internal PRF.  That's good.  The next step is to dispense with the intermediate values (Key_Material, MSK, EMSK, IV) and all the slicing that occurs and use the TLS exporter for each of the six values that the protocol requires.  I also note that the 0x0D value is used multiple times, unnecessarily, both as a context strong to the exporter and as a prefix to the session ID.

I think Alan explained the dual purpose of the Type-Code here.  (I myself
had missed the connection of where the 0x0d value came from, and a
reference for that seems like it would be helpful, as setting up this
machinery for reuse by other mechanisms in a way that provides key
separation.)

-Ben