but uses normal HTTP content negotiation mechanisms for selecting alternatives that endpoints may prefer in anticipation of serving new use cases.  In addition to this media type negotiation, it aligns <del> itself with HTTP features such as caching, proxying, and compression. </del>  The integration with HTTP provides a transport suitable for both traditional DNS clients and native web applications seeking access to 5.  Different response media types will provide more or less information from a DNS response.  For example, one response type might include the information from the DNS header bytes while another might omit

Thats better. Thanks
It would be good to explicitly call out the DNS rcode SERVFAIL as a type of failure response as well, not just NXDOMAIN, as they are very different sorts of failures such that the latter can be considered, in some contexts, as not really a failure.
the merged patch URL no longer mentions specific rcodes at all.. wdyt?
I personally think that as a DNS implementer that there is enough ambiguity around understanding a valid DNS response, a negative answer, and a failure response, that it should be made more painfully clear that something like all DNS servers returning message-valid SERVFAILs still warrants an HTTP 2xx.
Agree with NAME .
will reopen the issue to add more text
largely a restating of mailing list thread: A question on the mix of DNS and HTTP semantics
keep pr but reopen the issue to add a little more text
Liked Martin's rewording for the response text, but removed the security considerations until further discussion. Patrick, please edit or pull.

but uses normal HTTP content negotiation mechanisms for selecting alternatives that endpoints may prefer in anticipation of serving new use cases.  In addition to this media type negotiation, it aligns  <ins> itself with HTTP features such as caching, redirection, proxying, and compression. </ins> The integration with HTTP provides a transport suitable for both traditional DNS clients and native web applications seeking access to 5. <ins> An HTTP response with a 2xx status code (RFC7231 Section 6.3) indicates a valid DNS response to the query made in the HTTP request. A valid DNS response includes both success and failure responses. </ins> Different response media types will provide more or less information from a DNS response.  For example, one response type might include the information from the DNS header bytes while another might omit


untrusted party.  Instead, a client MUST only trust DNS API server that is configured as trustworthy.  9. Local policy considerations and similar factors mean different DNS

If you're ok with the language I think this is ready to go into the draft based on list discussion. (this does imply to has consensus - everything needs consensus, but as a process matter we need to try and channel those discussions into text for consideration.. its open to feedback, of course)
forked off from which deals with error handling, text on what happens if you choose to handle errors in a non doh fashion related to mailing list thread: A question on the mix of DNS and HTTP semantics

untrusted party.  Instead, a client MUST only trust DNS API server that is configured as trustworthy. <ins> A client can use DNS over HTTPS as one of multiple mechanisms to obtain DNS data.  If a client of this protocol encounters an HTTP error after sending a DNS query, and then falls back to a different DNS retrieval mechanism, doing so can weaken the privacy expected by the user of the client. </ins> 9. Local policy considerations and similar factors mean different DNS


Session level encryption has well known weaknesses with respect to traffic analysis which might be particularly acute when dealing with <del> DNS queries.  Sections 10.6 (Compression) and 10.7 (Padding) of RFC7540 provide some further advice on mitigations within an HTTP/2 context. </del>  The HTTPS connection provides transport security for the interaction between the DNS API server and client, but does not inherently ensure

In section 9 of DOH, it makes the following references: This isn't one of the formats that the tools process will convert into deep links. Instead, the "10.6" becomes a link to section 10.6 of DOH (which doesn't exist), while 10.7 doesn't become a link at all.
thanks. ugh.
HTTP/2 provides further advice about the use of compression (see Section 10.6 of [RFC7540]) and padding (Section 10.7 of [RFC7540]). That removes the "mitigations" word.
Fixed in PR

Session level encryption has well known weaknesses with respect to traffic analysis which might be particularly acute when dealing with  <ins> DNS queries.  HTTP/2 provides further advice about the use of compression (Section 10.6 of RFC7540) and padding (Section 10.7 of RFC7540). </ins> The HTTPS connection provides transport security for the interaction between the DNS API server and client, but does not inherently ensure


An HTTP response with a 2xx status code (RFC7231 Section 6.3) indicates a valid DNS response to the query made in the HTTP request. A valid DNS response includes both success and failure responses.  Different response media types will provide more or less information from a DNS response.  For example, one response type might include

intended
largely a restating of mailing list thread: A question on the mix of DNS and HTTP semantics
keep pr but reopen the issue to add a little more text
PRs during meetings iz hArd

An HTTP response with a 2xx status code (RFC7231 Section 6.3) indicates a valid DNS response to the query made in the HTTP request. A valid DNS response includes both success and failure responses. <ins> For example, a DNS failure response such as SERVFAIL or NXDOMAIN will contain a successful HTTP 2xx status code even though there was a failure at the DNS layer.  Responses with non-successful HTTP status codes do not contain DNS answers to the question in the corresponding request.  Some of these non-successful HTTPS responses (such as redirects or authentication failures) could allow clients to make new requests to satisfy the original question. </ins> Different response media types will provide more or less information from a DNS response.  For example, one response type might include


DNSSEC validation of answers received from a DNS API server or it may choose to trust answers from a particular DNS API server, much as a DNS client might choose to trust answers from its recursive DNS <del> resolver. </del>  caching describes the interaction of this protocol with HTTP caching. An adversary that can control the cache used by the client can affect

…dnssec
on list andrew s writes: Section 6 of -03 says this: Different response media types will provide more or less information from a DNS response. For example, one response type might include the information from the DNS header bytes while another might omit it. But section 9 says A DNS API client may also perform full DNSSEC validation of answers received from a DNS API server or it may choose to trust answers from a particular DNS API server, much as a DNS client might choose to trust answers from its recursive DNS resolver. It seems to me that these are in tension with one another, because the AD and CD bits are in the header that the response type is permitted to throw away. Maybe it could be resolved thus: NEW A DNS API client may also perform full DNSSEC validation of answers received from a DNS API server or it may choose to trust answers from a particular DNS API server, much as a DNS client might choose to trust answers from its recursive DNS resolver. This capability might be affected by the response media type a DNS API server supports.

DNSSEC validation of answers received from a DNS API server or it may choose to trust answers from a particular DNS API server, much as a DNS client might choose to trust answers from its recursive DNS  <ins> resolver.  This capability might be affected by the response media type. </ins> caching describes the interaction of this protocol with HTTP caching. An adversary that can control the cache used by the client can affect


4.1. <del> The media type is "application/dns-udpwireformat". </del> The data payload is the DNS on-the-wire format defined in RFC1035.  When using the GET method, the data payload MUST be encoded with base64url RFC4648 and then placed as a name value pair in the query DNS API clients using the DNS wire format MAY have one or more EDNS extensions RFC6891 in the request.  4.2. These examples use HTTP/2 style formatting from RFC7540.

Make clear here that it doesn't intrinsically come with a content-length limit, despite traditional DNS message length limits?
I merged this in a race condition with NAME 's comments. I support that change, but its a little different than the bug that drove this. NAME can you just make the change directly and minimally in this same text?
it could use a preview to help the reader orient herself
See

4.1.  The data payload is the DNS on-the-wire format defined in RFC1035. <ins> The format is for DNS over UDP.  (Note that this is different than the wire format used in RFC7858. </ins> When using the GET method, the data payload MUST be encoded with base64url RFC4648 and then placed as a name value pair in the query DNS API clients using the DNS wire format MAY have one or more EDNS extensions RFC6891 in the request. <ins> The media type is "application/dns-udpwireformat". </ins> 4.2. These examples use HTTP/2 style formatting from RFC7540.


in split DNS configurations RFC6950.  It logically follows that the server which is queried can influence the end result.  Therefore a client's choice of DNS server may affect the responses it gets to its <del> queries. </del>  The HTTPS channel used by this specification establishes secure two party communication between the DNS API Client and the DNS API

wrt mailing list thread DNS64 and DOH andrew sullivan suggests modifying an existing paragraph in operational considerations to have one new sentence: servers may provide different results to the same query: for instance in split DNS configurations [RFC6950]. It logically follows that the server which is queried can influence the end result. Therefore a client's choice of DNS server may affect the responses it gets to its queries. In the case of DNS64 [RFC6147], the choice could affect whether IPv6/IPv4 translation will work at all. in my opinion that's fine. We don't need to enumerate everything, but DNS64 was already called out as a non goal so we might as well note this implication of that.
PR

in split DNS configurations RFC6950.  It logically follows that the server which is queried can influence the end result.  Therefore a client's choice of DNS server may affect the responses it gets to its  <ins> queries.  For example, in the case of DNS64 RFC6147, the choice could affect whether IPv6/IPv4 translation will work at all. </ins> The HTTPS channel used by this specification establishes secure two party communication between the DNS API Client and the DNS API


The Internet does not always provide end to end reachability for native DNS.  On-path network devices may spoof DNS responses, block DNS requests, or just redirect DNS queries to different DNS servers <del> that give less-than-honest answers. </del>  Over time, there have been many proposals for using HTTP and HTTPS as a substrate for DNS queries and responses.  To date, none of those but uses normal HTTP content negotiation mechanisms for selecting alternatives that endpoints may prefer in anticipation of serving new use cases.  In addition to this media type negotiation, it aligns <del> itself with HTTP features such as caching, redirection, proxying, and compression. </del>  The integration with HTTP provides a transport suitable for both traditional DNS clients and native web applications seeking access to 8. Running DNS over HTTPS relies on the security of the underlying HTTP <del> transport.  Implementations utilizing HTTP/2 benefit from the TLS profile defined in RFC7540 Section 9.2. </del>  Session level encryption has well known weaknesses with respect to traffic analysis which might be particularly acute when dealing with

on list jon mattsson points out that we don't mention some pretty key architectural benefits of doh such as authentication, amplification resistance, etc. on list as "changes for draft-ietf-doh-dns-over-https-03". is meant to address this
Hi, following few impressions on advantageous aspects of doh: For sure, the experience aquired in mitigation against hammering attacks on "HTTP" layer is much more effective and well-ruled than DDoS mitigation(s) when comparing to UDP DNS, due to persisting amplification attacks. Many different APIs to expire contents are available on a system layer (Cloudflare, squid, find/rm), many HTTP request headers too on a protocl layer, so shall be widely possible to "control" cache validity with non-DNS methods, when system is responsive (i.e. can take little longer).Compression, modernised with brotli and binary proto.I also sustain the need of a mention to the HEAD method as cache priming or verification method.. Is it desired, interesting, considered any useful by the working group ? (Stephane brought this up to Ben as a bug, but me too I was considering it since ever)Leveraging CDN caches (when atomic, i.e. Etag, CF-ID) is another immediate advantage, but as discussed in the CNAME/A thread there might arise issues with ADDITIONAL/AUTHORITY sections' validity (my implementation used to squeeze the two in one consistent response, which is doable in DNS terms, for the sake of the service... or give shortened responses and iterate trough natural granularity of DNS messaging).Preemptive/ALL caching is less interesting to me personally, but I understand the relatively low effort required by infrastructure to take this extra burden of caching+refreshing it (we now always desire to get the most records at once...). Might state that too, that DNSSEC interactions will require more storage, or more bandwidth, or refer to it.Talking about Auth/Auth, OAuth or all the SSO you can name, are clearly BIG advantages (i.e. refuse some clients or geo-locate/displace others). I was thinking MAC/DAC reasonings were to fall outside of DNS-over-HTTP draft, IMHO... is not a "native" feature of DNS, as-is... what is your opinion ? to me is HTTP.OTOH, a more precise Accounting is a native aspect coming straight out of doh (making accounting easier if ever needed, my old implementation accounted for billing, not a new thing). To me, just because some companies do bill on imprecise Netflow stats, accurate tcpdumps on mirror ports, or even weirder things, doesn't mean DOH cannot state (mention) about "billabilty" at the net of SYN, SYN/ACK, ACK, retransmissions and RESETS :) :)Having a line like: "as any other HTTP dialogue, DNS-over-HTTP might offer possibility to have its usage logged and billed". For some companies it might be a plus, let's not tell them they could have done it with bind or plugins :) Traceability ?Is a mention to logging needed ? (or needs to be implied as any HTTP does?).The detail of the query itself might not be available to authorities via such simplified logs anyway, and that has been made clear during the Hackathon tables anyway, by Olafur regarding POSTs for example. In my previous exp in law enforcment for telco -started with landlines then switched to web- European ISP and hosting providers were obliged/required to provide HTTP and mail logs by investigating authorities (at their own cost of maintenance, law enforcment might be a dead budget for smaller companies). It was 2006, 2009 then 2016 things haven't much improved, just the sensibility towards the topic but not the smoothness of process and guarantee of security in personal/sensible data treatment, in medium companies not just. Many product offer since day 1 full auditing features, FGA in Oracle for example, simple or complex as be, is just matter of using them :( But why DNS traces are not always taken in consideration by all authorities, or everything becomes "best-effort" ? The queries/responses might not be traced/traceable, surely not in post-mortem, only some providers can/do. Not sponsoring any point of view on justice or privacy. ... this for doh is an evolution and an involution: the space needed to account for the long-term-storage might be an argument not to spouse doh. Obviously, filtering out is easy (ct=) By mentioning such aspect(s) we can help answering frequent questions before they're even been asked :+1: As we are realising, mixing the experts from 2 different worlds of DNS and HTTP is not easy, so the more dialectical the best ? With clear examples for sure. I just think that people need to think what is DOH and what does and what doesn't automagically do (extra certificates, extra logs, "slower" but maybe faster, etc) so to be able to compare pros/cons comparing to non HTTP/DNS servers/clients. To me is doh is just a transport thing, and I really like it since many years :) sorry for super long post, will copy this to mailing list if you think is useful.
NAME I agree with almost everything you say, but I don't think the DoH protocol doc is the place to got at all of these things at this length. I'm just trying to give a flavor of the implications of using the http ecosystem - which you go into in much deeper detail. The document has to focus on how you do that. my suggestion would be you raise the concept of a separate applicability/use-case document if you think this is valuable.. you could raise this as part of the charter discussion for DoH. Or you could just work on a really great blog post :)
Thank you NAME I will follow all of your suggestions, just a matter of having some time to say something "useful" and hopefully, possibly correct. I am still willing to follow all of the discussions around the doh topic, I have a lot to learn from all of you, really proud of your consideration. I understand the logic of defining precise specifications and how-to-implement, proper of drafting RFC. I fully support the criteria of "referring to" other standing and specific RFCs by keeping the transversal implications outside of the doc, as it might over-confuse implementors and this is not the goal. Sorry for that, I just wanted to mention some of the possible "arguments" or side-effects (my first time in participating in such exciting discussions and group). My congratulations to all of the working group and supporters, for all the efforts being put into this important draft

The Internet does not always provide end to end reachability for native DNS.  On-path network devices may spoof DNS responses, block DNS requests, or just redirect DNS queries to different DNS servers  <ins> that give less-than-honest answers.  These are also sometimes delivered with poor performance or reduced feature sets. </ins> Over time, there have been many proposals for using HTTP and HTTPS as a substrate for DNS queries and responses.  To date, none of those but uses normal HTTP content negotiation mechanisms for selecting alternatives that endpoints may prefer in anticipation of serving new use cases.  In addition to this media type negotiation, it aligns  <ins> itself with HTTP features such as caching, redirection, proxying, authentication, and compression. </ins> The integration with HTTP provides a transport suitable for both traditional DNS clients and native web applications seeking access to 8. Running DNS over HTTPS relies on the security of the underlying HTTP  <ins> transport.  This mitigates classic amplication attacks for UDP-based DNS.  Implementations utilizing HTTP/2 benefit from the TLS profile defined in RFC7540 Section 9.2. </ins> Session level encryption has well known weaknesses with respect to traffic analysis which might be particularly acute when dealing with


2.5. <del> This is a new section when compared to RFC5216. </del>  TLS 1.3 RFC8446 introduces Post-Handshake messages.  These Post- Handshake messages use the handshake content type and can be sent <del> after the main handshake.  One such Post-Handshake message is NewSessionTicket.  The NewSessionTicket can be used for resumption. After sending TLS Finished, the EAP-TLS server may send any number of Post-Handshake messages in separate EAP-Requests.  To decrease the </del>  uncertainty for the EAP-TLS peer, the following procedure MUST be followed: <del> When an EAP-TLS server has sent its last handshake message (Finished or a Post-Handshake), it commits to not sending any more handshake messages by sending a TLS close_notify alert.  After sending the alert, the EAP-TLS server may only send an EAP-Success or an EAP- Failure.  Using the TLS close_notify however results in an extra EAP- Request and EAP-Response exchange between the peer and the server. </del>  3.

Based on a number of comments from Bernard. This EAP state machine is related to Ben's DISCUSS and the EMU consensus call on alternate status indications and use of close_notify. The update tries to inplement the suggestions from Bernard. The informal RFC 4137 is references but not normatively. Requirement in RFC 3478 to differentiate protected and unprotected result indicators is followed. This pull request is related to the pull requests "Packet Modification Attacks" and "MUST Error alert"
In the dicussion on the commitment message there has been quite a lot of talk about the need for an authenticated signal at the end of the handshake. This has not been discussed before. The -13 commitment message could not be used for that and close notify cannot be used for that. The NewSessionTicket could be used for this. This is a message that acknoledge that the server has accepted the client authentication. it is also a message that can only be sent be the server and not by an on-path attacker. Note that the NewSessionTicket is not cryptographically bound to the Clients second flight, but this is probably not needed. Jorge Vergara wrote that an authenticated signal is probably not needed. "1. I don't see a strict requirement for an authenticated signal at the end of the handshake." This issue is likely related to the newly opened issue of the EAP state machine.
Most of the current discussion in the group is about result indications and not signaling the end of the handshake. I doesn't seem that we need to signal the end of the handshake. The peer should always know how long a flight of messages is even if they are fragmented.
Agree, the protected result indications make any "end of handshake"-indication superfluous.
I think we can close this issue out once we have merged the application data as success indicator.
This will be resolved by merging PR , PR and PR

2.5.  <ins> This is a new section when compared to RFC5216 and only applies to TLS 1.3 (or higher).  RFC4137 offers a proposed state machine for EAP. </ins> TLS 1.3 RFC8446 introduces Post-Handshake messages.  These Post- Handshake messages use the handshake content type and can be sent  <ins> after the main handshake.  Examples of Post-Handshake messages are NewSessionTicket, which is used for resumption and KeyUpdate, which is not useful and not expected in EAP-TLS.  After sending TLS Finished, the EAP-TLS server may send any number of Post-Handshake messages in separate EAP-Requests. To provide a protected success result indication and to decrease the </ins> uncertainty for the EAP-TLS peer, the following procedure MUST be followed:  <ins> 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 a TLS close_notify alert.  The TLS close_notify alert is a protected success result indication, as defined in RFC3748. Implementations follwing RFC4137 sets the alternate indication of success variable altAccept after sending or receiving close_notify. After sending the TLS close_notify alert, the EAP-TLS server may only send an EAP-Success.  The EAP-TLS server MUST NOT send an TLS close_notify alert before it has successfully processed the client finished and sent its last handshake message. TLS Error alerts SHOULD be considered a failure result indication, as defined in RFC3748.  Implementations follwing RFC4137 sets the alternate indication of failure variable altReject after sending or receiving an Error alert.  After sending or receiving a TLS Error alert, the EAP-TLS server may only send an EAP-Failure.  Protected TLS Error alerts are protected failure result indications, unprotected TLS Error alerts are not. The keying material can be derived after the TLS server Finished has been sent or received.  Implementations following RFC4137 can then set the eapKeyData and aaaEapKeyData variables. The keying material can be made available to lower layers and the authenticator after the authenticated success result indication has been sent or received.  Implementations following RFC4137 can set the eapKeyAvailable and aaaEapKeyAvailable variables. </ins> 3.


5.5. <del> No updates to Section 5.5 of RFC5216. </del>  5.6.

Bernard 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 Ben 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 don'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 don't think there is a way to protect the exchange from injection of errors" I don'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 Bernard 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 John's analysis. I think this can be closed.
Looks good to me. We may need to edit to add protected success indications.

5.5.  <ins> 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. 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. </ins> 5.6.


version used).  While this document updates EAP-TLS RFC5216, it remains backwards compatible with it and existing implementations of EAP-TLS.  This document only describes differences compared to <del> RFC5216.  All message flow are specific to TLS 1.3 and do not apply to TLS 1.2. </del>  In addition to the improved security and privacy offered by TLS 1.3, there are other significant benefits of using EAP-TLS with TLS 1.3. empty EAP-Response to the EAP-Request containing the TLS close_notify alert, the EAP-TLS server sends EAP-Success. <del> In the case where EAP-TLS with mutual authentication is successful (and neither HelloRetryRequest nor Post-Handshake messages are sent) the conversation will appear as shown in figbase1. </del>  2.1.2. tickets needed for future connections is defined in I-D.ietf-tls- ticketrequests. <del> In the case where EAP-TLS with mutual authentication and ticket establishment with two tickets is successful, the conversation will appear as shown in figbase2. </del>  2.1.3. is therefore in general unsuitable for deriving a NAI to use in the Identity Response. <del> A subsequent successful resumption handshake where both sides authenticate via a PSK provisioned via an earlier NewSessionTicket and where the server provisions a single new ticket is shown in figresumption. A subsequent successful resumption handshake where both sides authenticate via a PSK provisioned via an earlier NewSessionTicket and where the server does not provision any new tickets is shown in figresumption2. </del>  As specified in Section 2.2 of RFC8446, the EAP-TLS peer SHOULD supply a "key_share" extension when attempting resumption, which "user_cancelled", both of which indicate that the connection is not going to continue normally, see RFC8446. <del> In the case where the EAP-TLS server rejects the ClientHello with a fatal error, the conversation will appear as shown in figterm1.  The EAP-TLS server can also partly reject the ClientHello with a HelloRetryRequest, see helloretry. </del>  <del> In the case where EAP-TLS server authentication is unsuccessful, the conversation will appear as shown in figterm2. </del>  <del> In the case 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, the conversation will appear as shown in figterm3. </del>  2.1.5. This is a new section when compared to RFC5216. <del> In the case where EAP-TLS is used without peer authentication (e.g., emergency services, as described in RFC7406) the conversation will appear as shown in figbase3. </del>  2.1.6. "supported_groups" extension.  In this case the client should send a new ClientHello with a "key_share" that the EAP-TLS server supports. <del> The case of a successful EAP-TLS mutual authentication after the EAP- TLS server has sent a HelloRetryRequest message is shown in fighelloretryrequest.  Note the extra round-trip as a result of the </del>  HelloRetryRequest. 2.1.7.

Some of the text describing the figures indicated that TLS 1.3 only has one possible message flow. This pull request change the text to make it is clear that the message flows are examples. Based on discussion on the List initiated by Alan.

version used).  While this document updates EAP-TLS RFC5216, it remains backwards compatible with it and existing implementations of EAP-TLS.  This document only describes differences compared to  <ins> RFC5216.  All message flow are example message flows specific to TLS 1.3 and do not apply to TLS 1.2. </ins> In addition to the improved security and privacy offered by TLS 1.3, there are other significant benefits of using EAP-TLS with TLS 1.3. empty EAP-Response to the EAP-Request containing the TLS close_notify alert, the EAP-TLS server sends EAP-Success.  <ins> figbase1 shows an example message flow for a succesfull EAP-TLS full handshake with mutual authentication (and neither HelloRetryRequest nor Post-Handshake messages are sent). </ins> 2.1.2. tickets needed for future connections is defined in I-D.ietf-tls- ticketrequests.  <ins> figbase2 shows an example message flow for a succesfull EAP-TLS full handshake with mutual authentication and ticket establishment of a single ticket. </ins> 2.1.3. is therefore in general unsuitable for deriving a NAI to use in the Identity Response.  <ins> figresumption shows an example message flow for a subsequent succesfull EAP-TLS resumption handshake where both sides authenticate via a PSK provisioned via an earlier NewSessionTicket and where the server provisions a single new ticket. </ins> As specified in Section 2.2 of RFC8446, the EAP-TLS peer SHOULD supply a "key_share" extension when attempting resumption, which "user_cancelled", both of which indicate that the connection is not going to continue normally, see RFC8446.  <ins> figterm1 shows an example message flow where the EAP-TLS server rejects the ClientHello with a Error alert.  The EAP-TLS server can also partly reject the ClientHello with a HelloRetryRequest, see helloretry. </ins>  <ins> figterm2 shows an example message flow where EAP-TLS server authentication is unsuccessful and the EAP-TLS peer sends a TLS Error alert. </ins>  <ins> 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. </ins> 2.1.5. This is a new section when compared to RFC5216.  <ins> figbase3 shows an example message flow for a succesfull EAP-TLS full handshake without peer authentication (e.g., emergency services, as described in RFC7406). </ins> 2.1.6. "supported_groups" extension.  In this case the client should send a new ClientHello with a "key_share" that the EAP-TLS server supports.  <ins> fighelloretryrequest shows an example message flow for a succesfull EAP-TLS full handshake with mutual authentication and HelloRetryRequest.  Note the extra round-trip as a result of the </ins> HelloRetryRequest. 2.1.7.


This is a new section when compared to RFC5216. To enable resumption when using EAP-TLS with TLS 1.3, the EAP-TLS <del> server MUST send one or more NewSessionTicket messages (each containing a PSK, a PSK identity, a ticket lifetime, and other parameters) in the initial authentication.  Note that TLS 1.3 RFC8446 limits the ticket lifetime to a maximum of 604800 seconds (7 days) and EAP-TLS servers MUST respect this upper limit when issuing </del>  tickets.  The NewSessionTicket is sent after the EAP-TLS server has received the client Finished message in the initial authentication. <del> The PSK associated with the ticket depends on the client Finished and cannot be pre-computed in handshakes with client authentication.  The NesSessionTicket MUST NOT be sent before the client's certificate has been validated.  The NewSessionTicket message MUST NOT include an </del>  "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 TLS 1.3 replaces the session resumption mechanisms in earlier versions of TLS with a new PSK exchange.  When EAP-TLS is used with TLS version 1.3, EAP-TLS SHALL use a resumption mechanism compatible <del> with that version of TLS. </del>  For TLS 1.3, resumption is described in Section 2.2 of RFC8446.  If the client has received a NewSessionTicket message from the EAP-TLS <del> server, the client can use the PSK identity received in the ticket to negotiate the use of the associated PSK.  If the EAP-TLS server accepts it, then the security context of the new connection is tied to the original connection and the key derived from the initial </del>  handshake is used to bootstrap the cryptographic state instead of a full handshake.  It is up to the EAP-TLS peer whether to offer resumption, ut it is RECOMMENDED that the EAP-TLS peer offer

During dicsussion on close_notify, there was a good dicusssion on the list on why resumption is needed. Some short clarifications on how TLS 1.3 works. E.g. that PSK is not included in the ticket.

This is a new section when compared to RFC5216. To enable resumption when using EAP-TLS with TLS 1.3, the EAP-TLS  <ins> server MUST send one or more Post-Handshake NewSessionTicket messages (each associated with a PSK, a PSK identity, a ticket lifetime, and other parameters) in the initial authentication.  Note that TLS 1.3 RFC8446 limits the ticket lifetime to a maximum of 604800 seconds (7 days) and EAP-TLS servers MUST respect this upper limit when issuing </ins> tickets.  The NewSessionTicket is sent after the EAP-TLS server has received the client Finished message in the initial authentication.  <ins> The NewSessionTicket can be sent in the same flight as the TLS server Finished or later.  The PSK associated with the ticket depends on the client Finished and cannot be pre-computed in handshakes with client authentication.  The NewSessionTicket message MUST NOT include an </ins> "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 TLS 1.3 replaces the session resumption mechanisms in earlier versions of TLS with a new PSK exchange.  When EAP-TLS is used with TLS version 1.3, EAP-TLS SHALL use a resumption mechanism compatible  <ins> with that version of TLS.  EAP-TLS is typically used with client authentication and typically fragments the TLS flights into a large number of EAP requests and EAP responses.  Resumption significantly reduces the number of round-trips and enables the EAP-TLS server to omit database lookups needed during a full handshake with client authentication. </ins> For TLS 1.3, resumption is described in Section 2.2 of RFC8446.  If the client has received a NewSessionTicket message from the EAP-TLS  <ins> server, the client can use the PSK identity associated with the ticket to negotiate the use of the associated PSK.  If the EAP-TLS server accepts it, then the security context of the new connection is tied to the original connection and the key derived from the initial </ins> handshake is used to bootstrap the cryptographic state instead of a full handshake.  It is up to the EAP-TLS peer whether to offer resumption, ut it is RECOMMENDED that the EAP-TLS peer offer


Figures figterm1, figterm2, and figterm3 illustrate message flows in several cases where the EAP-TLS peer or EAP-TLS server sends a TLS <del> fatal alert message.  In earlier versions of TLS, error alerts could be warnings or fatal.  In TLS 1.3, error alerts are always fatal and </del>  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.  figterm1 shows an example message flow where the EAP-TLS server rejects the ClientHello with a Error alert.  The EAP-TLS server can also partly reject the ClientHello with a HelloRetryRequest, see

Added text based on suggestions from Alan
Alan suggests to make them MUST RFC 8446 states optionally or SHOULD
I implemented MUST Error in a pull request. Alan "I would suggest instead that it MUST send the TLS alert before any EAP-Failure." John: This would require also mandating user_cancelled.....
To make a practical difference I think we need to follow Alans suggestion and mandate a protected failure indication before EAP-Failure. Looking at RFC 8446 it looks like TLS 1.3 can terminate a connection by: Not sending any alert Sending an Error alert Sending closenotify Sending usercancelled Sending usercancelled followed by closenotify (It would also not suprise me if some implementation sends an Error alert followed by closenotify). It seems a bit complicated to use alerts as both failure and success indications. To make it work I think EAP-TLS 1.3 needs to: Forbid all use of usercancelled Forbid closenotify except as success indication Mandate Error alert before EAP-Failure Do implementors and TLS people agree that is possible? Alternativeley Forbid closenotify except as success indication Mandate Error alert or user_cancelled before EAP-Failure
I expect John already knows, but to link the github issues, there is some discussion at URL about "user_cancelled" and how some implementations don't really adhere to the text of 8446.
Any error alert set from the server should be treated as a failure signal regardless of what other information may be present. I think a user_cancelled alert should be treated in the same way ( although I'm not sure there is reason for a server to send it so perhaps it should not be allowed). Any error alert or user cancelled from the peer should be treated as a failure indication from the peer and the server should respond with an EAP Failure. Note: In it is possible for the peer to send a client hello after receiving an alert from the server to restart the conversation. I'm not sure that this changes anything.
"Any error alert or user cancelled from the peer should be treated as a failure indication from the peer and the server should respond with an EAP Failure." Yes, or "any alert should be treated as a failure indication" if we go with application data as a success indication. "Note: In 5216 it is possible for the peer to send a client hello after receiving an alert from the server to restart the conversation. I'm not sure that this changes anything." That's a good observation. Not sure we can allow that with TLS 1.3 if an alert is an failure indication. BTW, my view is that draft-ietf-emu-eap-tls13 introduces protected result indicators when TLS 1.3 is used and does not update RFC 5216 with protected results when TLS 1.2 is used. I don't think this has not been clearly stated in the discussion. If somebody have a different view it would be good to know asap.
Correct, we should not change the behavior of 5216
This is resolved in PR
In the dicussion on the commitment message there has been quite a lot of talk about the need for an authenticated signal at the end of the handshake. This has not been discussed before. The -13 commitment message could not be used for that and close notify cannot be used for that. The NewSessionTicket could be used for this. This is a message that acknoledge that the server has accepted the client authentication. it is also a message that can only be sent be the server and not by an on-path attacker. Note that the NewSessionTicket is not cryptographically bound to the Clients second flight, but this is probably not needed. Jorge Vergara wrote that an authenticated signal is probably not needed. "1. I don't see a strict requirement for an authenticated signal at the end of the handshake." This issue is likely related to the newly opened issue of the EAP state machine.
Most of the current discussion in the group is about result indications and not signaling the end of the handshake. I doesn't seem that we need to signal the end of the handshake. The peer should always know how long a flight of messages is even if they are fragmented.
Agree, the protected result indications make any "end of handshake"-indication superfluous.
I think we can close this issue out once we have merged the application data as success indicator.
This will be resolved by merging PR , PR and PR

Figures figterm1, figterm2, and figterm3 illustrate message flows in several cases where the EAP-TLS peer or EAP-TLS server sends a TLS  <ins> 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 </ins> 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. <ins> In TLS 1.3 RFC8446, Error alerts are not mandatory to send after a fatal error condition.  Failure to send TLS Error alerts means that the peer or server would have no way of determining what went wrong. EAP-TLS 1.3 strengthen this requirement.  Whenever an implementation encounters a fatal error condition, it MUST send an appropriate TLS Error alert. </ins> figterm1 shows an example message flow where the EAP-TLS server rejects the ClientHello with a Error alert.  The EAP-TLS server can also partly reject the ClientHello with a HelloRetryRequest, see


1.3 the key schedule is described in Section 7.1 of RFC8446. When EAP-TLS is used with TLS version 1.3 or higher the Key_Material, <del> 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). </del>  A zero-length context (indicated by "") is used in the TLS exporter interface.  The EAP-TLS Type-Code of '0D' (in hexadecimal) is above keying material. By using the TLS exporter, EAP-TLS can use any TLS 1.3 implementation <del> without having to extract the Master Secret, ClientHello.random, and </del>  ServerHello.random in a non-standard way. 2.4.

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

1.3 the key schedule is described in Section 7.1 of RFC8446. When EAP-TLS is used with TLS version 1.3 or higher the Key_Material,  <ins> 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). </ins> A zero-length context (indicated by "") is used in the TLS exporter interface.  The EAP-TLS Type-Code of '0D' (in hexadecimal) is above keying material. By using the TLS exporter, EAP-TLS can use any TLS 1.3 implementation  <ins> without having to extract the Main Secret, ClientHello.random, and </ins> ServerHello.random in a non-standard way. 2.4.


TLS exporter interface RFC5705 (for TLS 1.3 this is defined in Section 7.5 of RFC8446). <del> 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). </del>  RFC5247 deprecates the use of IV.  Thus, RECV-IV and SEND-IV are not exported in EAP-TLS with TLS 1.3.  As noted in RFC5247, lower layers

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. URL 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.) URL 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 Label Context 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 hadn't seen the issue close and didn't realize there was a PR associated with it. Closing this as resolved by PR

TLS exporter interface RFC5705 (for TLS 1.3 this is defined in Section 7.5 of RFC8446).  <ins> 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). </ins> RFC5247 deprecates the use of IV.  Thus, RECV-IV and SEND-IV are not exported in EAP-TLS with TLS 1.3.  As noted in RFC5247, lower layers


EAP-TLS, see Section 4.2.10 of RFC8446 for additional information of the "early_data" extension.  Resumption is handled as described in resumption.  TLS 1.3 introduced the Post-Handshake KeyUpdate message <del> 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. </del>  figbase1 shows an example message flow for a succesfull EAP-TLS full handshake with mutual authentication (and neither HelloRetryRequest

This was discussed and EMU WG IETF 110. URL URL 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. Alan DeKok 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

EAP-TLS, see Section 4.2.10 of RFC8446 for additional information of the "early_data" extension.  Resumption is handled as described in resumption.  TLS 1.3 introduced the Post-Handshake KeyUpdate message  <ins> 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. </ins> figbase1 shows an example message flow for a succesfull EAP-TLS full handshake with mutual authentication (and neither HelloRetryRequest


section is relevant for EAP-TLS in general (regardless of the underlying TLS version used).  EAP-TLS is typically encapsulated in other protocols, such as PPP RFC1661, RADIUS RFC2865, Diameter RFC6733, or PANA RFC5191.  The encapsulating protocols can also provide additional, non-EAP

Discuss security implementations of no peer authentication in the authorization section of section 5. This addresses issue
NAME 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.

section is relevant for EAP-TLS in general (regardless of the underlying TLS version used). <ins> 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. </ins> EAP-TLS is typically encapsulated in other protocols, such as PPP RFC1661, RADIUS RFC2865, Diameter RFC6733, or PANA RFC5191.  The encapsulating protocols can also provide additional, non-EAP


privacy handling, and key derivation need to be appropriately addressed for EAP-TLS with TLS 1.3 (or higher). <del> This document defines how to use EAP-TLS with TLS 1.3 (or higher) and does not change how EAP-TLS is used with older versions of TLS.  It does however provide additional guidance on authorization and resumption for EAP-TLS in general (regardless of the underlying TLS version used).  While this document updates EAP-TLS RFC5216, it remains backwards compatible with it and existing implementations of EAP-TLS.  This document only describes differences compared to RFC5216.  All message flow are example message flows specific to TLS 1.3 and do not apply to TLS 1.2. </del>  In addition to the improved security and privacy offered by TLS 1.3, there are other significant benefits of using EAP-TLS with TLS 1.3. After receiving an EAP-Request packet with EAP-Type=EAP-TLS as described in RFC5216 the conversation will continue with the TLS handshake protocol encapsulated in the data fields of EAP-Response <del> and EAP-Request packets.  When EAP-TLS is used with TLS version 1.3 or higher, the formatting and processing of the TLS handshake SHALL be done as specified in that version of TLS.  This document only lists additional and different requirements, restrictions, and processing compared to RFC8446 and RFC5216. </del>  2.1.1. TLS 1.3 replaces the session resumption mechanisms in earlier versions of TLS with a new PSK exchange.  When EAP-TLS is used with <del> TLS version 1.3 or higher, EAP-TLS SHALL use a resumption mechanism compatible with that version of TLS. </del>  For TLS 1.3, resumption is described in Section 2.2 of RFC8446.  If the client has received a NewSessionTicket message from the EAP-TLS compared to earlier versions of TLS.  Therefore, some normative text in Section 2.1.3 of RFC5216 does not apply for TLS 1.3 or higher. The two paragraphs below replaces the corresponding paragraphs in <del> Section 2.1.3 of RFC5216 when EAP-TLS is used with TLS 1.3 or higher. The other paragraphs in Section 2.1.3 of RFC5216 still apply with the </del>  exception that SessionID is deprecated. If the EAP-TLS peer authenticates successfully, the EAP-TLS server and encrypting large parts of the TLS handshake including the certificate messages. <del> EAP-TLS peer and server implementations supporting TLS 1.3 or higher MUST support anonymous NAIs (Network Access Identifiers) (Section 2.4 in RFC7542) and a client supporting TLS 1.3 MUST NOT send its username in cleartext in the Identity Response.  Following RFC7542, it is RECOMMENDED to omit the username (i.e., the NAI is @realm), but other constructions such as a fixed username (e.g. anonymous@realm) or an encrypted username (e.g., </del>  xCZINCPTK5+7y81CrSYbPg+RKPE3OTrYLn4AQc4AC2U=@realm) are allowed. Note that the NAI MUST be a UTF-8 string as defined by the grammar in Section 2.2 of RFC7542. As the certificate messages in TLS 1.3 are encrypted, there is no need to send an empty certificate_list and perform a second handshake for privacy (as needed by EAP-TLS with earlier versions of TLS). <del> When EAP-TLS is used with TLS version 1.3 or higher the EAP-TLS peer and EAP-TLS server SHALL follow the processing specified by the used version of TLS.  For TLS 1.3 this means that the EAP-TLS peer only sends an empty certificate_list if it does not have an appropriate certificate to send, and the EAP-TLS server MAY treat an empty certificate_list as a terminal condition. </del>  EAP-TLS with TLS 1.3 is always used with privacy.  This does not add any extra round-trips and the message flow with privacy is just the correct when EAP-TLS is used with TLS version 1.3 or higher.  For TLS 1.3 the key schedule is described in Section 7.1 of RFC8446. <del> 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 </del>  Section 7.5 of RFC8446). Other TLS based EAP methods can use exporters in a similar fashion by

Explain that the next version of TLS may not be compatible with this document. Remove "or higher" in several sections. This addresses issue
NAME does this commit address Issue ?
As an implementor, I'm not sure what it means to "automatically support" or "not automatically support" something. It's not clear to me what I do with that recommendation. I think it's best to make an explicit statement that That statement gives clear direction on exactly what to do. i.e. there are APIs to "limit the maximum TLS version". So I know what that phrase means. There are no APIs to "not automatically support" something. So I don't know what that phrase means, or what I should do in order to satisfy its' requirements. The rest of the changes are fine.
Thanks, I updated the text.
From Alan's review: Suggestion: remove all "or higher" text. Add in text which says that by default, EAP-TLS 1.3 implementations MUST limit the maximum TLS version to 1.3, unless later versions are explicitly enabled by the administrator.
It would help implementors to understand why this restriction is there. i.e. instead of just saying "use TLS 1.3", it would be good to note something like:

privacy handling, and key derivation need to be appropriately addressed for EAP-TLS with TLS 1.3 (or higher).  <ins> This document defines how to use EAP-TLS with TLS 1.3 and does not change how EAP-TLS is used with older versions of TLS.  It does however provide additional guidance on authorization and resumption for EAP-TLS in general (regardless of the underlying TLS version used).  While this document updates EAP-TLS RFC5216, it remains backwards compatible with it and existing implementations of EAP-TLS. This document only describes differences compared to RFC5216.  All message flow are example message flows specific to TLS 1.3 and do not apply to TLS 1.2.  Since EAP-TLS couples the TLS handshake state machine with the EAP state machine it is possible that new versions of TLS will cause incompatibilities that introduce failures or security issues if they are not carefully imtegrated into the EAP-TLS protocol.  Therefore, implementations MUST limit the maximum TLS version they use to 1.3, unless later versions are explicitly enabled by the administrator. </ins> In addition to the improved security and privacy offered by TLS 1.3, there are other significant benefits of using EAP-TLS with TLS 1.3. After receiving an EAP-Request packet with EAP-Type=EAP-TLS as described in RFC5216 the conversation will continue with the TLS handshake protocol encapsulated in the data fields of EAP-Response  <ins> and EAP-Request packets.  When EAP-TLS is used with TLS version 1.3, the formatting and processing of the TLS handshake SHALL be done as specified in that version of TLS.  This document only lists additional and different requirements, restrictions, and processing compared to RFC8446 and RFC5216. </ins> 2.1.1. TLS 1.3 replaces the session resumption mechanisms in earlier versions of TLS with a new PSK exchange.  When EAP-TLS is used with  <ins> TLS version 1.3, EAP-TLS SHALL use a resumption mechanism compatible with that version of TLS. </ins> For TLS 1.3, resumption is described in Section 2.2 of RFC8446.  If the client has received a NewSessionTicket message from the EAP-TLS compared to earlier versions of TLS.  Therefore, some normative text in Section 2.1.3 of RFC5216 does not apply for TLS 1.3 or higher. The two paragraphs below replaces the corresponding paragraphs in  <ins> Section 2.1.3 of RFC5216 when EAP-TLS is used with TLS 1.3.  The other paragraphs in Section 2.1.3 of RFC5216 still apply with the </ins> exception that SessionID is deprecated. If the EAP-TLS peer authenticates successfully, the EAP-TLS server and encrypting large parts of the TLS handshake including the certificate messages.  <ins> EAP-TLS peer and server implementations supporting TLS 1.3 MUST support anonymous NAIs (Network Access Identifiers) (Section 2.4 in RFC7542) and a client supporting TLS 1.3 MUST NOT send its username in cleartext in the Identity Response.  Following RFC7542, it is RECOMMENDED to omit the username (i.e., the NAI is @realm), but other constructions such as a fixed username (e.g. anonymous@realm) or an encrypted username (e.g., </ins> xCZINCPTK5+7y81CrSYbPg+RKPE3OTrYLn4AQc4AC2U=@realm) are allowed. Note that the NAI MUST be a UTF-8 string as defined by the grammar in Section 2.2 of RFC7542. As the certificate messages in TLS 1.3 are encrypted, there is no need to send an empty certificate_list and perform a second handshake for privacy (as needed by EAP-TLS with earlier versions of TLS).  <ins> When EAP-TLS is used with TLS version 1.3 the EAP-TLS peer and EAP- TLS server SHALL follow the processing specified by the used version of TLS.  For TLS 1.3 this means that the EAP-TLS peer only sends an empty certificate_list if it does not have an appropriate certificate to send, and the EAP-TLS server MAY treat an empty certificate_list as a terminal condition. </ins> EAP-TLS with TLS 1.3 is always used with privacy.  This does not add any extra round-trips and the message flow with privacy is just the correct when EAP-TLS is used with TLS version 1.3 or higher.  For TLS 1.3 the key schedule is described in Section 7.1 of RFC8446.  <ins> 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 </ins> Section 7.5 of RFC8446). Other TLS based EAP methods can use exporters in a similar fashion by


received the client Finished message in the initial authentication. The PSK associated with the ticket depends on the client Finished and cannot be pre-computed in handshakes with client authentication.  The <del> 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. </del>  figbase2 shows an example message flow for a succesfull EAP-TLS full handshake with mutual authentication and ticket establishment of a

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 .
NAME does this PR address the issue?
yes, thanks.
From Alan's review: >

received the client Finished message in the initial authentication. The PSK associated with the ticket depends on the client Finished and cannot be pre-computed in handshakes with client authentication.  The  <ins> 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. </ins> figbase2 shows an example message flow for a succesfull EAP-TLS full handshake with mutual authentication and ticket establishment of a


<del> Using EAP-TLS with TLS 1.3 </del>  draft-ietf-emu-eap-tls13-latest Abstract 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 <del> 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 </del>  authorization and resumption for EAP-TLS in general (regardless of the underlying TLS version used).  This document updates RFC 5216.

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
Hi John, 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

<ins> Using EAP-TLS with TLS 1.3 (EAP-TLS 1.3) </ins> draft-ietf-emu-eap-tls13-latest Abstract 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  <ins> compared to earlier versions of TLS.  EAP-TLS with TLS 1.3 (EAP-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 </ins> authorization and resumption for EAP-TLS in general (regardless of the underlying TLS version used).  This document updates RFC 5216.


In addition to the improved security and privacy offered by TLS 1.3, there are other significant benefits of using EAP-TLS with TLS 1.3. <del> Privacy, which in EAP-TLS means that the peer username is not disclosed, is mandatory and achieved without any additional round- trips.  Revocation checking is mandatory and simplified with OCSP stapling, and TLS 1.3 introduces more possibilities to reduce fragmentation when compared to earlier versions of TLS. </del>  This document follows the terminology from I-D.ietf-tls-rfc8446bis where the master secret is renamed to the main secret and the TLS 1.3 changes both the message flow and the handshake messages compared to earlier versions of TLS.  Therefore, much of Section 2.1 <del> of RFC5216 does not apply for TLS 1.3. </del>  After receiving an EAP-Request packet with EAP-Type=EAP-TLS as described in RFC5216 the conversation will continue with the TLS the client has received a NewSessionTicket message from the EAP-TLS server, the client can use the PSK identity associated with the ticket to negotiate the use of the associated PSK.  If the EAP-TLS <del> server accepts it, then the security context of the new connection is tied to the original connection and the key derived from the initial handshake is used to bootstrap the cryptographic state instead of a full handshake.  It is up to the EAP-TLS peer to use resumption, but it is RECOMMENDED that the EAP-TLS peer use resumption if it has a valid ticket that has not been used before.  It is left to the EAP- TLS server whether to accept resumption, but it is RECOMMENDED that the EAP-TLS server accept resumption if the ticket which was issued is still valid.  However, the EAP-TLS server MAY choose to require a full handshake.  As in a full handshake, sending a NewSessionTicket during resumption is optional.  As described in Appendix C.4 of RFC8446, reuse of a ticket allows passive observers to correlate different connections.  EAP-TLS peers and EAP-TLS servers SHOULD follow the client tracking preventions in Appendix C.4 of RFC8446. </del>  It is RECOMMENDED to use a Network Access Identifiers (NAIs) with the same realm during resumption and the original full handshake.  This above keying material. By using the TLS exporter, EAP-TLS can use any TLS 1.3 implementation <del> without having to extract the Main Secret, ClientHello.random, and ServerHello.random in a non-standard way. </del>  2.4. There are a number of security issues related to resumption that are not described in RFC5216.  The problems, guidelines, and requirements <del> in this section therefore applies to all version of TLS. </del>  When resumption occurs, it is based on cached information at the TLS layer.  To perform resumption in a secure way, the EAP-TLS peer and

The PR only fixed some of Alan's comments. I updated the PR to address all Alan's comments that was copied in the issue
From Alan's review: >
Also >
Looks good to merge

In addition to the improved security and privacy offered by TLS 1.3, there are other significant benefits of using EAP-TLS with TLS 1.3.  <ins> Privacy, which in EAP-TLS means that no information about the underlying peer identity is disclosed, is mandatory and achieved without any additional round-trips.  Revocation checking is mandatory and simplified with OCSP stapling, and TLS 1.3 introduces more possibilities to reduce fragmentation when compared to earlier versions of TLS. </ins> This document follows the terminology from I-D.ietf-tls-rfc8446bis where the master secret is renamed to the main secret and the TLS 1.3 changes both the message flow and the handshake messages compared to earlier versions of TLS.  Therefore, much of Section 2.1  <ins> of RFC5216 does not apply for TLS 1.3.  EAP-TLS 1.3 remains backwards compatible with EAP-TLS 1.2 RFC5216 . TLS version negotiation is handled by the TLS layer, and thus outside of the scope of EAP-TLS. Therefore so long as the underlying TLS implementation correctly implements TLS version negotiation, EAP-TLS will automatically leverage that capability. </ins> After receiving an EAP-Request packet with EAP-Type=EAP-TLS as described in RFC5216 the conversation will continue with the TLS the client has received a NewSessionTicket message from the EAP-TLS server, the client can use the PSK identity associated with the ticket to negotiate the use of the associated PSK.  If the EAP-TLS  <ins> server accepts it, then the resumed session has been deemed to be authenticated, and securely tied to the associated with the prior authentication or resumption.  It is up to the EAP-TLS peer to use resumption, but it is RECOMMENDED that the EAP-TLS peer use resumption if it has a valid ticket that has not been used before. It is left to the EAP-TLS server whether to accept resumption, but it is RECOMMENDED that the EAP-TLS server accept resumption if the ticket which was issued is still valid.  However, the EAP-TLS server MAY choose to require a full handshake.  In the case a full handshake is required, the negotiation proceeds as if the session was a new authentication, and resumption had never been requested.  The requirements of Sections section_auth and ticket then apply in their entirety.  As described in Appendix C.4 of RFC8446, reuse of a ticket allows passive observers to correlate different connections.  EAP-TLS peers and EAP-TLS servers SHOULD follow the client tracking preventions in Appendix C.4 of RFC8446. </ins> It is RECOMMENDED to use a Network Access Identifiers (NAIs) with the same realm during resumption and the original full handshake.  This above keying material. By using the TLS exporter, EAP-TLS can use any TLS 1.3 implementation  <ins> which provides a public API for the exporter.  Note that EAP-TLS with TLS 1.2 RFC5216 can be used with the TLS exporter since the public exporter was defined in RFC5705. </ins> 2.4. There are a number of security issues related to resumption that are not described in RFC5216.  The problems, guidelines, and requirements  <ins> in this section therefore applies to EAP-TLS when it is used with any version of TLS. </ins> When resumption occurs, it is based on cached information at the TLS layer.  To perform resumption in a secure way, the EAP-TLS peer and


stapling, and TLS 1.3 introduces more possibilities to reduce fragmentation when compared to earlier versions of TLS.  1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 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.  2. 2.1.

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. URL 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 URL 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.

stapling, and TLS 1.3 introduces more possibilities to reduce fragmentation when compared to earlier versions of TLS. <ins> 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. </ins> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 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. <ins> 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. </ins> 2. 2.1.


figbase1 shows an example message flow for a successful EAP-TLS full handshake with mutual authentication (and neither HelloRetryRequest <del> nor Post-Handshake messages are sent). </del>  2.1.2. This is a new section when compared to RFC5216. To enable resumption when using EAP-TLS with TLS 1.3, the EAP-TLS <del> server MUST send one or more Post-Handshake NewSessionTicket messages </del>  (each associated with a PSK, a PSK identity, a ticket lifetime, and other parameters) in the initial authentication.  Note that TLS 1.3 RFC8446 limits the ticket lifetime to a maximum of 604800 seconds (7 TLS 1.3 changes both the message flow and the handshake messages compared to earlier versions of TLS.  Therefore, some normative text in Section 2.1.3 of RFC5216 does not apply for TLS 1.3.  The two <del> paragraphs below replaces the corresponding paragraphs in </del>  Section 2.1.3 of RFC5216 when EAP-TLS is used with TLS 1.3.  The other paragraphs in Section 2.1.3 of RFC5216 still apply with the exception that SessionID is deprecated. This is a new section when compared to RFC5216 and only applies to TLS 1.3.  RFC4137 offers a proposed state machine for EAP. <del> TLS 1.3 RFC8446 introduces Post-Handshake messages.  These Post- Handshake messages use the handshake content type and can be sent after the main handshake.  Examples of Post-Handshake messages are </del>  NewSessionTicket, which is used for resumption and KeyUpdate, which is not useful and not expected in EAP-TLS.  After sending TLS <del> Finished, the EAP-TLS server may send any number of Post-Handshake </del>  messages in separate EAP-Requests. To provide a protected success result indication and to decrease the followed: When an EAP-TLS server has successfully processed the TLS client <del> 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 </del>  protected success result indication, as defined in RFC3748.  After <del> sending a EAP-Request that contains the protected success result </del>  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 layer.  To perform resumption in a secure way, the EAP-TLS peer and EAP-TLS server need to be able to securely retrieve authorization information such as certificate chains from the initial full <del> handshake.  This document use the term "cached data" to describe such information.  Authorization during resumption MUST be based on such cached data.  The EAP-TLS peer and EAP-TLS server MAY perform fresh revocation checks on the cached certificate data.  Any security </del>  policies for authorization MUST be followed also for resumption.  The certificates may have been revoked since the initial full handshake and the authorizations of the other party may have reduced.  If the

Hi! I performed a second AD review on draft-ietf-emu-eap-tls13. This time on -18. Thank you to the authors, the responsible co-chair, and the WG for all of the work to redesign the -13 protocol in response to the initial IESG review in December 2020. My review feedback consists of my own minimal additional comments and highlights of where previously stated IESG ballot items do not appear to be responded to or addressed. All items appear to be minor. ** Section 2.4. Previously, this text referenced TLS 1.3 or higher necessitating more ambiguous reference to version numbers. However, now the text only notes TLS 1.3. OLD When EAP-TLS is used with TLS version 1.3, the EAP-TLS peers and EAP- TLS servers MUST comply with the compliance requirements (mandatory- to-implement cipher suites, signature algorithms, key exchange algorithms, extensions, etc.) for the TLS version used. For TLS 1.3 the compliance requirements are defined in Section 9 of [RFC8446]. NEW When EAP-TLS is used with TLS version 1.3, the EAP-TLS peers and EAP-TLS servers MUST comply with the compliance requirements (mandatory- to-implement cipher suites, signature algorithms, key exchange algorithms, extensions, etc.) defined in Section 9 of [RFC8446]. ==[ COMMENT (Ben Kaduk) Section 2.1.4 The two paragraphs below replaces the corresponding paragraphs in Section 2.1.3 of [RFC5216] when EAP-TLS is used with TLS 1.3 or higher. The other paragraphs in Section 2.1.3 of [RFC5216] still apply with the exception that SessionID is deprecated. If the EAP-TLS peer authenticates successfully, the EAP-TLS server MUST send an EAP-Request packet with EAP-Type=EAP-TLS containing TLS records conforming to the version of TLS used. The message flow ends with the EAP-TLS server sending an EAP-Success message. If the EAP-TLS server authenticates successfully, the EAP-TLS peer MUST send an EAP-Response message with EAP-Type=EAP-TLS containing TLS records conforming to the version of TLS used. Just to walk through the various scenarios here; if the last message of the TLS handshake for a given TLS version is sent by the TLS client, that will go in an EAP-Response, so the server is then able to send EAP-Success directly. On the other hand, if the last TLS handshake message is sent by the server, that will have to go in an EAP-TLS EAP-Request, and so the peer will have to send an empty EAP-TLS response in order for the server to be able to wend EAP-Success? Do we need to have any text here to handle that empty EAP-TLS Eap-Request case? ==[ COMMENT(Alvaro Retana) Is the intention of the Appendix to provide additional formal updates to rfc5216? That is what it looks like to me, but there's no reference to it from the main text. Please either reference the Appendix when talking about some of the other updates (if appropriate) or specifically include the text somewhere more prominent. [Roman] As proposed above, please provide some forward reference. ==[ COMMENT (Éric Vyncke) I find "This section updates Section 2.1.1 of [RFC5216]." a little ambiguous as it the 'updated section' is not identified clearly. I.e., as the sections in RFC 5216 are not too long, why not simply providing whole new sections ? [Roman] I'd propose a simple fix by using (approximate phrases such as) either: This section updates Section xxx of [RFC5216] by amending it with the following text. (for the cases where the intent is to keep the existing text in rfc5216 but add this new text) This section updates Section xxx of [RFC5216] by replacing it with the following text. (for the cases where the intent is to replace an entire section in rfc5216) ==[ COMMENT (Éric Vyncke) None of us are native English speaker, but "e.g." as "i.e." are usually followed by a comma while "but" has usually no comma before ;-) [Roman] A simple s/e.g./e.g.,/ and s/i.e./i.e.,/ would catch this. Regards, Roman
==[ COMMENT (Éric Vyncke) None of us are native English speaker, but "e.g." as "i.e." are usually followed by a comma while "but" has usually no comma before ;-) [Roman] A simple s/e.g./e.g.,/ and s/i.e./i.e.,/ would catch this. Eric is correct that US english i.e. and e.g. is usually followed by a comma. I corrected this in d9f5028 I also run a word spell check on the document. Word does not suggest removing any comma after "but" but rather insert an additional comma after a but. I think this can be left to the RFC editor. The word spell check caught two other grammar errors (s after plural, no s after singular) RFC 8446 does not use capitalization on post-handshake as that is just a name for a set of messages. I corrected these things in
I Made a new PR
Made a commit with NEW When EAP-TLS is used with TLS version 1.3, the EAP-TLS peers and EAP-TLS servers MUST comply with the compliance requirements (mandatory- to-implement cipher suites, signature algorithms, key exchange algorithms, extensions, etc.) defined in Section 9 of [RFC8446].
Section 2.1.4 Changed the text to: The message flow ends with a protected success indication from the EAP-TLS server, follwed by an EAP-Response packet of EAP-Type=EAP-TLS and no data from the EAP-TLS peer, follwed by EAP-Success from the server.
I added a forward reference to the appendix in the introduction
NAME looks like you have got everything covered? are there any comments from Roman which still need to be addressed? should we submit a new version and ask for IETF last call?
I have tried to do everything. Problem with the updates thing. The replace or amend strategy does not really work.... [Roman] I'd propose a simple fix by using (approximate phrases such as) either: This section updates Section xxx of [RFC5216] by amending it with the following text. (for the cases where the intent is to keep the existing text in rfc5216 but add this new text) This section updates Section xxx of [RFC5216] by replacing it with the following text. (for the cases where the intent is to replace an entire section in rfc5216)
NAME We should likely not do to much changes. Maybe we can write something like Amends with the following text. TLS 1.2 specific details in RFC 5216 are replaced. Requirement in the new takes precedence over requirements in the old text.
This review was addressed in earlier submissions. closing

figbase1 shows an example message flow for a successful EAP-TLS full handshake with mutual authentication (and neither HelloRetryRequest  <ins> nor post-handshake messages are sent). </ins> 2.1.2. This is a new section when compared to RFC5216. To enable resumption when using EAP-TLS with TLS 1.3, the EAP-TLS  <ins> server MUST send one or more post-handshake NewSessionTicket messages </ins> (each associated with a PSK, a PSK identity, a ticket lifetime, and other parameters) in the initial authentication.  Note that TLS 1.3 RFC8446 limits the ticket lifetime to a maximum of 604800 seconds (7 TLS 1.3 changes both the message flow and the handshake messages compared to earlier versions of TLS.  Therefore, some normative text in Section 2.1.3 of RFC5216 does not apply for TLS 1.3.  The two  <ins> paragraphs below replace the corresponding paragraphs in </ins> Section 2.1.3 of RFC5216 when EAP-TLS is used with TLS 1.3.  The other paragraphs in Section 2.1.3 of RFC5216 still apply with the exception that SessionID is deprecated. This is a new section when compared to RFC5216 and only applies to TLS 1.3.  RFC4137 offers a proposed state machine for EAP.  <ins> TLS 1.3 RFC8446 introduces post-handshake messages.  These post- handshake messages use the handshake content type and can be sent after the main handshake.  Examples of post-handshake messages are </ins> NewSessionTicket, which is used for resumption and KeyUpdate, which is not useful and not expected in EAP-TLS.  After sending TLS  <ins> Finished, the EAP-TLS server may send any number of post-handshake </ins> messages in separate EAP-Requests. To provide a protected success result indication and to decrease the followed: When an EAP-TLS server has successfully processed the TLS client  <ins> Finished and sent its last handshake message (Finished or a post- handshake message), it sends an encrypted TLS record with application data 0x00.  The encrypted TLS record with application data 0x00 is a </ins> protected success result indication, as defined in RFC3748.  After  <ins> sending an EAP-Request that contains the protected success result </ins> 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 layer.  To perform resumption in a secure way, the EAP-TLS peer and EAP-TLS server need to be able to securely retrieve authorization information such as certificate chains from the initial full  <ins> handshake.  This document uses the term "cached data" to describe such information.  Authorization during resumption MUST be based on such cached data.  The EAP-TLS peer and EAP-TLS server MAY perform fresh revocation checks on the cached certificate data.  Any security </ins> policies for authorization MUST be followed also for resumption.  The certificates may have been revoked since the initial full handshake and the authorizations of the other party may have reduced.  If the


this step would automatically inform the IETF Secretariat that this repository should be backed up as described in backup.  3. I-D.thomson-github-bcp contains discussion of the different possible

This needs to be more concrete than the current text. I just removed the following from -using: organization on the WG Charter page in the datatracker under More Info. Similarly, if there are multiple mailing list options, links to those mailing lists should be given. An example of this is at URL I wouldn't recommend that exact language, but the the text definitely should mandate some means of linking from working group status pages to the GitHub organization.
Sorry to be late on this. I don't see what more concrete thing you are asking for. The current text already has the steps, including putting a pointer on the WG page (although not in the charter itself).
There is work-in-progress to add "general external references" to each of users, groups, docs, in datatracker. Some details are in URL
Discussed in Singapore; will add some text in this document. migration style. I guess you are initializing things from refnames: value side with a unique id saved into cache, but I didn't see where you used that. What is migration style? Where can I find "typical" examples to emulate? The idea is that existing "additional URLs" fields -- for example, look at URL or URL -- will have those fields that are common (as specified in the python script) moved into the new tables. I am calling those new commonly-named things "extref" for "external referfence" The value is just a string, but the idea is that it is an identifier that is useful in some external context, and having common names for these thing makes more automation possible. For example, a "GitHub Repository" extref. We want that name normalized, so that tooling can fetch it. Right now the additional URL's are a set of text fields, and the names are not consistent: "Github repo" "GitHub Repository" "Repository", etc., are all used. That is the point of the refnames map, to capture all the existing names via regexp and map them into a common name which gets an ID in the external_refs table, which is then used as foreign keys in the "list of external references" for each of the person, group, doc, entries. It will not be perfect, but I looked at all the names and in use (the tables mentioned in the python outline) and I think it gets almost all things right. I am unsure, for example, of the YANG links; what tooling of theirs breaks if the name becomes generic? Perhaps I just don't remove a link when migrating. What is not shown or done is mapping these extrefs into the source, such as URL, and displaying them. That's the real work, I just want commentary on the data structures first. For example, in URL I could add a "standard" extref that says "On github I am richsalz" Then this could be used by scripts to populate repo's and auto-link back to the DT accounts. Hope that helps you help me help the IETF. :)

this step would automatically inform the IETF Secretariat that this repository should be backed up as described in backup. <ins> 2.6. The IETF Datatracker should allow working group chairs to add links to repositories (for GitHub and other repository services) on the working group "About" page under "Additional URLs".  This feature is already under development. </ins> 3. I-D.thomson-github-bcp contains discussion of the different possible


The document is meant to spur discussion in the IETF community.  If there proves to be rough consensus in the community in support of the proposals in this document, the functional requirements would need to <del> be discussed with the IETF Tools Team, and the IETF Secretariat who </del>  would need to support various pieces of what is proposed herein. 2. conventions to support the creation and management of GitHub organizations for working groups and single-document repositories in a uniform way.  The steps could be done manually by the IETF <del> Secretariat or they could be automated.  For example, see </del>  <https://github.com/richsalz/ietf-gh-scripts> and <https://github.com/martinthomson/i-d-template> for working examples of automation that is in use in some working groups. In this document the question of whether processes should be manual <del> or automated is deliberately left ambiguous since the first question that should be asked is whether this is functionality the community would want to have supported at all. </del>  Most of the conventions below are drawn from I-D.ietf-git-using- github. be able to make it have the same management as one would get with going through the steps in creation.  That is, it would be good to be able to run steps 3 and 4 from creation so that the rest of the <del> activities in this section such as personnel work the same for the organizations that were created on their own. </del>  2.3. 2.4. When a working group is closed, the team with administrative access <del> would be removed and the owner list would be returned to its initial composition.  The organization summary and the repositories within the organization would be updated to indicate that they are no longer under development. </del>  2.5. be useful to have automation or established administrative conventions for repositories within WG organizations, such as: <del> Creating a new repository for an individual draft that is at the discretion of the WG chair; </del>  Creating a new repository for an already-adopted working group draft;

See URL
I'm good with all the changes except the one I commented on. I’ve picked this document up as responsible AD, because Alissa is an author on the document. There’s one item in my review that I’d like to have addressed before this goes out for last call; the rest don’t need to block last call, but they should be easy to address. Blocking comment: — Section 2.4 — When a working group is closed, the team with administrative access would be removed and the owner list would be returned to its initial composition. What “initial composition”? The Secretariat and the ADs at the time the organization was created? That doesn’t make sense. The Secretariat and current ADs at the time of closing? That’s not “initial”. Or do you have something else in mind? The rest: — Abstract — Just a note here that the second paragraph should be removed before publication. I’ve put this in as an RFC Editor Note. — Section 1 — proposals in this document, the functional requirements would need to be discussed with the IETF Tools Team, and the IETF Secretariat who would need to support various pieces of what is proposed herein. Nit: the comma after “Tools Team” is misplaced, and should be after “Secretariat” instead. — Section 2 — For example, see and for working examples of automation that is in use in some working groups. Two things here: Nit: “For example … for working examples” is redundant; I suggest starting the sentence with “See”. I’m not sure that these URLs will stand the test of time, remaining valid in an archival document. On the other hand, having them here as examples is certainly useful. Perhaps we could archive them on an URL page, or perhaps the RFC Editor could do so on an rfc-URL page? In this document the question of whether processes should be manual or automated is deliberately left ambiguous “Ambiguous” isn’t the right word — it carries a connotation of confusion. I suggest “unspecified”. And there needs to be a comma after that word, whichever we choose. — Section 2.2 — be able to run steps 3 and 4 from Section 2.1 so that the rest of the activities in this section such as personnel work the same for the organizations that were created on their own. I find this awkward; I think it needs commas and a minor edit: NEW be able to run steps 3 and 4 from Section 2.1 so that the rest of the activities in this section, such as personnel changes, work the same way as for organizations that were created as specified herein. END — Section 2.5 — o Creating a new repository for an individual draft that is at the discretion of the WG chair; What does “an individual draft that is at the discretion of the WG chair” mean? — Section 4 — An attacker who can change the contents of Internet Drafts, particularly late in a working group's process, can possibly cause unnoticed changes in protocols that are eventually adopted. Indeed, and so should we propose any mitigations? Using a github instance that’s maintained and secured under URL At the very least we’ll need to rely on careful review during the publication process, including verifying what changes were made at each step and flagging questionable changes. The text here should probably say something more. Barry

The document is meant to spur discussion in the IETF community.  If there proves to be rough consensus in the community in support of the proposals in this document, the functional requirements would need to  <ins> be discussed with the IETF Tools Team and the IETF Secretariat, who </ins> would need to support various pieces of what is proposed herein. 2. conventions to support the creation and management of GitHub organizations for working groups and single-document repositories in a uniform way.  The steps could be done manually by the IETF  <ins> Secretariat or they could be automated.  See </ins> <https://github.com/richsalz/ietf-gh-scripts> and <https://github.com/martinthomson/i-d-template> for working examples of automation that is in use in some working groups. In this document the question of whether processes should be manual  <ins> or automated is deliberately left unspecified, since the first question that should be asked is whether this is functionality the community would want to have supported at all. </ins> Most of the conventions below are drawn from I-D.ietf-git-using- github. be able to make it have the same management as one would get with going through the steps in creation.  That is, it would be good to be able to run steps 3 and 4 from creation so that the rest of the  <ins> activities in this section, such as personnel changes, work the same way as for organizations that were created as specified herein. </ins> 2.3. 2.4. When a working group is closed, the team with administrative access  <ins> would be removed and the owner list would be returned to the Secretariat and current ADs at the time of closing.  The organization summary and the repositories within the organization would be updated to indicate that they are no longer under development. </ins> 2.5. be useful to have automation or established administrative conventions for repositories within WG organizations, such as:  <ins> Creating a new repository for an individual draft (at the discretion of the WG chair); </ins> Creating a new repository for an already-adopted working group draft;


a minimum) the GitHub account of the user so that their contributions could be tracked more easily.  3.2. IETF working group mailing lists are automatically backed up by the

The document currently assumes that there is one document per repository. That's not always the best structure. It's not uncommon for there to be tight clusters of related documents. QUIC does this (even though it is likely an outlier in the process), but there are also frequent occasions where working groups develop overview documents along with a protocol, or split a document into separate logical pieces (tokbind did this for TLS bits and HTTP bits). URL is something of a train wreck, but there is plenty of middle-ground here.

a minimum) the GitHub account of the user so that their contributions could be tracked more easily. <ins> Some working groups choose to have more than one draft in a repository, particularly for drafts that are tightly linked with significant cross-references.  In such a case, the README for the repository needs to say that clearly so that a participant understands that changes might be made to multiple drafts at once. </ins> 3.2. IETF working group mailing lists are automatically backed up by the