jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-emu-eap-tls13

Commentary: I " seconds " as suggested by  .  suggested " Perhaps both of these should be left to the TLS spec . " I would agree with this ....
Mailing list commentary: Thanks , one comment regarding item # 16 is inline below . [ ] Got it . Then maybe it is worth specifying seconds in the section " 5.7 . Resumption " also so it will be clear that the requirement in this section is the same strict as in " 2.1.2 . Ticket Establishment " .
Paragraph (version A):
application data 0x00.  After the EAP-TLS server has received an
empty EAP-Response to the EAP-Request containing the TLS application
data 0x00, the EAP-TLS server sends EAP-Success.
Paragraph (version B):
application data 0x00.  After the EAP-TLS server has sent an EAP-
Request containing the TLS application data 0x00 and received an EAP-
Response packet of EAP-Type=EAP-TLS and no data, the EAP-TLS server
sends EAP-Success.
Paragraph (version A):
that key leakage does not compromise any earlier connections.  It is
RECOMMMENDED to use "psk_dhe_ke" for resumption.
Paragraph (version B):
that key leakage does not compromise any earlier connections.  The
"psk_dh_ke" mechanism MUST be used for resumption unless the
deployment has a local requirement to allow configuration of other
mechanisms.
Paragraph (version A):
figterm3 shows an example message flow where the EAP-TLS server
authenticates to the EAP-TLS peer successfully, but the EAP-TLS peer
fails to authenticate to the EAP-TLS server and sends a TLS Error
alert.
Paragraph (version B):
figterm3 shows an example message flow where the EAP-TLS server
authenticates to the EAP-TLS peer successfully, but the EAP-TLS peer
fails to authenticate to the EAP-TLS server and the server sends a
TLS Error alert.
Paragraph (version A):
As suggested in RFC8446, EAP-TLS peers MUST NOT store resumption PSKs
or tickets (and associated cached data) for longer than 7 days,
regardless of the PSK or ticket lifetime.  The EAP-TLS peer MAY
delete them earlier based on local policy.  The cached data MAY also
be removed on the EAP-TLS server or EAP-TLS peer if any certificate
in the certificate chain has been revoked or has expired.  In all
such cases, an attempt at resumption results in a full TLS handshake
instead.
Paragraph (version B):
As suggested in RFC8446, EAP-TLS peers MUST NOT store resumption PSKs
or tickets (and associated cached data) for longer than 604800
seconds (7 days), regardless of the PSK or ticket lifetime.  The EAP-
TLS peer MAY delete them earlier based on local policy.  The cached
data MAY also be removed on the EAP-TLS server or EAP-TLS peer if any
certificate in the certificate chain has been revoked or has expired.
In all such cases, an attempt at resumption results in a full TLS
handshake instead.
Draft: draft-ietf-emu-eap-tls13

Commentary: While reading draft - ietf - emu - eap - tls13 - 15 I noticed that section now uses which is the named used in but not in RFC 8446 itself . I first thought this was a typo , before a further look showed that this change was mentioned in IETF 110 . Suggestion : make clear which parts need to be looked up from RFC 8446bis . In addition to exporter terminology , the meeting slides above also discuss about usercancelled behavior on slide 10 . For clarity , any updates from RFC 8446bis should be marked clearly . 
 It would be best not to have normative references that block on RFC 8446bis . Perhaps we can just reference that it is renamed from " exportermastersecret " 
 Sounds good . That should make clear where it comes from and that there 's no need to file errata about unknown term and/or RFC 8446bis dependency . Taking another look at my comment about usercancelled behavior on slide 10 ; to clarify what I was meaning : The slides hint that clarifications in 8446bis are needed by EAP - TLS too . If so , this looks like a reference to RFC 8446bis too . Finally , one nit : the alert name in RFC 8446 is " usercanceled " , not " user_cancelled " as in draft -15 . 
 I made a PR with explaining that the document use the terminology from RFC8446bis . Do we need to say anything about usercancelled ? RFC8446bis might do several clarifications and corrections . I think we should only mention things that are directly relevant for EAP - TLS 1.3 Current plan for RFC8446bis seems to be to ignore closenotify and I assume require close_notify after . This does not seem directly relevant for EAP - TLS 1.3 . Or ? 
 close issue ? 
 Yes , please close this . I think it 's now clear where exportersecret comes from . Also , thanks for the pointer to TLSv1.3 discussion . I agree usercanceled followed by close_notify discussion is not relevant for EAP - TLS 1.3 . It 's seems to be TLSv1.3 specification and implementation level detail as opposed to something that EAP - TLS 1.3 needs to directly react on .
Paragraph (version B):
This document follows the terminology from I-D.ietf-tls-rfc8446bis
where the master secret is renamed to the main secret and the
exporter_master_secret is renamed to the exporter_secret.
Paragraph (version B):
Readers are expected to be familiar with the terms and concepts used
in EAP-TLS RFC5216 and TLS RFC8446.  The term EAP-TLS peer is used
for the entity acting as EAP peer and TLS client.  The term EAP-TLS
server is used for the entity acting as EAP server and TLS server.
Draft: draft-ietf-emu-eap-tls13

Commentary: Update the draft to use the same spelling as TLS RFC uses . Relates to issue 
 While reading draft - ietf - emu - eap - tls13 - 15 I noticed that section now uses which is the named used in but not in RFC 8446 itself . I first thought this was a typo , before a further look showed that this change was mentioned in IETF 110 . Suggestion : make clear which parts need to be looked up from RFC 8446bis . In addition to exporter terminology , the meeting slides above also discuss about usercancelled behavior on slide 10 . For clarity , any updates from RFC 8446bis should be marked clearly . 
 It would be best not to have normative references that block on RFC 8446bis . Perhaps we can just reference that it is renamed from " exportermastersecret " 
 Sounds good . That should make clear where it comes from and that there 's no need to file errata about unknown term and/or RFC 8446bis dependency . Taking another look at my comment about usercancelled behavior on slide 10 ; to clarify what I was meaning : The slides hint that clarifications in 8446bis are needed by EAP - TLS too . If so , this looks like a reference to RFC 8446bis too . Finally , one nit : the alert name in RFC 8446 is " usercanceled " , not " user_cancelled " as in draft -15 . 
 I made a PR with explaining that the document use the terminology from RFC8446bis . Do we need to say anything about usercancelled ? RFC8446bis might do several clarifications and corrections . I think we should only mention things that are directly relevant for EAP - TLS 1.3 Current plan for RFC8446bis seems to be to ignore closenotify and I assume require close_notify after . This does not seem directly relevant for EAP - TLS 1.3 . Or ? 
 close issue ? 
 Yes , please close this . I think it 's now clear where exportersecret comes from . Also , thanks for the pointer to TLSv1.3 discussion . I agree usercanceled followed by close_notify discussion is not relevant for EAP - TLS 1.3 . It 's seems to be TLSv1.3 specification and implementation level detail as opposed to something that EAP - TLS 1.3 needs to directly react on . 
 This looks good to merge
Paragraph (version A):
Figures figterm1, figterm2, and figterm3 illustrate message flows in
several cases where the EAP-TLS peer or EAP-TLS server sends a TLS
Error alert message.  In earlier versions of TLS, error alerts could
be warnings or fatal.  In TLS 1.3, error alerts are always fatal and
the only alerts sent at warning level are "close_notify" and
"user_cancelled", both of which indicate that the connection is not
going to continue normally, see RFC8446.
Paragraph (version B):
Figures figterm1, figterm2, and figterm3 illustrate message flows in
several cases where the EAP-TLS peer or EAP-TLS server sends a TLS
Error alert message.  In earlier versions of TLS, error alerts could
be warnings or fatal.  In TLS 1.3, error alerts are always fatal and
the only alerts sent at warning level are "close_notify" and
"user_canceled", both of which indicate that the connection is not
going to continue normally, see RFC8446.
Draft: draft-ietf-emu-eap-tls13

Commentary: I see that " EAP - TLS 1.3 " is used more an more in the discussions to refer to this the combination of EAP - TLS and TLS 1.3 . The term is used in the document but not in the title and abstract 
   , Please run this title change by the list . 
 Looking at this it seems that this change is simpler than I originally thought . This looks OK to merge
Paragraph (version A):
The Extensible Authentication Protocol (EAP), defined in RFC 3748,
provides a standard mechanism for support of multiple authentication
methods.  This document specifies the use of EAP-Transport Layer
Security (EAP-TLS) with TLS 1.3 while remaining backwards compatible
with existing implementations of EAP-TLS.  TLS 1.3 provides
significantly improved security, privacy, and reduced latency when
compared to earlier versions of TLS.  EAP-TLS with TLS 1.3 further
improves security and privacy by always providing forward secrecy,
never disclosing the peer identity, and by mandating use of
revocation checking.  This document also provides guidance on
authorization and resumption for EAP-TLS in general (regardless of
the underlying TLS version used).  This document updates RFC 5216.
Paragraph (version B):
The Extensible Authentication Protocol (EAP), defined in RFC 3748,
provides a standard mechanism for support of multiple authentication
methods.  This document specifies the use of EAP-Transport Layer
Security (EAP-TLS) with TLS 1.3 while remaining backwards compatible
with existing implementations of EAP-TLS.  TLS 1.3 provides
significantly improved security, privacy, and reduced latency when
compared to earlier versions of TLS.  EAP-TLS with TLS 1.3 (EAP-TLS
forward secrecy, never disclosing the peer identity, and by mandating
use of revocation checking.  This document also provides guidance on
authorization and resumption for EAP-TLS in general (regardless of
the underlying TLS version used).  This document updates RFC 5216.
Draft: draft-ietf-emu-eap-tls13

Commentary: This looks good to merge
Paragraph (version A):
While EAP-TLS does not protect any application data except for the
Commitment Message, the negotiated cipher suites and algorithms MAY
be used to secure data as done in other TLS-based EAP methods.
Paragraph (version B):
While EAP-TLS does not protect any application data except for the
TLS record with application data 0x00, the negotiated cipher suites
and algorithms MAY be used to secure data as done in other TLS-based
EAP methods.
Paragraph (version A):
When an EAP-TLS server has successfully processed the TLS client
Finished and sent its last handshake message (Finished or a Post-
Handshake), it commits to not sending any more handshake messages by
sending an encrypted TLS record with application data 0x00.  The
encrypted TLS record with application data 0x00 is a protected
success result indication, as defined in RFC3748.  After sending an
encrypted TLS record with application data 0x00, the EAP-TLS server
may only send an EAP-Success.  The EAP-TLS server MUST NOT send an
encrypted TLS record with application data 0x00 alert before it has
successfully processed the client finished and sent its last
handshake message.
Paragraph (version B):
When an EAP-TLS server has successfully processed the TLS client
Finished and sent its last handshake message (Finished or a Post-
Handshake), it sends an encrypted TLS record with application data
0x00.  The encrypted TLS record with application data 0x00 is a
protected success result indication, as defined in RFC3748.  After
sending a EAP-Request that contains the protected success result
indication, the EAP-TLS server must not send any more EAP-Request and
may only send an EAP-Success.  The EAP-TLS server MUST NOT send an
encrypted TLS record with application data 0x00 alert before it has
successfully processed the client finished and sent its last
handshake message.
Draft: draft-ietf-emu-eap-tls13

Commentary: This looks good to merge .
Paragraph (version A):
When EAP-TLS is used with TLS version 1.3 the Key_Material, IV, and
Method-Id SHALL be derived from the exporter_secret using the TLS
exporter interface RFC5705 (for TLS 1.3 this is defined in
Section 7.5 of RFC8446).
Paragraph (version B):
When EAP-TLS is used with TLS version 1.3 the Key_Material and
Method-Id SHALL be derived from the exporter_secret using the TLS
exporter interface RFC5705 (for TLS 1.3 this is defined in
Section 7.5 of RFC8446).
Draft: draft-ietf-emu-eap-tls13

Commentary: Added text to make sure the client cert is validated before a NST is sent and stated that early data must be ignored : This is to address issue . 
 does this PR address the issue ? 
 yes , thanks . 
 From  's review :
Paragraph (version A):
NewSessionTicket message MUST NOT include an "early_data" extension.
Servers should take into account that fewer newSessionTickets will
likely be needed in EAP-TLS than in the usual HTTPS connection
scenario.  In most cases a single newSessionTicket will be
sufficient.  A mechanism by which clients can specify the desired
number of tickets needed for future connections is defined in I-
D.ietf-tls-ticketrequests.
Paragraph (version B):
NesSessionTicket MUST NOT be sent before the client's certificate has
been validated.  The NewSessionTicket message MUST NOT include an
"early_data" extension.  If the "early_data" extension is received
then it MUST be ignored.  Servers should take into account that fewer
newSessionTickets will likely be needed in EAP-TLS than in the usual
HTTPS connection scenario.  In most cases a single newSessionTicket
will be sufficient.  A mechanism by which clients can specify the
desired number of tickets needed for future connections is defined in
I-D.ietf-tls-ticketrequests.
Draft: draft-ietf-emu-eap-tls13

Commentary: Discuss security implementations of no peer authentication in the authorization section of section 5 . This addresses issue 
 does this PR address this issue ? 
 Yes , thanks . 
 Section 5 should have text discussing the security aspects of " no peer authentication " Perhaps : MUST put users into a limited access network MUST NOT allow resumption Otherwise the unauthenticated users would get open access to secure networks .
Paragraph (version B):
EAP servers will usually require the EAP peer to provide a valid
certificate and will fail the connection if one is not provided.
Some deployments may permit no peer authentication for some or all
connections.  When peer authentication is not used, implementations
MUST take care to limit network access appropriately for
unauthenticated peers and implementations MUST use resumption with
caution to ensure that a resumed session is not granted more
privilege than was intended for the original session.
Draft: draft-ietf-emu-eap-tls13

Commentary: This was discussed and EMU WG IETF 110 . Interop test was done by several implementors during the hackaton . The conclusions was the application data works well as a protected success indication and that close_notify is problematic .   stated that application data will not cause problems for other TLS based EAP methods . The consensus in the WG was to use application data 0x00 as a protected success indication on the EAP - TLS layer . The application data is not controlling the TLS layer . After sending application data ( or any other success indication ) the EAP - TLS can only send EAP - SUCCESS . The working group argued that the IESG and TLS WG resistance against use application data was as it was used in -13 when it promised that no more handshake messages was sent by the TLS layers . The EMU WG hopes and thinks that the IESG and the TLS WG will be ok with the current use of applicaiton data as a protected success indication on the EAP - TLS layer . Additional changes related to this ( protected success and protected failure ) will / is done in the EAP State Machnine PR . 
 There seems to be consensus to use the 0x00 application data as a result indicator for EAP - TLS . See PR 
 Closing as PR is merged
Paragraph (version A):
which is not useful and not expected in EAP-TLS.  The EAP-TLS server
always commits to not send any more handshake messages by sending a
TLS close_notify alert.  After the EAP-TLS server has received an
empty EAP-Response to the EAP-Request containing the TLS close_notify
alert, the EAP-TLS server sends EAP-Success.
Paragraph (version B):
which is not useful and not expected in EAP-TLS.  As a protected
success indication RFC3748 the EAP-TLS server always sends TLS
application data 0x00, see Section 2.5.  Note that a TLS
implementation MAY not allow the EAP-TLS layer to control in which
order things are sent and the application data MAY therefore be sent
before a NewSessionTicket.  TLS application data 0x00 is therefore to
be interpretated as success after the EAP-Request that contains TLS
application data 0x00.  After the EAP-TLS server has received an
empty EAP-Response to the EAP-Request containing the TLS application
data 0x00, the EAP-TLS server sends EAP-Success.
Draft: draft-ietf-emu-eap-tls13

Commentary: Appending things to labels are not agreeing with the IANA registry for labels . Registering labels for each TLS based EAP type would explode the registry . 
 For the historic record , could you also record where this feedback originated from ? 
 This was discussed during EMU WG IETF 110 and the WG consensus was to go back to using context . For the reasons metioned in the first comment , this seemed like the best solution . This is also what has been interoptested ( but implementors stated they they could change if needed . ) The consunsus during the meeting was . Change back to using context If 1 . is not approved by IESG , then registed a larger number of labels with the type code in the label . 
 I think we still need to come to consensus on where the EAP - Type goes If the consensus is label then we need to determine how to incorporate IANA considerations as either a fixed string or reserve a prefix string 
 I thought we had consensus during IETF 110 to use type - code in the context . I had closed and merged PR 
 OK good , I had n't seen the issue close and did n't realize there was a PR associated with it . Closing this as resolved by PR
Paragraph (version A):
A zero-length context (indicated by "") is used in the TLS exporter
interface.  The EAP-TLS Type-Code of '0D' (in hexadecimal) is
appended to the label strings.  Other TLS based EAP methods can use
exporters in a similar fashion by replacing the EAP-TLS Type-Code
with their own Type-Code (encoded as a hexadecimal string).
Paragraph (version B):
Other TLS based EAP methods can use exporters in a similar fashion by
replacing the EAP-TLS Type-Code with their own Type-Code (encoded as
a hexadecimal string).
Draft: draft-ietf-emu-eap-tls13

Commentary: TLS WG has decided to change terminology in TLS 1.2 and TLS 1.3 . The draft is already WG adopted . I suggest we make this change in EAP - TLS 1.3 as well . 
 Looks good to me
Paragraph (version A):
When EAP-TLS is used with TLS version 1.3 or higher the Key_Material,
IV, and Method-Id SHALL be derived from the exporter_master_secret
using the TLS exporter interface RFC5705 (for TLS 1.3 this is defined
in Section 7.5 of RFC8446).
Paragraph (version B):
When EAP-TLS is used with TLS version 1.3 or higher the Key_Material,
IV, and Method-Id SHALL be derived from the exporter_secret using the
TLS exporter interface RFC5705 (for TLS 1.3 this is defined in
Section 7.5 of RFC8446).
Paragraph (version A):
By using the TLS exporter, EAP-TLS can use any TLS 1.3 implementation
without having to extract the Master Secret, ClientHello.random, and
ServerHello.random in a non-standard way.
Paragraph (version B):
By using the TLS exporter, EAP-TLS can use any TLS 1.3 implementation
without having to extract the Main Secret, ClientHello.random, and
ServerHello.random in a non-standard way.
Draft: draft-ietf-emu-eap-tls13

Commentary: This was suggested by several times in the discussion regarding his DISCUSS
Paragraph (version B):
This document specifies EAP-TLS 1.3 and does not specify how other
TLS-based EAP methods use TLS 1.3.  The specification for how other
TLS-based EAP methods use TLS 1.3 is left to other documents such as
I-D.ietf-emu-tls-eap-types.
Paragraph (version A):
Other TLS based EAP methods can use exporters in a similar fashion by
replacing the EAP-TLS Type-Code with their own Type-Code (encoded as
a hexadecimal string).
Paragraph (version B):
Other TLS based EAP methods can use the TLS exporter in a similar
fashion, see I-D.ietf-emu-tls-eap-types.
Draft: draft-ietf-emu-eap-tls13

Commentary:  has provided links to academic paper describing attacks on availability and ask for updates to the draft describing this . The new paragraph do just that . Added that most things can be spoofed was requested by several persons including Security AD  and several TLS people . This was misunderstandings . This is related to the pull request " EAP state machine " 
 This should address issue 
 protected failure indicatioin gives the peer an authenticated way to know that the real server sent the failure . It does little or nothing to improve availability as basically any forged message makes TLS fall hard and fatal . 
 I do n't think there is a way to protect the exchange from injection of errors without doing something more extreme like moving to DTLS . It 's also not clear that even if the method protected against it that many of the lower layers might have equivalent problems . 
 " I do n't think there is a way to protect the exchange from injection of errors " I do n't think so either and think that is fine . I think the important availability goal is that the client and server can try again . I.e. an attacker needs to constantly be active to drop the handshake . I brought this up as  stated that protected failure was important to improve availability . My conclusion is that protected failure does not improve availability as there are other easier was to drop the connection . 
 I agree with  's analysis . I think this can be closed . 
 Looks good to me . We may need to edit to add protected success indications .
Paragraph (version A):
No updates to Section 5.5 of RFC5216.
Paragraph (version B):
As decscribed in RFC3748 and Section 5.5 of RFC5216, the only
information that is integrity and replay protected in EAP-TLS are the
parts of the TLS Data that TLS protects.  All other information in
the EAP-TLS message exchange including EAP-Request and EAP-Response
headers, the identity in the identity response, EAP-TLS packet header
fields, Type, and Flags, EAP-Success, and EAP-Failure can be
modified, spoofed, or replayed.  This section updates Section 5.5 of
RFC5216.
Paragraph (version B):
Protected TLS Error alerts are protected failure result indications
and enables the EAP-TLS peer and EAP-TLS server to determine that the
failure result was not spoofed by an attacker.  Protected failure
result indications provide integrity protection and replay but MAY be
unauthenticated.  Protected failure result does not significantly
improve availability as TLS 1.3 treats most malformed data as a fatal
error.