Hiya,
On 26/05/15 18:13, Mike Liebhold wrote:
> (√) thanks. I'm glad to learn the right people are on the case from TLS
> and IPsec perspectives - but who specifically will scope out new
> prospective architectures -across the stack - for "other methods of
> creating keys, including one-time pads that are delivered via some
> out-of-band mechanism."
>
> Specifically, what are the new viable "out of band" mechanisms, and how
> would those scale effectively.
Well, for key agreement (which is the scope here) we do have some
clear recommendations - prefer ECDH (soon with our newly selected
curves, now with NIST curves) and then DH 2048 or better. And after
that probably fall back to RSA key transport. The role (if any) for
site-specific integer DH primes is being discussed on the TLS list
including with the authors of the logjam paper. My guess is they may
want to revisit a bit of the phrasing of some of the recommendations
from the paper, so we'll see how that pans out.
For lower level crypto mechanism things, then CFRG is the right
place within the IETF/IRTF though they are currently busy with
finishing the new curves work so it'll likely be a while before
they have bandwidth for much more.
That said, I don't think CFRG is a good place to invent new crypto
but rather it's a good place to figure out which of the already peer
reviewed academic cryptography work we want to take into standards,
and how, at the bit fiddling level. CFRG ought be doing the selection
(which requires real knowledge of the state of the art) and defining
the bit fiddling (where IETFers can help) but not the basic inventing
of algorithms or similar.
For that last, CHES and the crypto conferences or are really better
venues as would be any IACR journal or equivalent. Algorithm work
really is better started in a peer-reviewed academic context and not
dealt with on our mailing lists. (This thread [1] is a fine example
of why it's a bad idea to try invent stuff on our mailing lists;-)
[1] https://www.ietf.org/mail-archive/web/cfrg/current/msg06790.html
> Is that still out of scope for perpass?
Hope the above helps - the main idea of this list is to find the
right place for stuff, so asking "where" and getting views on that is
entirely correct. (And more are welcome.)
S.
>
>
> On 5/26/15 9:54 AM, Stephen Farrell wrote:
>> Hiya,
>>
>> That's being discussed at length on the TLS list. I figure any
>> conclusions from there will percolate to IPsec etc in good time.
>> Is there another angle we ought be considering too or is that
>> probably ok?
>>
>> Cheers,
>> S.
>>
>>
>> On 26/05/15 17:40, Mike Liebhold wrote:
>>> ---------- Forwarded message ----------
>>> From: *Rodney Van Meter* <r...@sfc.wide.ad.jp
>>> <mailto:r...@sfc.wide.ad.jp>>
>>> Subject: possible attack on Diffie-Hellman key exchange
>>>
>>> It seems some researchers have uncovered a way to *pre-compute* part of
>>> the function necessary for breaking D-H, in a way that depends *only* on
>>> the prime number used. It’s a substantial amount of CPU time to do, but
>>> is within the range of plausible for someone like the NSA for 1024 bit
>>> keys. The existing IKE RFC recommends (requires?) use of one of a small
>>> set of prime numbers defined at
>>> https://tools.ietf.org/html/rfc5996#appendix-B and
>>> https://tools.ietf.org/html/rfc3526
>>>
>>> Blog post from Scott Aaronson:
>>> http://www.scottaaronson.com/blog/?p=2293
>>> Follow the links to the paper, too:
>>> https://weakdh.org/imperfect-forward-secrecy.pdf
>>> Their website has more information, and a test for whether your browser
>>> is vulnerable to the same attack:
>>> https://weakdh.org/
>>>
>>> Of course, the obvious answer is to just raise the key length and/or use
>>> your own prime numbers rather than the ones in the spec, but who knows
>>> what else waits to be discovered? This serves as something of a
>>> motivation for continued work on alternatives to D-H; not because we
>>> believe D-H is inherently busted, or even that we necessarily believe
>>> that quantum key distribution (QKD) has no vulnerabilities of its own,
>>> but simply to have alternatives available as research lurches forward.
>>> We are working on documenting (as an RFC) a method for using
>>> QKD-generated keys with IKE in place of D-H. Our I-D has expired, but
>>> working is continuing, and we are actually generalizing it to support
>>> other methods of creating keys, including one-time pads that are
>>> delivered via some out-of-band mechanism.
>>> https://tools.ietf.org/id/draft-nagayama-ipsecme-ipsec-with-qkd-01.txt
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> perpass mailing list
>>> perpass@ietf.org
>>> https://www.ietf.org/mailman/listinfo/perpass
>>>
>
>
>
_______________________________________________
perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass
