> -----Original Message----- > From: John Mattsson <john.matts...@ericsson.com> > Sent: Thursday, March 21, 2019 8:56 AM > To: Jim Schaad <i...@augustcellars.com>; draft-ietf-emu-eap-tl...@ietf.org > Cc: 'EMU WG' <emu@ietf.org> > Subject: Re: Review of draft-ietf-emu-eap-tls13-04 > > Thanks for the thorough review Jim! > > -----Original Message----- > From: Jim Schaad <i...@augustcellars.com> > Date: Wednesday, 20 March 2019 at 11:03 > To: "draft-ietf-emu-eap-tl...@ietf.org" <draft-ietf-emu-eap-tl...@ietf.org> > Cc: 'EMU WG' <emu@ietf.org> > Subject: Review of draft-ietf-emu-eap-tls13-04 > Resent-From: <alias-boun...@ietf.org> > Resent-To: John Mattsson <john.matts...@ericsson.com>, > <mo...@piuha.net> > Resent-Date: Wednesday, 20 March 2019 at 11:03 > > General Comment: I have a strong tendency to like positive rather than > negative statements in documents, thus the use of MUST rather than > MUST NOT. > Additionally, I have a general tendency to like to know what should happen > if a statement is violated. Thus consider the following from section > 2.1.1: > > Agree, if possible it is often better with "MUST" statements describing what > is happening. The disadvantage with MUST statements are that they rule out > things that may be specified in updates to RFC 8446. > > TLS 1.3 introduces early application data; early application data SHALL > NOT > be used with EAP-TLS. > > I would prefer to see this as > > TLS 1.3 introduced early application data; if a server receives a client > hello with early application data it MUST abort the handshake with an > EAP-Failure. The server MAY generate a TLS-Alert as well. > > In the case of early data, Section 4.2.10 of RFC 8446 states that "A server > which receives an "early_data" extension MUST behave in one of three > ways:". The three ways are: ignoring early_data, send HelloRetryRequest, > and accepting early_data. > > Aborting the handshake would not follow RFC 8446, so I don't think we want > that. I would suggest to follow RFC 8446 and specify that the server ignore > the early_data extension or replies with HelloRetryRequest. I suggest > writing: > > TLS 1.3 introduced early application data which is not used in EAP-TLS. A > server which receives an "early_data" extension MUST ignore the extension > or respond with a HelloRetryRequest as described in Section 4.2.10 of RFC > 8446.
That is better, an additional note that new session tickets MUST NOT include the early data extension would also be relevant. > > This made me realize that draft-ietf-emu-eap-tls13-04 does not mention > HelloRetryRequest at all. I think draft-ietf-emu-eap-tls13-04 should mention > HelloRetryRequest add add a figure describing the message flow. > Alternatively state that HelloRetryRequest MUST NOT be used (or positively > that the server MUST respond with ServerHello). > > Section 2.1.2 - The following sentence: > If the EAP peer did not supply a "key_share" extension > when offering resumption, the EAP server needs to reject the > ClientHello and the EAP peer needs to restart a full handshake. > > Appears to state that the key share MUST be provided even though the > previous sentence said that it was only a SHOULD. Which is it? > > Good catch. Definitely something missing in that sentence. Should be > SHOULD following RFC 8446. Suggested update: > > "If the EAP peer did not supply a "key_share" extension when offering > resumption, an EAP server declining resumption needs to reject the > ClientHello and force the EAP peer to restart a full handshake. The message > flow in this case is given by Figure 4 followed by Figure 1 or Figure 2." Yes better > > Section 2.1.3 - I am having a problem understanding why you have Figure 8 > in > the system. > > There was an earlier comment from someone requesting more figures > describing messages flows for various use cases and errors. > > First, a new session ticket would only be returned if the > client asked for one to be returned. Thus the client will never receive > one > that is unexpected. > > That is not my understanding of how NewSessionTicket works according to > RFC 8446. The session_ticket extension is a far as I understand deprecated in > TLS 1.3. The only text I can find in RFC 8446 is that Oh fudge. Losing the indicator that a client wants this seems to be a stupid decision on the part of TLS. I guess that I just assumed it was still there because it was in the past. > > "At any time after the server has received the client Finished message, it > MAY send a NewSessionTicket message." > > Secondly, the authentication has finished and you are > in a situation where if you had not asked for the ticket everything would > be > fine. The only possible reason for doing this would be if the client > suddenly decided that it no longer wanted the ticket and was going to tell > the server that it did not need to cache the information associated with > it. > However, since this is not a normal flow in TLS that would never happen. > If > the client decides that it does not want to save the ticket that it > received, say because it is too big, then it can just not save it but > still > have EAP run to success. > > Agree that the client should just most likely just ignore the ticket. Let's > remove the figure and the text. > > Section 2.1.4 - an EAP-TLS server MUST treat an empty certificate_list as > a > terminal condition when client authentication is required. Current text > implies it is always true. > > The text in draft-ietf-emu-eap-tls13-04 > > "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." > Right but the first sentence in the paragraph is As the certificate messages in TLS 1.3 are encrypted, there is no need to send an empty certificate_list ... So both statements are not true. > follows Section 4.4.2.4 of RFC 8446: > > "If the client does not send any certificates (i.e., it sends an empty > Certificate > message), the server MAY at its discretion either continue the handshake > without client authentication or abort the handshake with a > "certificate_required" alert." > > I do not understand what you mean with " Current text implies it is always > true." The term terminal condition came from RFC 5216. Should I rewrite it > with text from RFC 8446? > > "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 at its discretion either continue the handshake without > client authentication or abort the handshake with a "certificate_required" > alert." > > Section 5.7 para 3 - The term "other authentication information" is > confusing to me. You should only be capturing the information from the > TLS > handshake and nothing else. > > I think the group need to discuss this more. I think Alan's suggestion was > that > you capture quite a lot. Agreed on the discussions Jim > > As an example, I would not expect that the > client would do any additional revocation checking when offering to use a > session ticket. If the revocation information is not sufficiently > current, > then the client should not do resumption. But this does not require > reevaluation of revocation information or the server certificate chain. A > client quite likely to be unable to access a network to check for > revocation > until after the EAP process has finished and thus would be unable in EAP > to > do these checks. > > That are very good points. I will update the text based on these suggstions. > > Section 5.7 para 7 - Current sentence appears to say that the IP address > is > part of the EAP-Response/Identity. > > Ok, let's reformulate > > I generally find this entire section > confusing and think that a large amount should probably be in the main > text > and not here. > > Yes, moving some of the information to 2.1.2 seems to make sense > > Jim > > > > > > > > > > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
