Hi Ben, This should hopefully address your feedback: https://github.com/emu-wg/eaptls-longcert/commit/d39c1411c908844cc74bc0a6fa689a73ecd5b7a8
Answers in-line. --Mohit On 11/4/20 9:04 AM, Benjamin Kaduk via Datatracker wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-emu-eaptlscert-06: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-emu-eaptlscert/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for responding to the secdir review and thanks to Stefan > Santesson for the review -- the changes staged in github are a > significant improvement! > > Though I am balloting Yes, please see my remarks about > draft-thomson-tls-sic in the comments on Section 4.2.5 -- it is expired > and was not adopted by the TLS WG and we should not imply that it is a > current work item there. > > I also made a pull request at > https://github.com/emu-wg/eaptls-longcert/pull/4 with a few editorial > fixes/suggestions. > > Section 3 > > o Multiple user groups in the certificate. > > What are "user groups" in a certificate? The text now says: It can contain multiple organization fields to reflect the multiple group memberships of a user (in a client certificate). > > A certificate chain (called a certification path in [RFC5280]) can > commonly have 2 - 6 intermediate certificates between the end-entity > certificate and the trust anchor. > > The '2' here is surprising to me; my understanding was that having just > 1 intermediate was quite common, especially on the web. Added that certificate chains in 'EAP-TLS' can have 2-6 intermediate certificates. > > Many access point implementations drop EAP sessions that do not > complete within 50 round-trips. This means that if the chain is > > Earlier we said "40 - 50"; we should probably be consistent about it. Fixed. > > Section 4.1 > > 1.3 [RFC8446] requires implementations to support ECC. New cipher > suites that use ECC are also specified for TLS 1.2 [RFC5289]. Using > > nit: RFC 8422 might be a better reference than 5289, here. Updated. > > Section 4.1.3 > > The EAP peer certificate chain does not have to mirror the > organizational hierarchy. For successful EAP-TLS authentication, > certificate chains SHOULD NOT contain more than 2-4 intermediate > certificates. > > This seems equivalent to the shorter "SHOULD NOT contain more than 4 > intermediate certificates". Changed to 4. > > Section 4.2 > > by updating the underlying TLS or EAP-TLS implementation. Note that > in many cases the new feature may already be implemented in the > underlying library and simply needs to be taken into use. > > Hmm, "many" might be a stretch, given that the majority of the > mechanisms we refer to are still at the internet-draft stage. Changed to "some" > > Section 4.2.2 > > possible. An option in such a scenario would be to cache validated > certificate chains even if the EAP-TLS exchange fails, but this is > currently not allowed according to [RFC7924]. > > This is arguably not a strict requirement in 7924; the text in question > looks to be: > > % Clients MUST ensure that they only cache information from legitimate > % sources. For example, when the client populates the cache from a TLS > % exchange, then it must only cache information after the successful > % completion of a TLS exchange to ensure that an attacker does not > % inject incorrect information into the cache. Failure to do so allows > % for man-in-the-middle attacks. > > The normative MUST is for "legitimate sources", and "only after > successful TLS exchange" uses the lowercase MUST. Of course, 7924 > predates 8174, so it's not fully clear-cut, but there may be some ground > to stand on for caching validated certificate chains prior to a > completed TLS handshake (provided that other validation is performed > properly). Updated text says " An option in such a scenario would be to cache validated certificate chains even if the EAP-TLS exchange fails, but such caching is currently not specified in [RFC7924]." > > Section 4.2.4 > > "known certificates". Thus, cTLS can provide another mechanism for > EAP-TLS deployments to reduce the size of messages and avoid > excessive fragmentation. > > cTLS is at a fairly early stage; it might be better to say "could > provide" rather than "can provide". Changed to "could provide". > > Section 4.2.5 > > handshake increases the size of the handshake unnecessarily. The TLS > working group is working on an extension for TLS 1.3 > [I-D.thomson-tls-sic] that allows a TLS client that has access to the > > It is not accurate or appropriate to say that "the TLS working group is > working on" an individual I-D that is not adopted by the WG. > Suppressing intermediate certificates might be more appopriate in the > "new certificate types and compression algorithms" section, that seems > to be the home for most of the still-speculative stuff. Yep. Good point. Removed the text "The TLS working group is working...". However, I haven't moved this to the "new certificate types and compression algorithms" section. > > Section 4.2.6 > > certificate chains. Deployments can consider their use as long as an > appropriate out-of-band mechanism for binding public keys with > identifiers is in place. > > It is also important to consider revocation and key rotation when > considering the use of raw public keys. Added: "Naturally, deployments will also need to consider the challenges of revocation and key rotation with the use of raw public keys." > > Section 6 > > We probably want a general disclaimer that the security considerations > of the referenced documents apply, in addition to whichever pieces we > cherry-pick for specific mention. (In light of my previous comment > about draft-thomson-tls-sic, we may want to not use that as one of the > things to cherry-pick for special mention.) > > We might also mention that various ways to avoid sending certificates > over the wire do not obviate the endpoints' responsibility to check > revocation information. > > Similarly, efforts to trim certificate size should not remove extensions > or other attributes that are necessary for secure operation (though that > is perhaps a bit banal to actually say). Removed the text of draft-thomson-tls-sic and added "Specific security considerations of the referenced documents apply when they are taken into use." > > Section 7.2 > > I think RFC 8446 needs to be a normative reference. Now it is normative. Happy to edit further as needed! --Mohit > > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
