Hi Ben,
On 1/7/21 9:21 AM, Benjamin Kaduk wrote:
> On Tue, Jan 05, 2021 at 10:41:50AM -0500, Alan DeKok wrote:
>> On Jan 5, 2021, at 4:47 AM, Mohit Sethi M wrote:
>>> What I am gathering is that this commitment message should instead be
>>> made into a confirmation message, i.e. it should only be sent after
>>> receiving TLS Finished from the client? This would result in one extra
> I forget if it has been explicitly mentioned in the thread so far, but
> https://tools.ietf.org/html/rfc8446#section-4.4.4 is pretty clear that
> "Servers MAY send data after sending their first flight, but because the
> handshake is not yet complete, they have no assurance of either the peer's
> identity or its liveness (i.e., the ClientHello might have been replayed)."
> In particular, "no assurance of the peer's identity" means that the server
> is at this point sending to an unauthenticated client. If the goal of
> EAP-TLS is to ascertain that there is in fact an authenticated client, it
> may be ill-advised to send indications of overall success to an
> unauthenticated client. Part of what Martin alluded to with the situation
> being lousy overall is that there are basically two things that can
> cryptographically confirm that the client has authenticated: successful
> processing of the client Finished, and values derived from the resumption
> master secret. In "normal" TLS usage the server will bail out if the
> client Finished doesn't validate, so continued receipt of application data,
> including application data bearing application-protocol responses to data
> the client sent in 1-RTT after client Finished, effectively implies that
> the server validated the client Finished, but the EAP-TLS usage is quite
> different from that. There's not a cryptographic way to tell whether 0x00
> application data was generated before or after the client Finished was
> processed.
Yes, this was discussed. See email from Hannes
(https://mailarchive.ietf.org/arch/msg/emu/Vf4Zor-xIDVZLQB-BE9mPvlDZMM/)
where we did look at the text from RFC 8446 about the peer being
unauthenticated. It was (at that time) accepted since the server was
only committing to not sending more post-handshake messages (rather than
indicating successful completion of handshake).
>
>>> round trip to both figure 1 and 3 in the current draft. So we would end
>>> up with the same number of messages as RFC 5216 for full authentication
>>> (https://tools.ietf.org/html/rfc5216#section-2.1.1) and actually do
>>> worse than RFC 5216 (one extra round trip) in case resumption
>>> (https://tools.ietf.org/html/rfc5216#section-2.1.2).
>>That sounds right.
> While counting arrows in the diagram like this is definitely useful, part
> of my concerns related to the need (in non-resumption flows) to convey the
> entire (enlarged) server Certificate chain in individual 1020-byte
> EAP-Requests. My understanding was that the server had to send a single
> 1020-byte EAP-Request and wait for the corresponding EAP-Response before
> sending the next chunk of the certificate chain. It was in that scenario
> that I expected a substantial difference between resumption and
> non-resumption.
>
>>> Maybe this is acceptable? The draft anyway notes that "Sending the
>>> Commitment Message in a separate EAP-Request adds an additional
>>> round-trip, but may be necessary in TLS implementations that only
>>> implement a subset of TLS 1.3.". In which case, I am not sure if the
>>> reasons against using close_notify apply anymore.
>>I won't offer opinions on TLS internals, as I'm out of my depth there.
>>
>>As an implementor, the priority is getting TLS alerts (expired cert,
>> etc.) back from the EAP server to the EAP peer. Those messages can then be
>> used to debug deployment issues.
>>
>>The exact method of doing this is less important. The "0x00" octet works
>> now, so I'm happy with it. But if TLS review decides that should change,
>> that's fine, too.
> It's pretty much guaranteed that we can get the TLS alerts if we always
> wait for client Finished to be processed (whatever signal we end up
> choosing to send after that occurs). Have we reached agreement on whether
> we should always wait for client Finished?
I hope so. I'll try to submit an update next week.
--Mohit
>
> -Ben
>
> ___
> TLS mailing list
> t...@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
