Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: Conformance with the TLS 13 Spec

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 2 Nov 2020 07:39:20 +0000

Hi Mohit,

I read Jim's email and he is not saying that you should make it an optional to support feature.

The issue is:

- are you trying to change the functionality of TLS 1.3 with this draft, and
- is there a good reason to do so?

In this case, the "SHOULD" statement gives an implementer absolutely not idea when or when it would be good to implement this feature.
Besides this, I don't even believe that the TLS 1.3 spec gives you that freedom for this specific feature anyway.

Ciao
Hannes

From: Mohit Sethi M <[email-masked]>
Sent: Saturday, October 31, 2020 6:04 PM
To: Hannes Tschofenig <[email-masked]>; [email-masked]
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: Conformance with the TLS 13 Spec

Hi Hannes,

Jim Schaad had asked for this: https://mailarchive.ietf.org/arch/msg/emu/XpRkNN-mh5BuiTD1O8iEfz9sM4M/

It is still optional to use. The figure only shows what the exchange would look like if a HRR was sent by the server.

--Mohit
On 10/21/20 12:16 PM, Hannes Tschofenig wrote:
Hi all,

Section 2.1.6 says:

"
   An EAP-TLS peer and server SHOULD support the use of
   HelloRetryRequest message.
"

My understanding of the TLS 1.3 specification is that the HelloRetryRequest is not an optional-to-implement message but it is only optional to use.

Is there a reason to deviate from the TLS 1.3 specification? Is there any reason to talk about the HRR message? The purpose of the message is given in the TLS 1.3 spec and whether you use it or not is up to the deployment.

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

_______________________________________________

Emu mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/emu

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Mohit Sethi M <[email-masked]>
Date: Mon, 2 Nov 2020 08:57:41 +0000

I now understand your issue with the sentence "An EAP-TLS peer and server SHOULD support the use of HelloRetryRequest message.". I guess there is no need for it, i.e., the section would be just fine without that sentence:

TLS 1.3 [RFC8446] defines that TLS servers can send a HelloRetryRequest message in response to a ClientHello if the server finds an acceptable set of parameters but the initial ClientHello does not contain all the needed information to continue the handshake.  One use case is if the server does not support the groups in the "key_share" extension, but supports one of the groups in the "supported_groups" extension.  In this case the client should send a new ClientHello with a "key_share" that the server supports.

As noted in Section 4.1.4 of [RFC8446], the server MUST provide the supported_versions extensions and SHOULD contain the minimal set of extensions necessary for the client to generate a correct ClientHello pair.  A HelloRetryRequest MUST NOT contain any extensions that were not first offered by the client in  its ClientHello, with the exception of optionally including the cookie extension.

The case of a successful EAP-TLS mutual authentication after the server has sent a HelloRetryRequest message is shown in Figure 8. Note the extra round-trip as a result of the HelloRetryRequest.

Commit on git: https://github.com/emu-wg/draft-ietf-emu-eap-tls13/commit/d4ac353a90dc7466d6da9deb5f50f4eb7c585e9b

--Mohit

On 11/2/20 9:39 AM, Hannes Tschofenig wrote:
Hi Mohit,

I read Jim’s email and he is not saying that you should make it an optional to support feature.

The issue is:

In this case, the “SHOULD” statement gives an implementer absolutely not idea when or when it would be good to implement this feature.
Besides this, I don’t even believe that the TLS 1.3 spec gives you that freedom for this specific feature anyway.

Ciao
Hannes

From: Mohit Sethi M <[email-masked]><mailto:[email-masked]>
Sent: Saturday, October 31, 2020 6:04 PM
To: Hannes Tschofenig <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: Conformance with the TLS 13 Spec

Hi Hannes,

--Mohit

Section 2.1.6 says:

"

Ciao
Hannes

Emu mailing list

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 2 Nov 2020 09:16:21 +0000

Thanks, Mohit.

You could also delete the entire paragraph because it adds nothing to what is already said in the TLS 1.3 spec.
See https://github.com/hannestschofenig/draft-ietf-emu-eap-tls13/pull/1

Ciao
Hannes

From: Mohit Sethi M <[email-masked]>
Sent: Monday, November 2, 2020 9:58 AM
To: Hannes Tschofenig <[email-masked]>; Mohit Sethi M <[email-masked]>; [email-masked]
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: Conformance with the TLS 13 Spec

--Mohit

The issue is:

Ciao
Hannes

Hi Hannes,

--Mohit

Section 2.1.6 says:

"

Ciao
Hannes

Emu mailing list

Emu mailing list

---

From: Mohit Sethi M <[email-masked]>
Date: Mon, 2 Nov 2020 11:20:31 +0000

Done as suggested:

https://github.com/emu-wg/draft-ietf-emu-eap-tls13/commit/8e158b5dc06ab5efd06c130ceffefe8c0cdff8e0

--Mohit

On 11/2/20 11:16 AM, Hannes Tschofenig wrote:
Thanks, Mohit.

Ciao
Hannes

From: Mohit Sethi M <[email-masked]><mailto:[email-masked]>
Sent: Monday, November 2, 2020 9:58 AM
To: Hannes Tschofenig <[email-masked]><mailto:[email-masked]>; Mohit Sethi M <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: Conformance with the TLS 13 Spec

--Mohit

The issue is:

Ciao
Hannes

Hi Hannes,

--Mohit

Section 2.1.6 says:

"

Ciao
Hannes

Emu mailing list

Emu mailing list

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 2 Nov 2020 11:33:57 +0000

Thanks, Mohit, for the quick turn-over.

From: Mohit Sethi M <[email-masked]>
Sent: Monday, November 2, 2020 12:21 PM
To: Hannes Tschofenig <[email-masked]>; Mohit Sethi M <[email-masked]>; [email-masked]
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: Conformance with the TLS 13 Spec

Done as suggested:

--Mohit

Ciao
Hannes

--Mohit

The issue is:

Ciao
Hannes

Hi Hannes,

--Mohit

Section 2.1.6 says:

"

Ciao
Hannes

Emu mailing list

Emu mailing list

Emu mailing list