[09:34:11] --- jas has joined
[09:54:20] --- jimsch1 has joined
[09:56:35] * jimsch1 has changed the subject to: pkix 4 ipsec
[09:56:56] --- paulknight has joined
[09:57:37] <paulknight> Good morning! Sorry I can't be there in person...
[09:59:40] --- kivinen has joined
[09:59:55] --- kivinen has left
[10:03:07] <paulknight> I hear Gregory on the audio now!
[10:03:35] <paulknight> thanks for mentioning that I'm out here, Gregory
[10:03:59] --- FDupont has joined
[10:04:03] <paulknight> I Can't scribe from here!
[10:04:07] <jimsch1> Paul Hoffman for Minutes -- Jim Schaad for jabber
[10:04:24] <paulknight> Thanks, Jim
[10:04:27] <jimsch1> Chair slides - follow the WG
[10:05:03] <jimsch1> Slides avaiable at the IETF site
[10:05:20] --- kivinen has joined
[10:05:27] <jimsch1> Next slide - Agenda
[10:06:14] <jimsch1> profile document in AD review - looking for external reviewers for suppliment
[10:07:23] --- dennis_f has joined
[10:07:23] --- dennis_f has left: Lost connection
[10:07:25] --- dennis_f has joined
[10:08:05] <jimsch1> profile requirements document ready for last call - deals with lifecycle and other issues.
[10:08:32] <jimsch1> End working group last call on the document at end of this week.
[10:10:11] <paulknight> Right, the chair slides are not there...
[10:10:32] <jimsch1> Chair slides should be present -
[10:10:52] <jimsch1> -09 version mailed in yesterday - not yet posted on the IETF site.
[10:12:06] <jimsch1> -09 version to be posted at the meetings material site (he's doing it right now) and availabe on the shadow site -
[10:12:25] <jimsch1> -09 on www.icsalabs.com/pki4ipsec
[10:12:26] --- dennis_f has left: Lost connection
[10:12:44] <jimsch1> Switch to brian slides
[10:12:53] <paulknight> http://www.icsalabs.com/pki4ipsec/draft-ietf-pki4ipsec-ikecert-profile-09.txt
[10:13:16] <jimsch1> Small changes on -09 only
[10:13:23] <jimsch1> next slide - changes in -07
[10:13:57] <jimsch1> sha256 changes and some warning text from the last meeting
[10:14:07] <jimsch1> then lots of small editorial type changes
[10:15:09] <jimsch1> next slide
[10:15:24] <jimsch1> next slide
[10:16:01] <jimsch1> (back one slide)
[10:16:12] <jimsch1> current - disabling certificate checks
[10:16:54] <paulknight> who is current speaker?
[10:16:57] <jimsch1> floor: possible issues with turning off ipid checking on some changes
[10:17:01] --- jas has left
[10:17:16] <jimsch1> Airel
[10:17:30] <paulknight> Thanks
[10:18:00] <jimsch1> Different from the consensus at the last meeting - which took most of the last meeeting to hammer out
[10:18:16] <jimsch1> next slide - changes in -08
[10:18:39] <paulknight> Well handled by Gregory, I think.
[10:18:40] <jimsch1> Adds sha-256 changes plus current state of MD5 and SHA-1
[10:19:25] <jimsch1> next slide - changes in -09
[10:19:48] <jimsch1> one type - remove security consideration text on SHA-256
[10:19:58] <jimsch1> -- want to continue moving forward if possible.
[10:20:10] <jimsch1> Russ - asking if his mail was seen
[10:20:25] <paulknight> It was Jim Knowles who made the comment on aggressive mode...
[10:20:30] <jimsch1> Russ coming to mike with his comments
[10:20:42] <jimsch1> Russ---
[10:20:48] <paulknight> I can hear better with the mike!
[10:20:55] <jimsch1> current state is AD review for the doucment
[10:21:57] <jimsch1> Page 6 has a table
[10:22:15] <jimsch1> Concert for the line on DN compairson - bitwise compare
[10:22:28] <jimsch1> Why not use the reference to 3280 for it's DN compairsion code
[10:22:56] <jimsch1> Brian - this is how it is implemented (bitwise ompare)
[10:23:19] <jimsch1> Paul Hoffman - discussion pre-IETF with pushback on doing the 3280 comparison from vendors
[10:23:43] <jimsch1> We don't have 3280 tool kits - just hacking together code
[10:24:10] <jimsch1> Russ - if that's the case need text to talk about the fact that bitwise is used in the section for CA considerations
[10:24:37] <jimsch1> russ - section 3.1.2
[10:24:58] <jimsch1> second paragraph (split across page)
[10:25:34] <jimsch1> caseless comparison must be preformed - Russ thinks this means change the case to all upper then compare (or equivalient)
[10:25:43] <jimsch1> Is this correct for international domain names?
[10:26:04] <jimsch1> Paul - quation is is UTF8 or puny code? for cert names
[10:26:29] <paulknight> Thanks for repeating, Gregory
[10:26:36] <jimsch1> Russ thinks that puny code is what is used - this means that everything is ascii so caseless is ok
[10:27:39] <paulknight> Yes
[10:27:42] <jimsch1> Russ - one last issue
[10:27:57] <jimsch1> Section 4.3
[10:28:34] <jimsch1> Last friday some researchers in the Netherlands anounced that they can find MD5 collisions in less than a minute on a PC.
[10:28:50] <jimsch1> Should we kill MD5 or allow keep it for mandate
[10:29:04] <paulknight> I think MD5 is still needed for interop
[10:29:11] <jimsch1> Paul Hoffman - Question: Russ do trivial MD5s have potential issues with certificates or not?
[10:29:31] <jimsch1> Does the certificate structure allow for a good degree of protection still?
[10:30:26] <jimsch1> David Black - RFCs are archive documents - bet that a year from now the structure issue will not be an issue
[10:30:53] <jimsch1> David: question ought to be SHOULD NOT or MUST NOT
[10:31:20] <jimsch1> Russ: Stronger language that he suggests - Accomidate current MD5 certificates but no new MD5 certificates
[10:31:50] <paulknight> +1 to Russ
[10:31:58] <jimsch1> Paul: - many current CAs are still using MD5 for trusted roots (see Microsoft cert store for examples)
[10:32:30] <jimsch1> Airel: Says that MD5 certificates with a long enough unpredictable serial number exists
[10:33:06] <jimsch1> Gregory (not chair): 3 audiences for the document - implementers of IKE, CAs and deployers
[10:33:33] <jimsch1> SHOULD NOT issue new would fufill our goals
[10:34:25] <jimsch1> Directive text is helpful for users of the document trying to figure out what they are going to do.
[10:35:00] <jimsch1> Paul Hoffman: Should state why the statements are being made. Cannot currently do this for the MD5 issue
[10:35:16] <jimsch1> Structure is not coming out of the current researchers in the field.
[10:36:01] --- mrichardson has joined
[10:36:45] <jimsch1> Current attacks allow for random blocks to be colided - currently could only use a the public key.
[10:37:16] <jimsch1> Attack not useful until identity or validation dates can be different and useful.
[10:38:25] <jimsch1> Two ceritifcates - same identity - different public keys - same CA signature
[10:38:55] <jimsch1> Requires prediction of all data before the public key by the certificate requestor
[10:39:36] <paulknight> If we had to choose today, are there any cases where we would choose MD5? If not, we ought to use SHOULD NOT.
[10:39:39] <jimsch1> Charlie Kaufman: We now have a New York Times attack on MD5
[10:40:05] <jimsch1> People will convert to a new hash fucntion just to avoid the debate - broken or not
[10:40:21] * mrichardson is confused why MD5 failure is in-scope for pki4ipsec vs saag.
[10:40:40] <jimsch1> David Black: Disagree with Paul -
[10:41:09] * mrichardson not in room.
[10:41:15] <jimsch1> Agree that good practice CAs are OK today - but not in the future - and too many bad administrators are going to be a problem
[10:42:00] <jimsch1> Paul: disagrees with the fact that the attack would be useful
[10:42:23] <jimsch1> Paul - do you want your last comment pushed to the mike?
[10:43:11] <paulknight> mrichardson: MD5 discussion is in scope because PKIK4IPSEC focus is on recommending interoperable cert usage.
[10:43:27] <paulknight> please
[10:44:32] <paulknight> Thanks for using the mike!
[10:45:08] <jimsch1> Tera: as attacks get faster then we can get structured attacks just on chance
[10:45:19] <jimsch1> (Tero not Tera)
[10:45:47] <jimsch1> Paul Hoffman - attack at that level just goes to the birthday attack level
[10:46:02] <paulknight> Jim, please do mention my comment at the mike if convenient for you.
[10:46:23] <jimsch1> Tim Polk - venders will support if practical and needed by customer base
[10:47:57] <paulknight> +1 to Paul H. Can't require what's not supported by software tools.
[10:48:15] <mrichardson> must state requirements, or software tools won't grow.
[10:48:25] <paulknight> Thanks Jim.
[10:48:32] <jimsch1> Yes but Open SLL does support SHA-256 today
[10:49:02] <jimsch1> Chair has the floor - looking at section 4.3 - Strethn of signature hashing algorithms
[10:50:03] <jimsch1> Question to Russ: Should this be a saag decission that filters down
[10:50:11] <jimsch1> Russ - you are first SOL
[10:50:23] <jimsch1> Russ at mike
[10:50:48] <jimsch1> SAAG in Vancouver - moving from SHA-1 to SHA-256 but have not talked about state of MD5
[10:51:21] <jimsch1> Gregory was underwhelmed by the clarity of the statement from last IETF
[10:51:52] <jimsch1> Wants a clearer statement on what to do with the algorithms in terms of MUST/SHOULD/SHOULD NOT
[10:52:14] <jimsch1> Russ will talk with SAM about placing this on the agenda for SAAG
[10:53:07] <jimsch1> Russ places weaker proposal on thable -- strongly encourage rather than SHOULD NOT
[10:54:01] <jimsch1> encouraged not to use MD5 for the issuing of new certificates - hum
[10:54:23] <paulknight> is SHA-1 also discouraged?
[10:54:39] <paulknight> I hum in favor
[10:55:32] <jimsch1> David Black: -- Crucail exposer is MD5 - SHA-1 not as far
[10:56:03] <jimsch1> Paul Hoffman - Same attack is applicable to SHA-1 and SHA-256 attacks will probably be slower but don't know how much
[10:57:10] <jimsch1> Gregory- Can we point people to SAAG for updates?
[10:57:19] <jimsch1> Russ - just ship it and know it's a point of time
[10:57:39] <jimsch1> Paul -- is that ok to skip it
[10:57:52] <paulknight> okay to skip
[10:58:09] <paulknight> OKAY
[10:58:09] <jimsch1> Next document -
[10:58:21] <paulknight> (the audio is delayed about 15 sec)
[10:58:27] <jimsch1> Francis - qustion on 3.14
[10:59:02] <jimsch1> thats 3.1.4
[10:59:13] <jimsch1> Reference to SBGP should be updated
[10:59:47] <jimsch1> Now is in the form of an RFC - the definition is the same (reference 13)
[10:59:54] <jimsch1> RFC 3779
[11:00:36] <jimsch1> Presentation on requirements for management protocol
[11:01:01] <paulknight> hand up
[11:01:41] <jimsch1> Question if we are going to get more input on the document before end of week -- no hands
[11:02:07] <jimsch1> Any open issues to the floor?
[11:02:24] <jimsch1> Stephan - Question : Is this a speculation document or is this a real useful document?
[11:03:43] <jimsch1> Gregory (non chair) - at the start of deploy - set of IPSEC implmenters - wanted vendors to be at the same place
[11:04:14] <jimsch1> Never succeeded in getting CA vendors to come and works with them
[11:04:42] <jimsch1> This states - this is what the IPSEC comunitiy probably wants CA people to do;
[11:06:47] <jimsch1> No comments formt he floor on this document.
[11:07:03] <jimsch1> On to charter and Milestones
[11:07:41] <jimsch1> When new profile doment is released then should go to IESG
[11:07:58] <jimsch1> management profile last call ends EOW and goes to AD
[11:08:02] <jimsch1> Any new charter items?
[11:08:17] <jimsch1> Working group should close next month - last meeting -- cheers
[11:08:54] <paulknight> Thanks for the good jabber scribing and use of mikes to let me participate remotely!
[11:09:19] --- jimsch1 has left
[11:09:21] --- kivinen has left
[11:09:30] <paulknight> You're welcome.
[11:10:09] <paulknight> Bye all!
[11:10:28] --- paulknight has left
[13:22:35] --- FDupont has left
[20:17:18] --- mrichardson has left