Note-Well Agenda Bashing WG Status - 10 minutes On Soft Errors: Lars: The data tracker is down so from memory: Soft errors is pending some thoughts from the IPv6 community. Wes on behalf of Sally Floyd for ECN+SYN: Sally thinks it should go forward for last call, but would like a few folks to check the changes for "safeness". Wes asks for any volunteers for that role from the group. There are no volunteers, Wes notes that the chairs will pole the mailing list. On TCP Secure: Lars: It would help if the WG provide a preference on whether this updates 1122 David Borman: Consensus seems to be no. Matt Mathis: Felt that it didn't need any special consideration by the IESG if it was "no" DB: The way I stated it, was that it will be raised to the IESG for consideration with either decision. We would like the IESG to confirm it one way or the other. On Early Retransmit: Wes: There is a new draft on this that was checked in by Mark Allman recently. Chances are no one has seen it yet, plan to announce that to the mail list. Current WG Items ===== Authentication Option Draft draft-ietf-tcpm-tcp-auth-opt-02 Joe Touch 30 minutes A: Request of [what to do with the] bellovin draft? [no response from crowd, sans one lone bit that it should be expired] Wes: It's been expired Tim Polk: If there was strong consensus from the security community, then there would be a greater push to support only one of the options, but that doesn't exist so there's no reason to support both. Jabber: { MUST / MUST - 3 implementors already support this. It's proven to be pretty easy in implementation. And, should one get cracked, we can roll to the other } Eric Rescorla: [spoke to quickly - didn't follow] TP: Thinks either algorithm would work just fine, and more important factor/question is if the code base is properly baked. Brian Weis: As an implementer, I'd rather only have to do one. With that would rather do SHA1, AES would be a bit more difficult. Wes: Do we have at least consensus on SHA1 Gregory Lebovitz: I'm not willing to hold a document on this topic... I think SHA1 has to be a MUST and would like to see the WG pick something else that is a SHOULD that would help get us to the future Wes: Raise hand if SHA1 is a MUST Show of hands: YES, none oppose Wes: Show of hands, should there be an ALT Show of hands: moderate Wes: Show of hands, should that be a must? Crowd: Negative reaction GL: We should adopt a concept from security world about SHOULD+ Lars: Agrees because it's basically avoids the stress of forcing people to update, but if your touching your code, it's a good idea to go ahead and put something Multiple: Verbally show support the concept of a "Strong" SHOULD ER: Chinese menu is one take, other is [MAC -> PRF binding ?] Russ Housley: I don't think that's true, because then it won't work. [Conversation on coupling the __? and __?] GL: mentioned something about FIPS and potential of government action that would require some additional work TP: [Must use them as a pair] BW: What's the issue with creating a new registry for this? A: Unless we create new algorithms, we don't need a new registry - which is usually an algorithm and number. BW: Well if we don't have any numbers then we don't need IKEv2 A: That's a good point, needs to be looked into. RH: Seems if you follow the IPSEC model, they have a registry and document tree that keeps it clean, but becomes problematic if you add __? Jabber: this pushes us in the direction of a new registry. We need a new registry to express a policy that shows a set of algorithms that the community has vetted. ER: [Had some thoughts on code points] TP: Doesn't think it will be a large registry that would need to protect IANA from __? A: Registry typically assigns code points. If we need code points, we need a registry. So can we agree to the point that if we need code points, THEN we need a registry. Crowd: Nods in agreement GL: Alludes to the point that we will most likely need code points, but doc is not out yet. RH: Process is in place to allow the progression of document to full standard (allowing a few paragraphs to change) MM (no mic): And that applies to _all_ our proposed standards. On Header Fields: GL: On Pros, it's not needed on the key exchange, that you can do it without putting any bits on the wire. A: Wanted to ask you about that, in brief. Asks for explanation. ER: For any different underlaying shared secret (even though the traffic keys are different) Crowd: Some disagreement with that. ER: Then we need to discuss that. A: FYI, nothing in the current spec that supports that. [ed: Much more back and forth, listen to the stream] ER: Gives an example of his proposal. RH: Explains why key-ids don't need to be the same. [More discussion and thoughts on this key-id and header bit(s)] [And they come to the conclusion/agreement that we don't a bit on the wire for the keyid.] ***ACTION*** GL will write the text up explaining all of this GL: Troubleshooting wise: either wrong keys or algorithms... is it really necessarily to go through the checks on each packet... Lars: We're burning a bit in option space which is scarce... if we don't need it then we shouldn't use it. (Saving a bit in the option space) Wes: Do you want to use a bit: Want; Don't Want; Don't Care Show Hands: 1.5; Consensus (10+); 3 Lars: Sees working group last call in December. Matt Mathis Re-thinking TCP-Friendly (no draft available) 5 minutes Michael Scharf draft-scharf-tcpm-flow-control-quick-start-00 10 minutes Wes: Is the working group interested in this topic as a WG topic. MM: Surprised at a piece of info... this is only the receiver behavior. There is a lot of research on the linux behavior and a problem with memory. (that you run out). This code is on by default in linux and will open the window to about 4MB (contingent on memory). A: Linux code is perfect, but not useful for the first round trip (aka for things like QS)... so this is about the init syn period DB: This is to avoid another round trip delay - letting you send an immediate ACK in order to advertise the scaled window (which you couldn't do in both directions with the standard three way handshake) DB: Reordering issues A: One could argue that if there is reordering, should you even continue with the QS? Wes: Sounds like we need to take this to the mailing list. A: OK ===== Fernando Gont Urgent Data draft-gont-tcpm-urgent-data-00 10 minutes When discussing the options to the Urgent Pointer: Lars: Option 4) Obsolete the Urgent Pointer ====== Fernando Gont Timestamp Generation draft-gont-tcpm-tcp-timestamps-00 10 minutes Joe Touch: Whatever you do with this needs to be put into the same place or have a normative reference [to the other] ===== ICMP Attacks Draft draft-ietf-tcpm-icmp-attacks-04 Fernando Gont 20 minutes A: Been striping issues from the document Joe Touch: Just needs to be scrubbed before last call ***ACTION*** Joe and Gorry to provide that scrubbing. Chairs: Should be able to progress soon. ===== 1323bis draft-ietf-tcpm-1323bis-00 David Borman 10 minutes