Re: Fwd: Security team successfully cracks SSL using 200 PS3's and MD5 flaw.
At Sun, 4 Jan 2009 07:51:01 -0500, Marshall Eubanks wrote: I think that Hank raises a very good question. There has been a very active discussion of this on NANOG, both re SSL, BGP and in general. Here is the original link : http://hackaday.com/2008/12/30/25c3-hackers-completely-break-ssl-using-200-ps3s/ Regards Marshall Begin forwarded message: From: Hank Nussbacher h...@efes.iucc.ac.il Date: January 4, 2009 2:22:06 AM EST To: Mikael Abrahamsson swm...@swm.pp.se, na...@nanog.org na...@nanog.org Subject: Re: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. At 06:44 PM 03-01-09 +0100, Mikael Abrahamsson wrote: On Sat, 3 Jan 2009, Hank Nussbacher wrote: You mean like for BGP neighbors? Wanna suggest an alternative? :-) Well, most likely MD5 is better than the alterantive today which is to run no authentication/encryption at all. But we should push whoever is developing these standards to go for SHA-1 or equivalent instead of MD5 in the longer term. Who is working on this? I don't find anything here: http://www.ietf.org/html.charters/idr-charter.html All I can find is: http://www.ietf.org/rfc/rfc2385.txt http://www.ietf.org/rfc/rfc3562.txt http://www.ietf.org/rfc/rfc4278.txt Nothing on replacing MD5 for BGP. Oh boy... 1. This isn't a break in SSL per se. It's an attack on a single CA which was still unsafely using MD5. As I understand it, they have now fixed that. So, it's not clear to what extent this has an ongoing impact. In particular, it only affects certificate-based authentication, not authentication with a shared secret, as is used in TCP-MD5. My summary of the attack can be found here: http://www.educatedguesswork.org/2008/12/understanding_the_sotirov_et_a.html 2. The MAC used in TCP-MD5 is weak by modern standards (for several reasons, not just that it uses MD5) and there is already work going on in TCPM to replace it. See draft-ietf-tcpm-tcp-auth-opt. -Ekr ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [taugh.com-standards] Re: Review of draft-ietf-dkim-ssp-08
On Sun, 2009-01-04, Dave CROCKER wrote: From: ACME Chief Officers: Alice c...@acme.example.com, Bob c...@acme.example.com; There must have been *some* concept of email that dictated that a message could be sent *to* a group but not *from* one! I don't remember whether this idea came up during discussions for RFC 733. I don't think so, although it certainly seems to me to be as reasonable to be able to apply the construct to the author field as to a recipient field. But since the construct so infrequently used, I'm not sure it's all that helpful to explore this enhancement... Well, this prompted me to go searching the RFCs, and I found out that the From: group: ... ; construct WAS allowed in RFCs 724 and 733 but was removed in 822. There are examples showing exactly this construct in the earlier RFCs (724: II.D.i and 733: V.C.9), but the corresponding example has been changed in 822 (A.2.7) and a note added specifically saying: Note that the name of the committee cannot be specified, since group names are not permitted in the From field. I'd love to see the discussion that brought about that change. :-) Anyway, this tangent has probably run it's course, so I'll drop it on this list. -- Bill McQuillan mcqui...@pobox.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [taugh.com-standards] Re: Review of draft-ietf-dkim-ssp-08
Bill McQuillan wrote: Perhaps someone knows what the Founders (of email) conceptual models were for a message (memo?) For instance, although I obviously do not understand the original intent behind the group of mailboxes construct, I have long wondered why the following is not valid: Internet mail grew out of the standalone mail system that was running on BBN's Tenex system, which had a message appearance similar to what we see today. I haven't talked with the folks who created the Tenex system, to ask about their particular choice. However I suggested an interpretation of it's perspective in RFC 733, which formally codified the model: A general memo framework is used. ... Such a framework severely constrains document tone and appearance and is primarily useful for most intra-organization communications and relatively structured inter-organization communication. A more robust environment might allow for multi- font, multi-color, multi-dimension encoding of information. A less robust environment, as is present in most single-machine message systems, would more severely constrain the ability to add fields and the decision to include specific fields. In contrast to paper-based communication, it is interesting to note that the RECEIVER of a message can exercise an extraordinary amount of control over the message's appearance. The incremental revisions to the model that were done in RFC 733, RFC 822, RFC 2822 and RFC 5322 have tweaked things, such as with the group construct you cite and, of course, with multi-media attachments (MIME). These enable a broader range of uses. So I'm not sure the 'founders' intent is all that informative or constraining, 35 years on. I think it is more helpful to note the disparity between what styles of communication email *can* support and what kinds it *does* support. Specifically, the point of my message was to note that IMF (Internet Message Format) is used for only a subset of the functions it could be used for and that (probably) it could support with no change and that. In fact, it has features intended to support those additional functions but which remain almost completely unexercised after all this time. What prompted my note was the observation that having stray bits of unexercised protocol features hanging around invites divergent implementations, as follow-on enhancements are made. The current situation with ADSP is merely a concrete example. By divergent I mean non-interoperable. So as logically compelling as the potential for those unused bits of capability are, the fact that they remain unused is demonstrably problematic, which leads to the questions of possibly deprecating them, and how to do it. From: ACME Chief Officers: Alice c...@acme.example.com, Bob c...@acme.example.com; There must have been *some* concept of email that dictated that a message could be sent *to* a group but not *from* one! I don't remember whether this idea came up during discussions for RFC 733. I don't think so, although it certainly seems to me to be as reasonable to be able to apply the construct to the author field as to a recipient field. But since the construct so infrequently used, I'm not sure it's all that helpful to explore this enhancement... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Fwd: Security team successfully cracks SSL using 200 PS3's and MD5 flaw.
I think that Hank raises a very good question. There has been a very active discussion of this on NANOG, both re SSL, BGP and in general. Here is the original link : http://hackaday.com/2008/12/30/25c3-hackers-completely-break-ssl-using-200-ps3s/ Regards Marshall Begin forwarded message: From: Hank Nussbacher h...@efes.iucc.ac.il Date: January 4, 2009 2:22:06 AM EST To: Mikael Abrahamsson swm...@swm.pp.se, na...@nanog.org na...@nanog.org Subject: Re: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. At 06:44 PM 03-01-09 +0100, Mikael Abrahamsson wrote: On Sat, 3 Jan 2009, Hank Nussbacher wrote: You mean like for BGP neighbors? Wanna suggest an alternative? :-) Well, most likely MD5 is better than the alterantive today which is to run no authentication/encryption at all. But we should push whoever is developing these standards to go for SHA-1 or equivalent instead of MD5 in the longer term. Who is working on this? I don't find anything here: http://www.ietf.org/html.charters/idr-charter.html All I can find is: http://www.ietf.org/rfc/rfc2385.txt http://www.ietf.org/rfc/rfc3562.txt http://www.ietf.org/rfc/rfc4278.txt Nothing on replacing MD5 for BGP. -Hank ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Renumbering needs work
A draft on this topic has been updated: http://www.ietf.org/internet-drafts/draft-carpenter-renum-needs-work-01.txt Comments and discussion are invited on the OPS Area list, ops-a...@ietf.org Brian Carpenter Ran Atkinson Hannu Flinck P.S. Apologies if you receive multiple copies, but that seems preferable to cross-posting to multiple lists. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
