http://permalink.gmane.org/gmane.ietf.saag hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.ietf.saag/3259 <pre> See also Question J of the "Crypto Gardening Guide and Planting Tips", http://www.cs.auckland.ac.nz/~pgut001/pubs/crypto_guide.txt (based on an informal survey of crypto app developers at the time). Peter. </pre> Peter Gutmann 2013-05-24T00:54:12 http://permalink.gmane.org/gmane.ietf.saag/3258 <pre> Paul&gt; The document makes an assumption that someone signing a Paul&gt; message knows the algorithm capabilities of everyone who is Paul&gt; intended to verify that signature. That seems like a very, Paul&gt; very bad assumption. Defining a new hash algorithm whose Paul&gt; benefit is to be part of a signature algorithm implies that Paul&gt; all verifiers will have the new algorithm in their Paul&gt; implementations. In online protocols with negotiation, that's Paul&gt; acceptable (but still a bit onerous). Having just spent two months debugging what ended up being a bug in how some verifiers reported the absence of SHA-256 support (and the shocking lack of SHA-256 support in places where I was kind of hoping it would be present by now), i'd like to agree with Paul that this assumption is really bad. The bar to overcome for adding a new hash algorithm in offline verification can be really high in practice. </pre> Sam Hartman 2013-05-23T18:50:15 http://permalink.gmane.org/gmane.ietf.saag/3257 <pre>The document makes an assumption that someone signing a message knows the algorithm capabilities of everyone who is intended to verify that signature. That seems like a very, very bad assumption. Defining a new hash algorithm whose benefit is to be part of a signature algorithm implies that all verifiers will have the new algorithm in their implementations. In online protocols with negotiation, that's acceptable (but still a bit onerous). However, if these signatures are also meant to be used in protocols with no negotiation (such as PKIX and CMS), then adding a new signature algorithm needs to be done only if the advantage (in this case, speed of one part of the verification) greatly outweighs the disadvantage of some verifiers having to fail completely. To date, it is extremely rare to hear "we can't use SHA256 in this signature algorithm because it is too slow". This proposal seems to be based on optimization, not actual need. These balances should be covered in the document, probably in the introducti</pre> Paul Hoffman 2013-05-23T17:47:10 http://permalink.gmane.org/gmane.ietf.saag/3256 <pre>They appear to be mentioned here: http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/algorithms.html#Hash Secure Hash Algorithm object identifiers id-sha256 OBJECT IDENTIFIER ::= { hashAlgs 1 } id-sha384 OBJECT IDENTIFIER ::= { hashAlgs 2 } id-sha512 OBJECT IDENTIFIER ::= { hashAlgs 3 } id-sha224 OBJECT IDENTIFIER ::= { hashAlgs 4 } id-sha512-224 OBJECT IDENTIFIER ::= { hashAlgs 5 } id-sha512-256 OBJECT IDENTIFIER ::= { hashAlgs 6 } On Thu, May 23, 2013 at 8:39 AM, Russ Housley &lt;housley&lt; at &gt;vigilsec.com&gt; wrote: </pre> Matthew Chalmers 2013-05-23T14:47:41 http://permalink.gmane.org/gmane.ietf.saag/3255 <pre>Quynh: Has NIST assigned OIDs for these hash algorithms? If so, it would be good to include them in this draft, even as an appendix. Russ On May 23, 2013, at 7:23 AM, Dang, Quynh wrote: </pre> Russ Housley 2013-05-23T13:39:34 http://permalink.gmane.org/gmane.ietf.saag/3254 <pre>Hi everyone, I just submitted an individual draft which I and Sean wrote together discussing recommended uses of SHA-512/224 and SHA-512/256. Below is the link to the ID. http://www.ietf.org/id/draft-dang-turner-sha-512-224-256-00.txt Your comments will be appreciated. Regards, Quynh. </pre> Dang, Quynh 2013-05-23T11:23:46 http://permalink.gmane.org/gmane.ietf.saag/3253 <pre> As I said when I forwarded the liaison, this liaison is "for information". The ITU-T is not expecting any response to the liaison. However... Without diving into ITU-T process speak... suffice it to say that the document (now called X.1037) has entered one of their approval processes. The last call for comments on the document is June 12. If you want to comment, one option is to send a liaison to the ITU-T, but the study group would probably not have time to consider the liaison before the last call closed. That may be ok, if you simply want to include ideas for the next revision of the document. The other way to comment is to submit AAP comments. That process is easy if you are a sector member of the ITU-T, but is still possible if you are not. ISOC is a sector member and can submit comments, or you can find an ITU-T sector member that agrees to submit your comments. Here is the link --&gt; http://www.itu.int/ITU-T/aap/aapid/2804/show.aspx If I can help, let me know. Regards, -scott. </pre> Scott Mansfield 2013-05-21T20:04:20 http://permalink.gmane.org/gmane.ietf.saag/3248 <pre>Some on this list might find this of interest. spt -------- Original Message -------- Subject: I-D Action: draft-saintandre-username-interop-00.txt Date: Wed, 08 May 2013 20:52:20 -0700 From: internet-drafts&lt; at &gt;ietf.org Reply-To: internet-drafts&lt; at &gt;ietf.org To: i-d-announce&lt; at &gt;ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Username Interoperability Author(s) : Peter Saint-Andre Filename : draft-saintandre-username-interop-00.txt Pages : 9 Date : 2013-05-08 Abstract: Various Internet protocols have defined constructs for usernames. This document describes a subset of characters to allow in usernames for maximal interoperability across Internet protocols. The subset might prove useful in cases where a provider offers multiple services using the same underlying identifier. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-saintandre-username-interop T</pre> Sean Turner 2013-05-09T09:33:04 http://permalink.gmane.org/gmane.ietf.saag/3247 <pre> FYI -------- Original Message -------- Subject: Just Announced: New NIST Security Controls Document - SP 800-53 Rev 4 Training Date: Tue, 07 May 2013 08:34:28 -0600 From: NIST Security Controls SP 800-53 Rev 4 Workshop &lt;Training&lt; at &gt;NIST800-53Rev4.potomacforum.org&gt; To: &lt;stephen.farrell&lt; at &gt;cs.tcd.ie&gt; Just Released NIST SP 800-53 Rev 4 (FINAL) Security Controls Document - Released on April 30th. NIST Keynote and Featured Presentation. Workshop will Present a Detailed Analysis of the Document- Please Forward To Your Associates - CIO, Security, IG, CFO, Program Managers &amp; Staff, Industry Interested in IT Security - Government &amp; Industry - New NIST Security Controls Publication SP 800-53 Revision 4 (April 30, 2013) http://www.potomacforum.org http://www.potomacforum.org Security and Privacy Controls for Federal Information Systems and Organizations Training Workshop Gov Security Controls: What is New What Has Changed How Does Rev 4 Effect Government Security Programs Government and Industry Invited to Atte</pre> Stephen Farrell 2013-05-07T14:39:56 http://permalink.gmane.org/gmane.ietf.saag/3246 <pre>Security People, AVTCORE WG are developing an overview document over available security options for RTP. As several of these comes from various corners of the security area as well as some being developed in AVT WG. I am thus requesting review of this document. Or maybe you want to be astonished of the flora of things you have produced that can be applied to securing a protocol like RTP in its various usages. Thanks Magnus Westerlund </pre> Magnus Westerlund 2013-05-06T09:57:08 http://permalink.gmane.org/gmane.ietf.saag/3244 <pre>We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit t</pre> hammondjohnson< at >hushmail.com 2013-04-27T18:03:04 http://permalink.gmane.org/gmane.ietf.saag/3243 <pre> Hiya, If someone is interested in a security related BoF in Berlin you probably need to be talking to Sean or me real soon now. The dates are: • 2013-06-17 (Monday): Cutoff date for BOF proposal requests to Area Directors at UTC 24:00. To request a BOF, please see instructions on Requesting a BOF. • 2013-06-20 (Thursday): Cutoff date for Area Directors to approve BOFs at UTC 24:00. Cheers, S. </pre> Stephen Farrell 2013-04-23T20:33:13 http://permalink.gmane.org/gmane.ietf.saag/3242 <pre>Hi, The AVTCORE WG has developed this application of AES-GCM and AES-CCM as cipher suit for SRTP. I would really appreciate if some more security knowledgeable would take a look at it before we request publication. If they have any understanding of SRTP it would be a big plus. https://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-aes-gcm/ Thanks Magnus Westerlund AVTCORE WG chair </pre> Magnus Westerlund 2013-04-18T13:37:54 http://permalink.gmane.org/gmane.ietf.saag/3241 <pre>A new draft "SSH Key Management for Automated Access - Current Recommended Practice" is now available at https://tools.ietf.org/html/draft-ylonen-sshkeybcp-01 The draft is relevant for anyone interested in SSH user key management and more generally identity and access management. We have found hundreds of thousands to millions of SSH authorized keys from the IT environments of many large enterprises (many times more than they have interactive users), and bringing key-based access under control is very important. The draft outlines the risks with unmanaged key-based access and presents a process for remediating the situation in an existing environment and implanting an ongoing process for monitoring and managing key-based access (and other automated passwordless access). I am hoping the draft will evolve into a BCP (Best Current Practice) standard on managing SSH user keys in organizations. The draft is mostly about process and policy, not technical protocols, as SSH user key management is really an iden</pre> Tatu Ylonen 2013-04-06T13:45:12 http://permalink.gmane.org/gmane.ietf.saag/3240 <pre> The httpbis wg are trying to figure out how to do compression in HTTP/2.0 in a way that's not so vulnerable to the CRIME attack. They'd like additional security eyeballs on what is quite a tricky problem. If you're willing and able to help then that'd be best done on the httpbis wg list. Any other questions feel free to ask me or Mark (httpbis wg chair, cc'd) offlist. S. -------- Original Message -------- Subject: Fwd: Choosing a header compression algorithm Date: Sat, 30 Mar 2013 16:50:32 +1100 From: Mark Nottingham &lt;mnot&lt; at &gt;mnot.net&gt; To: Stephen Farrell &lt;stephen.farrell&lt; at &gt;cs.tcd.ie&gt;, Sean Turner &lt;turners&lt; at &gt;ieca.com&gt; Any input from Security would be most welcome here… Cheers, Begin forwarded message: -- Mark Nottingham http://www.mnot.net/ </pre> Stephen Farrell 2013-03-30T11:39:40 http://permalink.gmane.org/gmane.ietf.saag/3239 <pre> On Mar 25, 2013, at 12:02 PM, Bob Hinden &lt;bob.hinden&lt; at &gt;gmail.com&gt; wrote: See, for example, http://arstechnica.com/security/2012/12/25-gpu-cluster-cracks-every-standard-windows-password-in-6-hours/ --Steve Bellovin, https://www.cs.columbia.edu/~smb </pre> Steven Bellovin 2013-03-26T18:04:36 http://permalink.gmane.org/gmane.ietf.saag/3238 <pre>Hello, I believe the attached version addresses all of the outstanding questions. Please let me know if there are any further comments. Once version 1.0 is published, then we can work on the more extensive changes in a revision. Thank you, Kathleen -----Original Message----- From: internet-drafts&lt; at &gt;ietf.org [mailto:internet-drafts&lt; at &gt;ietf.org] Sent: Monday, March 25, 2013 2:11 PM To: Moriarty, Kathleen Cc: mnystrom&lt; at &gt;microsoft.com; Parkinson, Sean; Rusch, Andreas; Scott, Michael2 Subject: New Version Notification for draft-moriarty-pkcs12v1-1-01.txt A new version of I-D, draft-moriarty-pkcs12v1-1-01.txt has been successfully submitted by Kathleen M. Moriarty and posted to the IETF repository. Filename: draft-moriarty-pkcs12v1-1 Revision: 01 Title: PKCS 12 v1: Personal Information Exchange Syntax Creation date: 2013-03-25 Group: Individual Submission Number of pages: 29 URL: http://www.ietf.org/internet-drafts/draft-moriarty-pkcs12v1-1-01.txt Status: http://datatracker.ietf.org/d</pre> Moriarty, Kathleen 2013-03-25T18:36:11 http://permalink.gmane.org/gmane.ietf.saag/3235 <pre>Because as processors get faster, the relative amount of work remains constant at 2^59, but the absolute amount of processing time per operation decreases for both attacker and defender. So the absolute amount of time required to mount a successful attack also decreases over the long term. At some point, the absolute amount of time required to mount an attack will eventually be comparable to the amount of time an address is in use, which makes attacks attractive. Eventually you either have to reduce the time the CGA address remains in use, or make the algorithm more complex for both attacker and defender [add sec]. c.f. DES -&gt; triple DES. _______________________________________________ saag mailing list saag&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/saag </pre> Ray Hunter 2013-03-25T06:35:04 http://permalink.gmane.org/gmane.ietf.saag/3233 <pre> 2^59 is a rather large number. Everything else being equal, another 1 second of computation at the user translates into another 18 billion years at the attacker. </pre> Christian Huitema 2013-03-25T04:33:40 http://permalink.gmane.org/gmane.ietf.saag/3231 <pre>I have a simpler solution (assuming to-be-matched bits are high order, if they are not 2 must be replaced by 2**k) - pick one prime number - divide the modulus to get the second prime number range - for all odd numbers in the range (fast) check it is prime Note the standard RSA generation is: - pick a bunch of random bits of the wanted size - fast checks it is prime, if it is not retry, if it is got a prime Apply this twice to get the 2 primes, compute the modulus, private exponent and CRT coefficients with a (given too) public exponent. So I argue it is not significantly more expensive to break a SSAS (*) than to generate a new RSA key pair. Regards Francis.Dupont&lt; at &gt;fdupont.fr PS (*): the solved problem is to find a valid RSA key pair which shares N contiguous bits of the modulus, N &lt;&lt; size(modulus) (verified for any SSAS like as 64 &lt;&lt; 1024. PPS: Christian's argument applies for ECDSA (I expect ECDSA will replace by RSA in the SSAS proposal if it is not simply withdrawn) so if nobody has a quicker wa</pre> Francis Dupont 2013-03-23T12:26:25 http://permalink.gmane.org/gmane.ietf.saag/3229 <pre> Oops. Thanks. S On 03/23/2013 12:38 AM, Yoav Nir wrote: </pre> Stephen Farrell 2013-03-23T00:59:11 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.saag