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

[Benjamin Kaduk <[e-mail]>]

On Tue, Jan 05, 2021 at 10:26:40AM +1100, Martin Thomson wrote:
> On Mon, Jan 4, 2021, at 21:01, Mohit Sethi M wrote:
> > >  I have a much simpler one: the EAP layer has a signal that the 
> > >  protocol is complete: EAP-Success 
> > Alan Dekok explained in a separate email thread why this is not the 
> > case 
> > (https://mailarchive.ietf.org/arch/msg/emu/uMNKV_vfov7ASob6_Qu3FlCNcT0/). He wrote: "The EAP-Success and EAP-Failure messages are *not* protected.  i.e. they are 4-bytes of data which can be spoofed rather trivially.". 
> 
> I specifically addressed that point in my original email.  My assertion was that this is not an significant concern.
> 
> Your point about reliability is confusing.  I've read Section 4.2 of RFC 3748 and while it says "A peer MUST allow for this circumstance as described in this note.", I see no explanation of how to concretely make that allowance.  Are you saying that EAP methods don't really use EAP-Success and condition their behaviour on other signals?  For TLS 1.3, where the server indicates success before the client, I can see how you might want a reliable confirmation that the server has accepted the client Finished.
> 
> As an aside, this makes is clear that the signal does not exist for the reason implied by the draft.  It does not exist to signal that the TLS messages are done; it exists to signal that the server has received and accepted the client Finished.  To that end, it's not really a layering violation in the sense that Ben describes.  The layering violation exists only because of the language constraining what TLS does thereafter; in that case, a language cleanup might be enough to address the concerns.
> 
> Note however, that the proposed design does not guarantee that a Confirmation Message acknowledges the client Finished.  The server can send the proposed Confirmation Message before the client completes the handshake.  
> 
> Echoing the client Finished might help, but that's a layering violation too.  Ideally you would be able use something like exporters to help, but those have problems (see below).  I know it's a knee-jerk, but the idea of making EAP-Success reliable is far more appealing to me than anything you suggest.
>  
> > I also think that this should not be treated as an issue for EAP-TLS 
> > only. I can imagine other deployments which use TLS for making 
> > authorization decisions but do not use the TLS for sending message. So 
> > I am glad that Ben has brought this to the TLS working group for 
> > further discussion. Whether we use this 1-byte of application data (as 
> > done in this draft) or some other mechanism (such as close_notify), we 
> > need a reliable way of telling that no further post handshake messages 
> > will be sent. 
> 
> EAP has the privilege of being the first to grapple with this.
> 
> I'm going to suggest something slightly scandalous: TLS 1.3 exporters are not the ideal design.  They should have included the full handshake transcript, just like the resumption secret.  There were good reasons at the time for designing them as they are, and there are likely reasons to retain the current design as an option (it's stronger than the early exporter and there might be use cases), but those original reasons are less relevant.  The current design gives short shrift to client authentication, to the detriment of use cases like EAP.

I was just grappling with this topic recently in a different context.  I
agree that it would be good to have at least some version of an exporter
available that includes the full transcript's hash in the context.  It
seems to have made some implicit assumptions about how TLS is used (to
carry application data, not as a key-exchange or authentication mechanism)
and how TLS records are carried (over TCP, which serializes handshake
messages and application data; not the case for QUIC) that are causing
problems for us now.

That said, it doesn't seem like it would be *terribly* complicated to
specify a new type of exporter interface that does use the full transcript.
It might have to be TLS 1.3+ only, and getting the IANA considerations
right might be gnarly, but the core of it seems pretty simple.

> Having exporters depend on the entire transcript would serve EAP better.  In this case, you could provide an application-level signal using an exported value.
> 
> Without that sort of in-TLS affordance, confirming receipt of the client Finished might do.  You still have the possibility that the server doesn't depend on client authentication and so predicts the value, but that would be true of a full-transcript exporter too, so arguably that doesn't matter.

If there truly is a need for a signal from TLS to not generate more
handshake messages (including to tear down the connection if KeyUpdate
would be needed), that seems like it is arguing for a new TLS handshake
message.  I am not 100% sure whether those semantics are needed for the
EAP-TLS case, but they might be needed elsewhere, as Mohit notes.

-Ben