Subject: [Emu] NewSessionTicket, Resumption, close_notify, and number of round-trips

From: John Mattsson <[email-masked]>
Date: Wed, 27 Jan 2021 15:09:12 +0000

Hi,

Looking at the GitHub version after the latest changes. I don't think the tradeoffs make sense anymore.

- Full handshake is now 4.5 round-trips
- Resumption is now 4.5 round-trips.

This does not seem like a good tradeoff or optimization at all. If we instead skipped Resumption, the full handshake could as far as I understand always be done in 3.5 round-trips. This would cut a large amount of complexity from the draft and implementations and make the protocol much faster.

Trading a few asymmetric operations for an additional round-trip does not make sense to me. Optimizing away a few asymmetric operation is not important. Optimizing the number of round-trips is very important.

My conclusion from the discussion regarding the Commitment message is not that is should be replaced by the close_notify, but that EAP-TLS should probably remove Commitment message, NewSessionTicket, and resumption...

EAP-TLS 1.3 could then be done in 3.5 round-trips as shown below:

EAP-TLS Peer                                      EAP-TLS Server

                                                      EAP-Request/
                              <--------                  Identity
 EAP-Response/
 Identity (Privacy-Friendly)  -------->
                                                      EAP-Request/
                                                 EAP-Type=EAP-TLS
                              <--------                (TLS Start)
 EAP-Response/
 EAP-Type=EAP-TLS
(TLS ClientHello)             -------->
                                                      EAP-Request/
                                                 EAP-Type=EAP-TLS
                                                 (TLS ServerHello,
                                          TLS EncryptedExtensions,
                                           TLS CertificateRequest,
                                                  TLS Certificate,
                                            TLS CertificateVerify,
                              <--------              TLS Finished)
 EAP-Response/
 EAP-Type=EAP-TLS
(TLS Certificate,
 TLS CertificateVerify,
 TLS Finished)                -------->
                              <--------               EAP-Success

/John

---

From: Alan DeKok <[email-masked]>
Date: Wed, 27 Jan 2021 10:16:51 -0500

> - Full handshake is now 4.5 round-trips

  Does that account for large / long certificate chains?

> This does not seem like a good tradeoff or optimization at all. If we instead skipped Resumption, the full handshake could as far as I understand always be done in 3.5 round-trips. This would cut a…

  That sounds good.  But how would this affect other TLS-based EAP methods?  They send data inside of the tunnel, which adds round trips.  So perhaps resumption is useful there?

  It would likely be problematic if EAP-TLS doesn't support resumption, but TTLS / PEAP / etc. required it.

  And of course, this ignores the timeliness of the changes.  I suspect that silence from the WG means that consensus is "we can afford to wait another year for EAP-TLS to be finished".

  Alan DeKok.

---

From: Joseph Salowey <[email-masked]>
Date: Wed, 27 Jan 2021 12:25:00 -0800

On Wed, Jan 27, 2021 at 7:17 AM Alan DeKok <[email-masked]>
wrote:

> > This does not seem like a good tradeoff or optimization at all. If we
> instead skipped Resumption, the full handshake could as far as I understand
> always be done in 3.5 round-trips. This would cut a large amount of
> complexity from the draft and implementations and make the protocol much
> faster.
>
>   That sounds good.  But how would this affect other TLS-based EAP
> methods?  They send data inside of the tunnel, which adds round trips.  So
> perhaps resumption is useful there?
>
[Joe] It seems that resumption would help in the case that large
certificates cause multiple round trips.  Do you have an idea of how
widespread resumption use is in current EAP-TLS implementations?   Its
likely that TEAP implementations would use resumption, however they handle
commitment in a different way.

>   And of course, this ignores the timeliness of the changes.  I suspect
> that silence from the WG means that consensus is "we can afford to wait
> another year for EAP-TLS to be finished".
>
>   Alan DeKok.
>
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu
>

---

From: Alan DeKok <[email-masked]>
Date: Wed, 27 Jan 2021 17:03:49 -0500

On Jan 27, 2021, at 3:25 PM, Joseph Salowey <[email-masked]> wrote:
> [Joe] It seems that resumption would help in the case that large certificates cause multiple round trips.  Do you have an idea of how widespread resumption use is in current EAP-TLS implementations?

  It's common.  Perhaps not ubiquitous, but common.  Once deployments get past the trivial / tiny certificate stage, resumption helps lower the number of round trips required.

  For PEAP and TTLS, it's even more common.  The main benefit to session resumption there is that the name / password does not need to be checked against an external database.  For slow databases, TLS session resumption can result in significantly lower load, and significantly faster re-auth times.

  Alan DeKok.

---

From: John Mattsson <[email-masked]>
Date: Thu, 28 Jan 2021 14:44:06 +0000

Hi,

I am not very happy with adding an additional dummy roundtrip to the 5G certificate authentication. Fragmentation and slow databases can be optimized away (short chains, small certs, 4K or 9K frames) but a mandatory extra roundtrip stays forever.

Without fragmentation, EAP-TLS 1.3 is now worse than EAP-TLS 1.2 when it comes to latency. They have the same number of roundtrips for full handshake, but EAP-TLS 1.3 has one more for resumption. In practice, with a typical 1500 MTU, EAP-TLS 1.3 is probably faster as long as certificate compression (RFC8879, draft-mattsson-cose-cbor-cert-compress-06) are used.

The suggestion from Jim to use application data was adopted as it did not introduce extra round-trips and allowed alerts. Is the principle of not using application data really worth introducing a mandatory extra round-trip? And is a mandatory extra dummy roundtrip really the best solution we can come up with?

                                                      EAP-Request/
                                                 EAP-Type=EAP-TLS
                              <--------         (TLS close_notify)
EAP-Response/
EAP-Type=EAP-TLS             -------->

It looks kind of stupid ....

After Jim suggested to use application data, the commitment issue was not discussed much more. Would e.g. using the reserved bits in the EAP-TLS packet be possible or would that cause problems? I think an extra round-trip is a sad conclusion to the EAP-TLS 1.3 work.

John

---

From: Alan DeKok <[email-masked]>
Date: Thu, 28 Jan 2021 10:03:57 -0500

On Jan 28, 2021, at 9:44 AM, John Mattsson <[email-masked]> wrote:
> 
>> Hi,
>>  
>> I am not very happy with adding an additional dummy roundtrip to the 5G certificate authentication.

  Dummy round trips are bad, unless they serve a purpose.  The question here is likely not "what's best" but "what's the least worst choice".

>> Fragmentation and slow databases can be optimized away (short chains, small certs, 4K or 9K frames) but a mandatory extra roundtrip stays forever.

  That statement makes me nervous.  I don't see how a standards group can make a decision that peoples deployment requirements are invalid, and should be ignored.

  Whatever the solution is for EAP-TLS, no one will be perfectly happy.  If the price for allowing some people to use long chains is that 5G has extra round trips, well... 

>> The suggestion from Jim to use application data was adopted

  Initially.  Recent discussion has suggested different ways to achieve the same goal.  As a result, we cannot say that the suggestion is currently the consensus.

>> After Jim suggested to use application data, the commitment issue was not discussed much more. Would e.g. using the reserved bits in the EAP-TLS packet be possible or would that cause problems? I…

  It would be much worse to tell people "you have to throw away your current systems and practices, because some people don't like them".

  From an implementation point of view, draft-13 is fine for me.  The open question is really whether or not we're changing that.

  The TLS review so far seems to have stalled.  Which means to me that the TLS feedback isn't important enough to finalize it.  So we should just say "thanks", and stick with draft-13.

  Alan DeKok.