Stephen Farrell has entered the following ballot position for draft-ietf-emu-eap-tunnel-method-10: No Objection
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 http://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: http://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for handling my discuss. --- didn't check comments against -10 This was discuss point (1), not a comment: (1) 3.4: when x.500 names or SubjectAltNames are "exported" is it clear how those are formatted? Maybe a pointer to where that's defined would be good in case implementers get it wrong. You might also want to warn here (or somewhere) about names that contain a null byte in case that attack is used e.g. with a TLS server cert subject name like "CN=www.paypal.com\0.badguy.com" Even though that's really a PKI failure, not detecting it here would be bad too. older comments... - 3.2: You're allowing TLS compression. Is there the potential for something like a CRIME attack here? I guess not, given that there's no way to programatically get a peer or inner method server to send attacker-chosen data. Is that correct? (Just checking.) - 3.2.2: Since a PAC-lifetime is a wall-clock time then it would provide a way to correlate old and new sessions (i.e. act as a fingerprint) if its ever carried in clear. Can that happen? - 3.3.3, 1st para: what does "clear text" mean here? Do you mean within the TLS tunnel or not? I hope you do mean within the TLS tunnel, but I think you need to be clear(er) in any case. - 3.8: this says mutual auth "results" if the peer trusts the server cert belongs to the server - that sounds wrong, isn't it? - 3.8.1: I think you need an s/MAY/MUST/ here - you say the request "MAY be issued only ..." but I think you mean "MUST be issued only..." - 3.8.2: Just checking, and I may be wrong here. Say if I establish a TLS server-auth tunnel and then renegotiate to get TLS client-auth (with id privacy) as well, and then the Peer wants to get a new cert. This calls for the tls-unique for the initial server-auth TLS session to be used in the pkcs#10. Am I reading it right? Is that ok? I think it is, but just want to check since its pretty confusing;-) - The secdir review [1] raised a couple of questions that I think would be good to answer. Did I miss that answer? [1] http://www.ietf.org/mail-archive/web/secdir/current/msg04106.html _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
