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

[Alan DeKok <[e-mail]>]

On Jan 29, 2021, at 5:00 PM, Joseph Salowey <[e-mail]> wrote:
> DISCUSS: the EAP-TLS draft should also explain that session tickets may be sent either before or after the 0x00 octet.  Does the packet flow look any different for the two cases?  If so, what does that mean?
> 
> [Joe] I believe the flow of the message flights would be the same, but the on-the-wire format of those flights could be reversed.  I don't think this will necessarily cause a problem since the application data is consumed by the EAP TLS and the NewSessionTicket is consumed by TLS,  However I think the draft should be clear that this can happen.  

  I think so, too.

> DISCUSS: the EAP-TLS draft Section 2.1.1 should be updated to note that this examples does not include Session Tickets.  Section 2.1.2 should be updated to note that there are more rounds than for the previous section.
> 
> [Joe] Yes.  It might be helpful to say that the commitment message may be sent before or after the client authentication is verified, but in the case that resumption is used it will always be after.  

  I think that's a good idea.  The current draft doesn't make this explicit.

  But... if the commitment message is sent before the client certificates have been authenticated, what does that commitment message *mean*?

  i.e. can the server send the commitment message, ignore the client cert information, and send an EAP-Success?  Even if the client certs have expired, been revoked, etc.?  Can the client detect a rogue server which always answers "yes"?

  RFC 4137 (https://tools.ietf.org/html/rfc4137) describes a state machine for EAP peer and server.  Does this work follow that?

> [Joe]  If we are going to make a change in the key derivation we should do it now.  Personally, I think we should update the key derivation to separate the MSK and EMSK, but it is workable as is.  
> I think there are potential issues around the ordering of the 0x00 octet and other messages, but I don't think this will require changes to implementations in the short term, but the spec needs to clarify this. 

  I agree.

  There's also the question of *why* the commitment message is there.  It's not in EAP-TLS for TLS 1.2.  The draft doesn't explain why it's not needed in TLS 1.2, but is needed for TLS 1.3.  Such an explanation would go a long way to clarifying many issues around the commitment message.

>   So if we later discover that EAP-TLS is flawed, we can only deprecated EAP-TLS, and create a new EAP-TLS "prime", with a new EAP type code.
> 
> [Joe] Perhaps we could use an expanded EAP-Type for the alpha? Or perhaps experimental or a temporary experimental allocation could be made (not sure if that would be possible). 

  I think the issue for MS is less "alpha" code than "shipping" code.  If we use an experimental type, it doesn't matter if it's interoperable, because people won't deploy it in production.  Implementors are already verifying code behind the scenes in builds which aren't shipped to customers.  So the type code is less of an issue, because that interoperability is "inter-engineer", and not "inter-customer".

  Alan DeKok.