I agree with all the proposed resolutions. For context, there was some prior
discussion of this errata here:
https://mailarchive.ietf.org/arch/msg/emu/K_XWBMevKNdxdWskK8RkBt1ZpSQ/
Jorge Vergara
From: Joseph Salowey
Sent: Wednesday, October 21, 2020 5:13 PM
To: EMU WG ; Jouni Malinen ; Jorge Ve
Errata 5767: https://www.rfc-editor.org/errata/eid5767
Status: Verified
Revision:
Section 3.3.1 says:
EAP method messages are carried within EAP-Payload TLVs defined in
Section 4.2.10. If more than one method is going to be executed in
the tunnel, then upon method completion, the server
(I accidentally dropped this list from the conversation)
On Wed, Oct 21, 2020 at 4:48 PM Jorge Vergara
wrote:
> >[Joe] Yes this is a concern and I think your interpretation of the
> current document is also valid. There may be more than one
> implementation. So what you implemented was:
>
> >
In theory I agree this is a possible resolution. However, this doesn’t match
any of the current TEAP implementations that I am aware of. Perhaps Oleg can
weigh in as well in terms of what he’s seen.
I believe all current implementations treat 60 as the desired output length
without treating as
Errata 5765: https://www.rfc-editor.org/errata/eid5765
Proposed Status: Verified
Revision: (unmodified from original posting)
Section 4.2.2 says:
M
Mandatory, set to one (1)
It should say:
M
0 (Optional)
Notes:
Authority-ID TLV is used only as an Outer TLV (in TEAP/Start)
Errata 5128: https://www.rfc-editor.org/errata/eid5128
Proposed State: Verified
Revision:
Section 5.2. says
IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys",
IMSK[j], 60)
It should say:
IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j] | 60)
Not
On Wed, Oct 21, 2020 at 12:11 PM Jouni Malinen wrote:
> On Wed, Oct 21, 2020 at 09:30:33AM -0700, Joseph Salowey wrote:
> > Errata 5127: https://www.rfc-editor.org/errata/eid5127
> > Proposed State: Verified
> > Revision:
> > Section 5.2.
> > OLD
> >
> > IMSK = First 32 octets of TLS-PRF(EMSK, "t
On Wed, Oct 21, 2020 at 09:30:33AM -0700, Joseph Salowey wrote:
> Errata 5127: https://www.rfc-editor.org/errata/eid5127
> Proposed State: Verified
> Revision:
> Section 5.2.
> OLD
>
> IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org" |
> "\0" | 64)
>
> NEW
>
> IMSK = First 32
Hannes Tschofenig wrote:
> this draft mandates OCSCP stapling (for use with TLS 1.3 in EAP-TLS)
> and I believe this is a problem for implementations. This extra burden
> is IMHO unjustified. For the type of deployments where EAP is used
> there is no need for a mandatory certific
Errata 5127: https://www.rfc-editor.org/errata/eid5127
Proposed State: Verified
Revision:
Section 5.2.
OLD
IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org" |
"\0" | 64)
NEW
IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org" |
'/0', 64)
Notes:
According to
RFC5
I'll be posting proposed errata revisions for a short, 1 week, final review
before sending it off to the Area Director (Roman) who has the
responsibility of the final action. For more information how errata are
handled and the please see [1].
Please take a little time to review the errata resolut
On Oct 21, 2020, at 5:02 AM, Hannes Tschofenig
wrote:
> this draft mandates OCSCP stapling (for use with TLS 1.3 in EAP-TLS) and I
> believe this is a problem for implementations. This extra burden is IMHO
> unjustified. For the type of deployments where EAP is used there is no need
> for a ma
On Oct 21, 2020, at 5:00 AM, Hannes Tschofenig
wrote:
> the draft says it updates the earlier EAP-TLS version and claims that the
> updates are related to
>
> * Section 5.6 Authorization
> * Section 5.7 Resumption
>
> The content of Section 5.6 actually does not relate to EAP-TLS but is gene
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
Hi all,
the draft contains a number of cases where text from the TLS 1.3 specification
or other specifications is repeated. Often, only fragments are used, which can
easily fool the reader into believing that the omitted parts do not apply.
Hence, I would avoid the repetition where not strictly
Hi all,
There are plenty of places in the draft where statements are made in a somewhat
sloppy manner.
Section 5.1:
" TLS 1.3 increases the number of
cryptographic parameters that are negotiated in the handshake.
"
Increases the number of parameters compared to what?
Section 5.1:
"
TLS 1.3
Hi all,
there are lots of editorial bugs in the text. I noticed many missing commas,
missing articles, etc.
I know that the RFC Editor does a great job in correcting all of those errors
but we have to do our work as well.
It would also be good to be consistent with the terms. How do you want t
Hi all,
this draft mandates OCSCP stapling (for use with TLS 1.3 in EAP-TLS) and I
believe this is a problem for implementations. This extra burden is IMHO
unjustified. For the type of deployments where EAP is used there is no need for
a mandatory certificate revocation checking with OCSP.
Hav
Hi all,
the draft says it updates the earlier EAP-TLS version and claims that the
updates are related to
* Section 5.6 Authorization
* Section 5.7 Resumption
The content of Section 5.6 actually does not relate to EAP-TLS but is generic
to all EAP methods. I don't think it even belongs in an EA
Hi all,
in an earlier email on this topic John wrote "I don't see why anybody would get
the impressions that the application data would be unencrypted, all application
data in TLS 1.3 is encrypted."
Even in the latest version of the draft (version -11) I can still find text
that says the c
Hi all,
Roman asked me to look at draft-ietf-emu-eap-tls13-11.
I have carefully read through the document and I will post my reviews in
separate emails.
There are still lots of room for improvement.
Ciao
Hannes
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential
21 matches
Mail list logo
