------------------------------------------ IETF73 CSI WG meeting minutes ------------------------------------------ WEDNESDAY, November 19, 2008 1300-1500 Afternoon Session I ------------------------------------------ Agenda bashing, note takers All - 5 min ------------------------------------------ Document status update Chairs - 5 min We are going to issue the WGLC for SEND PS. ------------------------------------------ Proxy SeND http://www3.tools.ietf.org/html/draft-krishnan-csi-proxy-send-00 Julien/Suresh - 10 min The document is now a WG doc,all suggested changes have been made excluding one. Outstanding issue: Backward Compatability (non-local-node generated CGAs) Perhaps mosts relevantly, Dave's comment about using delegation / chain Suggestion to add this into the DHCP-CGA Problem Statement Proposal to carry this forward, 1 or 2 more revisions probably needed ------------------------------------------ Hash Agility for SeND http://www.rfc-editor.org/cgi-bin/iddoctype.pl?letsgo=draft-ietf-csi-hash-threat-00 Ana/Suresh/Sheng - 15 min The proposal presents 4 possible solutions Call for opinions - pick one of these, other, none of the above ... Discussion WRT SEND w/o CGAs ... permit weaker models, and not all SEND messages use CGAs at all Suggestion to drop first option Whether you are using the CGA or not, do you know the relevant information Suresh votes in favor of the Hybrid option - least impact on security, permitting other things to happen if needed / desirable Suggestion to drop option three ... Comment in support of Option 2 - operates similar to non-SEND level of security Suggestion to (apparently) steal some bits from address space to encode the alg. selection; discussion about case where this might not work / be desirable Chair moves to keep it open for one more go-round ------------------------------------------ PK agility and ECC support for SeND ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-shen-csi-ecc-01.txt Sean/Michaela - 20 min RSA 1024 undesirable; lacking crypto strength while also requiring too much CPU Proposes new ECC Sign Option and new ECC CGA Data Struct (both similar in form to RSA) Question over the level of similarity ... how does a node know? Pub Key descr. differentiates Existing problem in informing node, will be addressed in future draft (this one assumes node knows which type of key) Draft explicitly references Option type 31, will need to revise to just say "ask IANA" Question of change from MUST to recommended (key length) ... Back to that MUST vs recommended ... desires a MUST of some sort One voice in support of this, pushing for security review soon thereafter (specifically to eval the crypto key length values) One voice in support of 384 (US Crypto Std) remaining in draft ... +=1 Sean: Concern about too many choices being listed Marcelo: We are chartered to support crypto agility, but cannot assume a priori knowledge by the nodes ... should do that first, then address the alg's Sean: Didn't feel that was appropriate in this doc, it is being done in PKI/agility work Marcelo: ... still in favor or doing that agility first then looking at these algs. ... Sean: ... We are doing both in parallel ... Chair calls for Crypto Agility first, then these algorythms Presenting PKI agility next More algs coming to market Comment raised WRT terminology, "PKI" vs "Signing Algorythms" Comment about hashing being relevant as well, and possibility of different key lengths between signing and hashing algs. Backwards compatibility good ... burn N addresses Question - one CGA being signed by multiple algs? A: Starting down that path, but left it due to backwards compat. Question - different addresses raises an Address Selection problem? Question - about the word IF ... are we going to do both, do we want hosts to do both ... always ... ? may need new options defined Clarification - these are proposed changes to SEND options, not CGA options Open item : 1 address or two addresses ... Router as Notary - not documented in draft currently ... And yes, we are chartered to solve Crypto Agility Again - solve this problem first, then circle-back to ECC proposal Question from Jabber WRT two public keys ... they don't go in same field, define an extension ------------------------------------------ Certificate Management http://www.ietf.org/internet-drafts/draft-krishnan-cgaext-send-cert-eku-01.txt Suresh/Ana/Khaja - 15 min Current draft total mess, going to start just about from scratch self-defining/ refining everything needed ... based on RPKI certs defined in draft-ietf-sidr-res-certs-15 Question regarding revocation, checking status thereof ... this draft won't do it - but we are chartered to do so Lack of RPKI deployment should be coming, and lack thereof not an impediment moving forward No EKUs is a problem - perhaps work with SIDR folks to fix that? EKUs were removed from current RPKI draft because they weren't needed ... adding it back should be easy CRLs ... large CRLs could be problematic, but should be rare Voice in support of CRLs, with word of concern lifespan is bounded no name changes to worry about revocation should be very rare (contractual bounds) small amount of data goes into CRL Question: How will we use the CRLs? should that be answered herein, or as a separate doc? let's talk about it ("not for a long time"), and then decide WG consensus to adopt RPKI cert profile for SEND ------------------------------------------ DHCPv6 and CGA Interaction: Problem Statement http://tools.ietf.org/id/draft-jiang-csi-dhcpv6-cga-ps-00.txt Sheng - 10 min Just a PS, no solution decision - DHCPv6 + SEND Current spec allows requestor to ask for it's CGA address, new options? Comment : more ways DHCPv6 server could help, generate key pair and CGA addr. Non-PK basic signature usage / delegation. Requests wording in draft if not there already Comment: This is useful and answers questions asked throughout the day's presentations ... Dave & Suresh: 1- client does all work, informs (requests?) DHCPv6 server ... smart client, dumb server ... possible today if router is sending RAs 2- client supplies pub key in request, server generates CGA ... "cpu computation offload" ... 3- DHCP server does all work, using own key and delegates to client - would require key work as well Ralph ... clarification on DHCPv4 vs v6 behaviors Chair: Good base, need to ID all possible interactions (any other unforeseen? anything missing?) ... include that analysis in doc ... then make recommendations Ralph (co-chair of DHC WG) ... pls ensure collaboration with DHC ... and do a last call w/i both -- DHC would be a good source for those unforeseen interactions ... -- Also encourages early interaction, not just a WG LC ((Note, this was presented @ DHC previously once)) Chair: Yes, document all cases - but also caution reader that not all cases will be covered in all cases / in this mechanism ... "sitaution / implementation specifics" will apply ------------------------------------------