A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the EAP Method Update WG of the IETF.
Title : Using EAP-TLS with TLS 1.3
Authors : John Preuß Mattsson
Mohit Sethi
Eliot Lear wrote:
> Consider the scenario when you have the CA sitting off somewhere in the
> distance, and a power failure or other service interruption has
> occurred. Should the client refuse to come up because stapling didn’t
> happen? Should old stapling information be
On Nov 2, 2020, at 4:37 AM, Hannes Tschofenig wrote:
> IMHO the entire text in Section 5.7 reads a bit like you are giving
> implementation guidance. That would be great if John or you had written such
> code. I don’t know whether you have.
> You are given the reader the impression that there
Joe,
Thanks for all your work on this. On the “discuss”es, would you mind giving
some time for them at the meeting?
Thanks,
Eliot
> On 1 Nov 2020, at 23:33, Joseph Salowey wrote:
>
> Below is the summary of the TEAP errata resolutions. The text that will be
> sent to the AD is in the
Robert Wilton has entered the following ballot position for
draft-ietf-emu-eaptlscert-06: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
Hi Hannes,
Thanks. I like the friendly banter. I could probably find the commit which says
"SHOULD mitigate known attacks" and blame it on John. I will change it to MUST.
:)
I have opened an issue to explain the relationship to RFC 7525:
FWIW there is a public Mbed TLS virtual workshop tomorrow (see
https://www.trustedfirmware.org/meetings/mbed-tls-workshop/).
Those who care about any of these security features could join, and ask for the
support of x, y and z.
Ciao
Hannes
From: Mohit Sethi M
Sent: Monday, November 2, 2020
Hi Hannes,
On 11/2/20 11:42 AM, Hannes Tschofenig wrote:
Hi Mohit,
> Et voilà, we seem to be moving towards a consensus!
That’s indeed exciting.
> PS: I would certainly like to help with getting OCSP in mbed TLS. I guess its
> high time.
Looking forward to it. I would then add the other
Thanks, Mohit, for the quick turn-over.
From: Mohit Sethi M
Sent: Monday, November 2, 2020 12:21 PM
To: Hannes Tschofenig ; Mohit Sethi M
; emu@ietf.org
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: Conformance with the TLS 13 Spec
Done as suggested:
I agree with you, Eliot.
I don’t understand for what certificates we would be using OCSP in the EAP-TLS
context, and what would happen if OCSP checks fail.
Ciao
Hannes
From: Eliot Lear
Sent: Monday, November 2, 2020 12:27 PM
To: Hannes Tschofenig
Cc: Mohit Sethi M ; emu@ietf.org
Subject: Re:
Hi Hannes,
My concern is not about implementation. At least for the sake of discussion,
let us assume that we can get the code to where it needs to be. The question
is more about what happens when an OCSP server is unavailable, either to the
client or to the server (stapled or otherwise).
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.
You could also delete the entire paragraph because it adds nothing to what is
already said in the TLS 1.3
Hi Mohit,
> Et voilà, we seem to be moving towards a consensus!
That’s indeed exciting.
> PS: I would certainly like to help with getting OCSP in mbed TLS. I guess its
> high time.
Looking forward to it. I would then add the other pieces to TLS 1.3 to make it
complete.
> There have
Hi Mohit,
I have now read the email from Terry and he is not suggesting the original
text. He is, in fact, correcting misleading text in your draft.
IMHO the entire text in Section 5.7 reads a bit like you are giving
implementation guidance. That would be great if John or you had written such
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
Sent: Monday, November 2, 2020 9:58 AM
To: Hannes Tschofenig
Hi Hannes,
As said, we added this text based on the request of working group members.
There were comments and additions to this text by Terry Burton for example:
https://mailarchive.ietf.org/arch/browse/emu/?q=Client%20re-validation%20of%20server%20authority%20information%20during%20resumption
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
Et voilà, we seem to be moving towards a consensus!
--Mohit
PS: I would certainly like to help with getting OCSP in mbed TLS. I guess its
high time. There have been several requests for this already for a few years:
https://github.com/ARMmbed/mbedtls/issues/880
On 11/2/20 10:08 AM, Hannes
Hi Mohit,
* I think it is a reasonable compromise for servers to implement OCSP
stapling. Clients can implement and use it, but they would be compliant even if
they don't. So the updated text would be (as Joe wrote in his email):
“
EAP-TLS servers supporting TLS 1.3 MUST implement
19 matches
Mail list logo
