Subject: [Cfrg] considering new topics for CFRG

From: David McGrew <[email-masked]>
Date: Fri, 03 Jan 2014 19:28:26 -0500

Hi,

recently, Stephen and others suggested some topics that seem worth 
considering as future work for this research group.   I want to expand 
on those suggestions, and solicit your input.  If there is sufficiently 
broad interest, and people willing to contribute, than we can consider 
taking it on.   The goal of this note is to gauge interest in some 
topics that I have heard others talk about, and some that I think are 
worthwhile.  Recall that CFRG is a bridge between theory and practice, 
and traffic can go in both directions. The practice community can 
identify unsolved problems and new issues that aren't dealt with in 
theory.   Conversely, the theory community can introduce new results.

Stephen, Sean, please do let us know what work would be most useful to 
the IETF Security Area, and what work would be less useful or would 
conflict with IETF chartered work.   Thanks!

Useful topics on side channel attacks:

- Documenting ways of implementing existing algorithms that resist 
side-channel attacks, especially timing attacks.   This could include 
documentation of naive implementation methods that are vulnerable, or 
experimental work quantifying vulnerabilities.

- The development of testing methodologies for crypto implementations 
that can identify vulnerabilities to side-channel attacks.  A test 
harness that runs in separate software or hardware that interacts with a 
target crypto implementation could collect timing statistics, which 
could then be analyzed to check for vulnerabilities.   There are crypto 
module validation schemes such as CMVP that are widely used.   Why don't 
we develop a testing methodology for such schemes that would identify 
timing vulnerabilities?

- The design, identification, and/or specification of algorithms that 
resist side channel attacks.

- The design, identification, and/or specification of algorithms that 
lack subliminal channels; that is, algorithms that would be hard to 
implement in a way that subverted the privacy of the user without their 
knowledge.   Also interesting would be testing methodologies that detect 
such channels, possibly including static analysis of source code, or 
statistical analysis of random or pseudorandom sources.

Useful topics in crypto algorithm design:

- Authenticated encryption that does not require an application to 
manage nonces and/or is robust against nonce misuse.

- Simplicity of design as a way to achieve robust crypto implementations.

- Recommendations on algorithms that should be used.   This could 
include recommendations on DRBGs.

Useful topics in provable security:

- A document describing the hierarchy of goals for security proofs, and 
recommendations on what IETF WG expectations should be regarding such 
proofs.   It would also be useful to describe the important security 
models, and to provide referenceable common definitions.

- Provably secure designs for complex protocols.   For instance: can 
there be a provably secure protocol that provides the same level of 
critical functionality as TLS, yet at the same time has been proven 
secure using techniques and/or tools that are accessible to many reviewers?

Useful topics in privacy

- Analyzing and documenting the limitations on privacy/anonymity 
technologies in the Internet protocols.   For example: if your MAC 
address and/or IPv6 address are traceable, then cryptography is not 
going to get you strong anonymity, no matter what crypto you use. 
Additionally, analysis of packet lengths and timings can reveal a lot of 
information.   Existing IETF security protocols have message-length 
hiding mechanisms, but these are not very effective.   If we are wiling 
to add latency and consume extra bandwidth, we could improve security in 
this area.   Is it worth it?

No doubt this is not an exhaustive list, and if you have other topics to 
put forward, please send them to the list and keep "considering new 
topics" in the subject line to make it easier to keep track.

One topic that I didn't list above, because it is somewhat outside of 
CFRG's traditional scope, is security in Cloud environments.  To my 
thinking, the industry trend towards putting all the data one can get a 
hold of into multi-tenant, virtualized environments is one of the 
biggest threats to information security and privacy.   Maybe I trust the 
Cloud provider to be well intentioned, but can I actually trust them to 
maintain data security?    I didn't try to craft a topic along this line 
because it goes beyond the scope of communication security.

regards,

David

---

From: Sean Turner <[email-masked]>
Date: Fri, 3 Jan 2014 20:43:57 -0500

David,

I’ve got some thoughts about the process question that I’ll put in another email to not muddy up the more interesting technical thread.

spt

On Jan 03, 2014, at 19:28, David McGrew <[email-masked]> wrote:

> Hi,
> 
> recently, Stephen and others suggested some topics that seem worth considering as future work for this research group.   I want to expand on those suggestions, and solicit your input.  If there is sufficiently broad interest, and people willing to contribute, than we can consider taking it on.   The goal of this note is to gauge interest in some topics that I have heard others talk about, and some that I think are worthwhile.  Recall that CFRG is a bridge between theory and practice, and traffic can go in both directions. The practice community can identify unsolved problems and new issues that aren't dealt with in theory.   Conversely, the theory community can introduce new results.
> 
> Stephen, Sean, please do let us know what work would be most useful to the IETF Security Area, and what work would be less useful or would conflict with IETF chartered work.   Thanks!
> 
> - Documenting ways of implementing existing algorithms that resist side-channel attacks, especially timing attacks.   This could include documentation of naive implementation methods that are vulnerable, or experimental work quantifying vulnerabilities.
> 
> - The development of testing methodologies for crypto implementations that can identify vulnerabilities to side-channel attacks.  A test harness that runs in separate software or hardware that interacts with a target crypto implementation could collect timing statistics, which could then be analyzed to check for vulnerabilities.   There are crypto module validation schemes such as CMVP that are widely used.   Why don't we develop a testing methodology for such schemes that would identify timing vulnerabilities?
> 
> - The design, identification, and/or specification of algorithms that resist side channel attacks.
> 
> - The design, identification, and/or specification of algorithms that lack subliminal channels; that is, algorithms that would be hard to implement in a way that subverted the privacy of the user without their knowledge.   Also interesting would be testing methodologies that detect such channels, possibly including static analysis of source code, or statistical analysis of random or pseudorandom sources.
> 
> 
> - Authenticated encryption that does not require an application to manage nonces and/or is robust against nonce misuse.
> 
> - Recommendations on algorithms that should be used.   This could include recommendations on DRBGs.
> 
> 
> - A document describing the hierarchy of goals for security proofs, and recommendations on what IETF WG expectations should be regarding such proofs.   It would also be useful to describe the important security models, and to provide referenceable common definitions.
> 
> - Provably secure designs for complex protocols.   For instance: can there be a provably secure protocol that provides the same level of critical functionality as TLS, yet at the same time has been proven secure using techniques and/or tools that are accessible to many reviewers?
> 
> 
> Useful topics in privacy
> 
> - Analyzing and documenting the limitations on privacy/anonymity technologies in the Internet protocols.   For example: if your MAC address and/or IPv6 address are traceable, then cryptography is not going to get you strong anonymity, no matter what crypto you use. Additionally, analysis of packet lengths and timings can reveal a lot of information.   Existing IETF security protocols have message-length hiding mechanisms, but these are not very effective.   If we are wiling to add latency and consume extra bandwidth, we could improve security in this area.   Is it worth it?
> 
> No doubt this is not an exhaustive list, and if you have other topics to put forward, please send them to the list and keep "considering new topics" in the subject line to make it easier to keep track.
> 
> One topic that I didn't list above, because it is somewhat outside of CFRG's traditional scope, is security in Cloud environments.  To my thinking, the industry trend towards putting all the data one can get a hold of into multi-tenant, virtualized environments is one of the biggest threats to information security and privacy.   Maybe I trust the Cloud provider to be well intentioned, but can I actually trust them to maintain data security?    I didn't try to craft a topic along this line because it goes beyond the scope of communication security.
> 
> regards,
> 
> David
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg

---

From: Henrick Hellström <[email-masked]>
Date: Sat, 04 Jan 2014 03:20:17 +0100

> experimental work quantifying vulnerabilities.

I find this very interesting, in particular considering that things like 
arithmetics often get implemented using either an input dependent number 
of instructions, or if with a constant number of instructions, with 
branches, or if not, with branch-less pointer swapping, instead of 
branch-less memory swapping.

Hence, potentially vulnerable implementations have either of the 
following features:

- branches, except loops with a number of iterations that must only 
depend on public parameter values (such as "bit sizes"),
- value dependent memory access, including branch-less pointer swapping

Conversely, any algorithm that can be implemented in such way that the 
number of instructions performed, and the memory addresses accessed, *do 
not* depend of the value of the arguments, can only be vulnerable if the 
CPU itself does not execute individual instructions in constant time.

---

From: David Wagner <[email-masked]>
Date: Fri, 03 Jan 2014 18:41:43 -0800

> we develop a testing methodology for such schemes that would identify 

Back in 2005, David Molnar, Matt Piotrowski, David Schultz,
and I proposed a simple method for testing for side channel
vulnerabilities.  You instrument the program with gcov, then run it
many times with many different randomly chosen keys (but with
all other inputs held fixed), using gcov to gather a set of statement
coverage statistics separately for each different key.  Then, you
look at the statement coverage statistics that gcov produced.
If you find any line in the code that was executed more times
for some keys than for others, you have found a potential
side channel vulnerability, as you've found some evidence that
whether or not that line will be executed depends upon the value
of the key.

We did a few small-scale experiments, and it seems to work
surprisingly well at finding vulnerabilities.  It's not perfect, but
the main advantage is that it is very easy to implement and try.
You can read more about our experiments with it in Section 4
of the following paper:

The Program Counter Security Model: Automatic Detection and
Removal of Control-Flow Side Channel Attacks.
David Molnar, Matt Piotrowski, David Schultz, and David Wagner.
ICISC 2005, December 1, 2005.
http://www.cs.berkeley.edu/~daw/papers/pcmodel-long.pdf

As far as I know, the main limitations are that it is oriented
primarily at deterministic algorithms (rather than ones that
internally flip random coins and use them), and it relies upon
gcov for coverage statistics, and gcov isn't always great
when the code is compiled with optimization.

-- David

---

From: Henrick Hellström <[email-masked]>
Date: Sat, 04 Jan 2014 04:02:04 +0100

> whether or not that line will be executed depends upon the value

This method will not detect timing differences caused by cache misses. 
(Think table look-ups, or branch-less pointer swapping.)

---

From: Trevor Perrin <[email-masked]>
Date: Fri, 3 Jan 2014 22:05:16 -0800

On Fri, Jan 3, 2014 at 7:02 PM, Henrick Hellström <[email-masked]> wrote:
>> vulnerabilities.
[...]
> (Think table look-ups, or branch-less pointer swapping.)

The "transcript" idea from David's paper is a nice way to think about
sidechannel security.

For another tool, check out Adam Langley's "ctgrind":

https://github.com/agl/ctgrind

Trevor

---

From: Henrick Hellström <[email-masked]>
Date: Sat, 04 Jan 2014 11:48:31 +0100

> The "transcript" idea from David's paper is a nice way to think about

Don't get me wrong, it is necessary for your code to pass the test 
outlined in the paper, but in light of more recently published side 
channel attacks, it is not sufficient.

> https://github.com/agl/ctgrind

Thanks, but considering that relevant code might not be implemented in 
C/C++, is there any specification of the abstract requirements for such 
testing, or perhaps a tool for a language agnostic profiler?

---

From: Paul Lambert <[email-masked]>
Date: Sat, 4 Jan 2014 03:20:36 -0800

My wish list for 2014:

 - A public key based ¹trust¹ architecture to
   determine ³who can do what² (not based on X.509 or PGP)
 - Public key based methods that can be readily be used
   to both sign data and be used to develop encryption keys
 - Nonce insensitive or deterministic encryption modes
   to support group multicast in a mesh topology
 - Elliptic curves for cryptographic use that are developed
   in a transparent manner that dispels any possible mistrust
 - Algorithm modes that have infinite error extension
   (verus CCM, 1 bit plaintext change -> 1 bit ciphertext)
 - Secure time stamps
 - A 'setup process' based on public keys to enable
   the secure configuration of consumer products
 - Strong P2P authentication for Wi-Fi devices
 - Ephemeral MAC Addresses
 - Deprecation and abolishment of known bad algorithms:
   in a manner that impacts real products
   (e.g. TKIP, WEP, DES, RC4)

Paul

---

From: David McGrew <[email-masked]>
Date: Sun, 05 Jan 2014 19:22:17 -0500

Hi Paul,

thanks for your suggestions.

>     determine ³who can do what² (not based on X.509 or PGP)

This is an intriguing thought, but probably something out of scope for 
CFRG.   (Seems more like a PKNG thing if I understand you right.)

>     to support group multicast in a mesh topology

I'm with you on that one.

>     in a transparent manner that dispels any possible mistrust

Yes, this is a good one.  I think there is sufficient interest in this 
topic in the IETF to warrant this work.

>     (verus CCM, 1 bit plaintext change -> 1 bit ciphertext)

This seems in scope.

>   - Ephemeral MAC Addresses

Would be interesting.   Probably not in our RG scope, I would guess.

>     (e.g. TKIP, WEP, DES, RC4)

CFRG can't initiate the standards that deprecate algorithms, but there 
are probably things that we can do to hilight the need for that 
deprecation (in practice as well as in standards).   One thing I'd like 
to see is the cipher-catalog get completed, with some clear guidance in 
it on what is recommended and what is not.   It would be great to see 
that RFC get referenced in open source, for example.

David

> .

---

From: David McGrew <[email-masked]>
Date: Sun, 05 Jan 2014 19:27:37 -0500

I had forgotten an important topic from my list:

- Postquantum cryptography.   Signing algorithms based on hash functions 
(based on the work of Merkle and Hulsing) will not be too hard.  
Encryption based on codes would need more review, but should be 
possible; Bernstein and others have done good work in this area 
recently.   Other encryption and signature schemes could be considered 
as well.  Also useful would be parameter and algorithm guidance for 
postquantum security.

David

---

From: David McGrew <[email-masked]>
Date: Sun, 05 Jan 2014 19:39:13 -0500

Hi David,

> when the code is compiled with optimization.

Thanks for reminding the group about this work, it is a good set of 
ideas.   I especially like that it uses a dynamic rather than purely 
static analysis.  Was there ever follow-up research on how to better 
deal with optimized code?

These ideas can be used during software development.   That's definitely 
a good thing.   But what I meant to suggest above was something a little 
different: a test harness that gathers statistics that are usable to 
check for timing attacks, which can be run on a software library or 
hardware module provided by someone else.   My goal here is providing a 
level of third-party validation on the crypto implementation.    This 
would enable a somone who uses a crypto implementation to test it (or to 
rely on a test result from a third party that they trust), and it would 
give a vendor a way to showcase the absence of side channels (and a good 
motivation to be diligent in eliminating them).   Now, a run-time check 
like this will likely have less statistical power than than a 
development-time check like you describe, but there is a lot of value in 
allowing anyone to run the test.

David

---

From: Paul Lambert <[email-masked]>
Date: Mon, 6 Jan 2014 12:32:48 -0800

> -----Original Message-----
> From: David McGrew [mailto:[email-masked]]
> > My wish list for 2014:
> >

There was an IETF PKNG that died with no visible results. 
This is an area where the IETF seems either too unfocused or mired
in existing PKI to make progress.  Hence it's on my wish list ...
Let me know if you have any suggestion for other viable forums in IETF
for such a topic.

> I'm with you on that one.
This came out of my personal requirements for the above framework.
Having a public key for encryption versus one for signing greatly
complicated our frameworks for security.

> topic in the IETF to warrant this work.
This could be addressed quite quickly by simply regenerating seed values
for a few of the small Weistrass based curves.

I'd suggest that we could define a seed entropy process that would allow
multiple individuals/groups to contribute seed values that would be combined
in a three phase process. Phase 1 - send a Commit
  commit_i = h(nonce_i, seed_i)
After some deadline, Phase 2 - send Reveal
  Reveal_i = nonce_i, seed_i

Phase 3 - combine submitted seeds.
  def seed(seed_list): 
    hash = h()
    for s in seed_list: 
       hash.update(s)
    return hash.digest()

A distributed community based process for creating trusted random values would be valueable.

> Would be interesting.   Probably not in our RG scope, I would guess.
Yes ... unfortunately.  The actual application of crypto in protocols
is generally more interesting and useful than raw math functions (IMO :-).
Applications also creates new requirements for algorithms and their usage

> that RFC get referenced in open source, for example.
A catalog with very clear and strong recommendations would help solve this problem.

Paul

> >> on those suggestions, and solicit your input.  If there is
> >> sufficiently broad interest, and people willing to contribute, than
> we can consider
> >> worthwhile.  Recall that CFRG is a bridge between theory and
> >> practice, and traffic can go in both directions. The practice
> >> community can identify unsolved problems and new issues that aren't
> dealt with in
> >> Stephen, Sean, please do let us know what work would be most useful
> >> to the IETF Security Area, and what work would be less useful or
> would
> >> harness that runs in separate software or hardware that interacts
> >> with a target crypto implementation could collect timing statistics,
> which
> >> - A document describing the hierarchy of goals for security proofs,
> >> and recommendations on what IETF WG expectations should be regarding
> such
> >> No doubt this is not an exhaustive list, and if you have other
> topics
> >> to put forward, please send them to the list and keep "considering
> >> new topics" in the subject line to make it easier to keep track.
> >>
> >> thinking, the industry trend towards putting all the data one can
> get
> >> a hold of into multi-tenant, virtualized environments is one of the

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 06 Jan 2014 22:39:48 +0000

> There was an IETF PKNG that died with no visible results. 

That was an IRTF RG. IMO it never had a cadre of researchers
nor a sufficient set of IETF participants who were interested
in a nextgen thing.

> Let me know if you have any suggestion for other viable forums in IETF

We have a list where we discussed certificate transparency but
which has a broader remit. [1] That's discussing whether or
not to start a new CT WG in the IETF at the moment.

There's the wpkops WG for operational issues related to the
web PKI. [2] They could do with help in terms of cycles to do
already-identified work (not hugely interesting for a
security/crypto researcher though probably).

The PKIX list [3] is still open, and would be a good place to
talk about any X.509-related PKI stuff. Not so good for non
X.509 based PKI though maybe unless for an approach that's
very much evolutionary and starts from X.509.

And there's the saag list [4] which is for general security
topics if none of the above fit.

So stuff is happening and there are places to discuss and
propose stuff. And Sean and I would be quite happy to try
help PKI nextgen stuff progress in the IETF should there
be credible proposals.

However, current PKI is not an easy thing to displace, no
matter how much you dislike parts or all of it. The main
reasons IMO are that replacements are likely to suffer a lot
of the same (or equivalent) complexity since its a complex
problem, and that any credible replacement will take at least
a few years to work out and them 5-10 to get deployed which
seems to be beyond the horizon for researchers (speaking as
one who chases funding;-). One could argue that that's why
of all the "large DB of public keys" approaches, only CT
seems to be left standing.

One other thing - listing the problems with the current PKI
is not likely to be a useful place to start. We know those,
and any credible approach would start with a fairly well
worked out proposal, including consideration of that 5-10
year overlap period. Its not easy;-)

Having said all that though, CT is I think a good proof of
concept that the large-DB-of-public-keys thing could be
a runner, and we have learned a lot about the wrinkles in
X.509 based PKI over the years so there is hope maybe.

S.

PS: For any of [1]-[4] please check the archives before
diving in, or ask someone who might be familiar, which
could include me.

[1] https://www.ietf.org/mailman/listinfo/therightkey
[2] http://tools.ietf.org/wg/wpkops/
[3] https://www.ietf.org/mailman/listinfo/pkix
[4] https://www.ietf.org/mailman/listinfo/saag

---

From: William Whyte <[email-masked]>
Date: Mon, 6 Jan 2014 17:45:08 -0500

Hi all,

> Encryption based on codes would need more review, but should be possible;
Bernstein and

> others have done good work in this area

postquantum security.

(full disclosure: my company, Security Innovation, holds the patents for
the NTRU cryptosystems, which are among the leading candidates for use as
post quantum algorithms. We've recently made the patents available to use
under GPL or a range of other FOSS licenses -- see
https://github.com/NTRUOpenSourceProject/ntru-crypto/blob/master/LICENSE.md,
https://github.com/NTRUOpenSourceProject/ntru-crypto/blob/master/FOSS%20Exception.md
).

I agree that postquantum crypto is important and CFRG has a valuable role
to play in recommending algorithms for use.

However, I'd also like to see the internet community move away from using a
single public key algorithm per message or session. Any data that's
encrypted with a single public key algorithm is vulnerable to a single
cryptographic breakthrough, whether that's a classical or quantum
algorithm. An adversary who stores a large amount of historical traffic may
well be able to decrypt it in the future. This is particularly the case
with ECC and RSA-based ciphersuites because of the known threat from
quantum computing, but any algorithm is potentially vulnerable.

I'd like to see some thought given to how different public key algorithms
can be used in parallel so that a session has the strength of at least the
strongest of them. For TLS this is in principle pretty easy -- split the
master secret into two or more XORed strings, encrypt each with a different
public key algorithm, XOR the decrypted results together (or use a key
exchange algorithm to derive one or more of the XOR strings) -- but the
details may be tricky and CFRG can help here.

Combined public key algorithms would help give improved protection to users
against attacks yet to be discovered. It might also help with migration --
service providers might be unwilling to migrate directly to a newer
algorithm like for example NTRU from a more widely understood one like for
example ECDH, but using both in parallel gives the assurance associated
with ECDH plus the (assumed) quantum resistance of NTRU.

In general, solutions based on a single public key algorithm run the risk
of baking in a single point of failure. Migration from one solution to
another will be hard; migrating from one single point of failure to another
runs the risk that we'll have to migrate again, which would be extremely
hard. Much better for the internet community to think about how to put in
place a system that we can change parameters in (such as choice of
algorithm) without having to change the underlying framework. This would
fit in with the catalog of clear and strong recommendations that Paul
Lambert mentioned in another mail: the catalog could contain different
algorithms with different properties, allowing implementers to select a
combination that gave the properties they want.

When potential new work areas are raised on CFRG, it's fair to ask who's
going to actually do the work, so let me state for the record that Security
Innovation is willing to commit resources to help get this work done within
the CFRG in 2014 and onwards. We obviously have an interest in that we
think it'll make adoption of NTRU easier, but it also seems like the right
thing to do.

Cheers,

William

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 06 Jan 2014 22:50:53 +0000

Oops - and I forgot one of my own WGs:-) The DANE WG [0]
has developed PKI based on DNS and depending on DNSSEC
and is doing work on a few extensions still.

S.

[0] http://tools.ietf.org/wg/dane/

---

From: Watson Ladd <[email-masked]>
Date: Mon, 6 Jan 2014 15:04:54 -0800

> complicated our frameworks for security.

Why not have the primary master signing key sign individual keys for each role?

This is an interesting problem, but one that is quite nasty: you need
to show that
solving a problem with access to some oracles is still reducible to a
hard problem.
For some commonly deployed schemes (RSA, I'm looking at you) this separation is
necessary.

Public key encryption isn't actually necessary: hybrid encryption is
much, much nicer to live with
and implement. Look up the history of OAEP for a reminder of just how
tough it is. By contrast if
RSA based key agreement is needed, H(C, P) for ciphertext C and
plaintext P does an excellent job.
Look ma, no padding!

In the ROM I think you can show that exposing that oracle doesn't hurt
the security of signing, but I
can't remember what exactly RSA signing looks like. I do DH based
schemes almost exclusively.

The reason we use one key for each job is it makes life easy in the
land of proofs: everything composes.
The instant things become dependent on each other, life gets unfun.

> for a few of the small Weistrass based curves.

What is wrong with Curve25519 or the bigger variants?
> Phase 3 - combine submitted seeds.

As has been pointed ad nauseam, this only works if you are one of the
seed producers.
We don't need seeds to pick good curves: just some MAGMA scripts (or
PARI, or SAGE).
DJB and Paulo Barrato have already done this: I don't see CFRG as
having a comparative advantage
in this area.

>> >     (verus CCM, 1 bit plaintext change -> 1 bit ciphertext)

I really don't like this at all. Error extension has a terrible
history of being used as a heuristic
for the security of protocols that were later busted wide open,
because attackers are smart.
Infinite-garble extension in Kerberos is the example that comes to mind.

There is a notion of wide-block PRP that actually does what you are
looking for, I think. AERO relies
on that. Yes, it's inefficient, but it exists. What sort of
requirement do you want this new mode
to meet, and why should we care about meeting it? What gains does it
get over existing
modes and notions of security?

> Applications also creates new requirements for algorithms and their usage

I would actually like this to be in scope. If we can discuss what the
commercial needs are
that current solutions aren't meeting, we have a chance at drumming up
interest in good
solutions. Although I feel that hardwired configuration ports are
usually decent enough for the specific
case mentioned by grandparent.

Most applications require secure point to point communication with
authentication. Multiparty computation
has been used exactly once in the real world, namely for a sugar beet
auction on an island in Denmark.
I don't really see new requirements on core algorithms coming from the
sort of people who care about
the I(E|R)TF standardization status of whatever they use.

> A catalog with very clear and strong recommendations would help solve this problem.

I think this is an excellent idea.
Time for me to put in some grunt work.

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Paul Lambert <[email-masked]>
Date: Mon, 6 Jan 2014 16:46:27 -0800

> From: Watson Ladd [mailto:[email-masked]]
> Sent: Monday, January 06, 2014 3:05 PM
> To: Paul Lambert
> Cc: David McGrew; Sean Turner; [email-masked]
> Subject: Re: [Cfrg] considering new topics for CFRG
>
> > This is an area where the IETF seems either too unfocused or mired in
> > existing PKI to make progress.  Hence it's on my wish list ...
Possible - but it's more complexity and bits to send.
Also - I'm not asking for roles ... which might in a more complex
authorization model support a large number of keys and associated roles/attributes.

Given a public key, we have arbitrary limitations that declare that
signatures MUST use one key and encryption must use another.

> to show that solving a problem with access to some oracles is still
> reducible to a hard problem.
> For some commonly deployed schemes (RSA, I'm looking at you) this
> separation is necessary.
There are proposed uses of Ed25519.

> much, much nicer to live with and implement. Look up the history of
> OAEP for a reminder of just how tough it is. By contrast if RSA based
> key agreement is needed, H(C, P) for ciphertext C and plaintext P does
> an excellent job.
> Look ma, no padding!
>
> the security of signing, but I can't remember what exactly RSA signing
> looks like. I do DH based schemes almost exclusively.
>

This tends to be one of the problems with modern crypto.
Easy proofs may not make the best overall system design.

Many 'key usage guidelines' also mandate different keys because of
different lifetime and usage models of encryption versus signatures.
Specifically - the guidelines say that encryption keys must be different
so the encryption keys can be escrowed.  Signature keys do not need escrow.

This and many other guidelines indicate an inherent double standard
where signatures are good for mass deployment, but encryption must
be handled differently.

One public key should be able to do the suite of necessary
operations.  Specifically - signatures and pair-wise key establishment.

Mechanisms exist - but industry or NIST 'approval' of this architecture is lacking.

> >> Yes, this is a good one.  I think there is sufficient interest in
> >> this topic in the IETF to warrant this work.
> > This could be addressed quite quickly by simply regenerating seed
> > values for a few of the small Weistrass based curves.
>
Yes - they are possible ... but the overall requirement is
dispel any mistrust.   Curve25519 is relatively new and this group
could help review/bless/approve it's usage.  Academic papers
do not cut it for industry application. NIST, IETF or other
industry groups need to make clear recommendations with
transparent justifications.

> >
> > I'd suggest that we could define a seed entropy process that would
> > allow multiple individuals/groups to contribute seed values that
> would
> > be combined in a three phase process. Phase 1 - send a Commit
Longer debate possible ... but this was just one approach to
demonstrating the provenance of a selected number.

> We don't need seeds to pick good curves: just some MAGMA scripts (or
Perhaps ... but recently I've seen considerable debate about
about NIST curves and the seed selection not being well documented.

Seems easy to fix the provenance issue by re-selecting parameters.

> having a comparative advantage in this area.
Perhaps ... but adoption in real products requires some level
of documented review and acceptance.  The CFRG could provide
a basic set of recommendations that would mitigate concerns
about 'special numbers' being injected into the standar.

> I really don't like this at all. Error extension has a terrible history
> of being used as a heuristic for the security of protocols that were
> later busted wide open, because attackers are smart.
I am not suggesting that it is the only heuristic.  This is for whatever reasons
a type of operation that is widely avoided in real systems.

CCM and GCM are nonce sensitive partly for this one-to-one bit stream
cipher mapping.

> looking for, I think. AERO relies on that. Yes, it's inefficient, but
> it exists. What sort of requirement do you want this new mode to meet,
> and why should we care about meeting it? What gains does it get over
> existing modes and notions of security?
Wide-block PRP is interesting.  I need to spend more time looking at AERO.

> commercial needs are that current solutions aren't meeting, we have a
> chance at drumming up interest in good solutions. Although I feel that
> hardwired configuration ports are usually decent enough for the
> specific case mentioned by grandparent.
I'm currently working on the last three above in other forums.
They could be separate topics, but if you consider addresses to
Be ephemeral than it changes the way you look at authentication.

> authentication. Multiparty computation has been used exactly once in
> the real world, namely for a sugar beet auction on an island in
> Denmark.
Never mentioned multi-party.  It has been used in more than your named example.

> sort of people who care about the I(E|R)TF standardization status of
> whatever they use.
>
> >>
> >> CFRG can't initiate the standards that deprecate algorithms, but
> >> there are probably things that we can do to hilight the need for
> that
Great.
We need to prune the tree of algorithms to enable new ones to florish.

Paul

> >> >> Stephen, Sean, please do let us know what work would be most
> >> >> useful to the IETF Security Area, and what work would be less
> >> >> useful or
> >> would
> >> >> documentation of naive implementation methods that are
> vulnerable,
> >> or
> >> >> module validation schemes such as CMVP that are widely used.
> Why
> >> don't
> >> >> lack subliminal channels; that is, algorithms that would be hard
> >> >> to implement in a way that subverted the privacy of the user
> >> >> without
> >> their
> >> >> such channels, possibly including static analysis of source code,
> >> >> or statistical analysis of random or pseudorandom sources.
> >> >>
> >> >>
> >> >> - A document describing the hierarchy of goals for security
> >> >> proofs, and recommendations on what IETF WG expectations should
> be
> >> >> regarding
> >> such
> >> >> there be a provably secure protocol that provides the same level
> >> >> of critical functionality as TLS, yet at the same time has been
> >> >> proven secure using techniques and/or tools that are accessible
> to
> >> >> many reviewers?
> >> >>
> >> >>
> >> >> Useful topics in privacy
> >> >>
> >> >> address and/or IPv6 address are traceable, then cryptography is
> >> >> not going to get you strong anonymity, no matter what crypto you
> use.
> >> >> One topic that I didn't list above, because it is somewhat
> outside
> >> of
> >> >> CFRG's traditional scope, is security in Cloud environments.  To
> >> >> my thinking, the industry trend towards putting all the data one
> >> >> can
> >> get
> >> >> biggest threats to information security and privacy.   Maybe I
> trust
> >> the
> >> >> Cloud provider to be well intentioned, but can I actually trust
> >> >> them
> >> to
> >> >> maintain data security?    I didn't try to craft a topic along
> this
> >> line

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Mon, 6 Jan 2014 22:49:52 -0500

Next Gen PKI is of interest to me, and I'd be happy to contribute. I've published a paper in 2010, mentioning the directions I thought beneficial, and am working on a new revision. I think it would be directly applicable, and hopefully useful.

Caveat: if my current employer decides that for whatever reason I should not participate, they can stop me.

--
Regards,
Uri Blumenthal                            Voice: (781) 981-1638
Cyber Systems and Technology   Fax:   (781) 981-0186
MIT Lincoln Laboratory                Cell:  (339) 223-5363
244 Wood Street                        Email: <[email-masked]>
Lexington, MA  02420-9185       

Web:  http://www.ll.mit.edu/CST/

MIT LL Root CA: 

 <https://www.ll.mit.edu/labcertificateauthority.html>

DSN:   478-5980 ask Lincoln ext.1638

----- Original Message -----
From: Stephen Farrell [mailto:[email-masked]]
Sent: Tuesday, January 07, 2014 04:09 AM
To: Paul Lambert <[email-masked]>; David McGrew <[email-masked]>
Cc: Sean Turner <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Cfrg] considering new topics for CFRG

S.

---

From: Paul Lambert <[email-masked]>
Date: Tue, 7 Jan 2014 13:05:31 -0800

>nor a sufficient set of IETF participants who were interested
Yes - no visible results.
Note - I’m biased against even using the ‘I’ infrastructure terminology.
This was used to reflect the need for coordination required for CAs and
the original ideas of X.500

>not to start a new CT WG in the IETF at the moment.
Excellent work.  Currently a bandaid to X.509 PKI.  The Merkle tree
mechanism do have broader applicability but are just one mechanism that
could be part of a new framework.
A tree/log based approach is useful for validating the time sequence
relationship of events. It can help with making claims based on time
ordering (perhaps for names).

A useful mechanism, but it would be better to start with reexamining and
redefining our usage of public keys.  Specifically - I’m an advocate of
keys as the primary identifiers.  A ‘key centric’ approach is a dual model
to Kohnfelder/X.509   The SDSI/SPKI work did progress work in this
direction, but failed for a variety of reasons.

>security/crypto researcher though probably).
Old PKI … not a good venue.
>very much evolutionary and starts from X.509.
Yes. Wrong forum.
>topics if none of the above fit.
Yes - but not useable for sustained conversations.
>problem, 
Maybe ...

>and that any credible replacement will take at least
>one who chases funding;-).
Perhaps … but it depends on the market and application.
IPv6 … 20-30 years.
X.509 in TLS in browsers … 5-10 years
New applications … instantly

>One could argue that that's why
For fixing DNS names used in TLS

>is not likely to be a useful place to start.
Yes. It’s been done.

>We know those,
Please note that I was not suggesting that we replace
>     determine ³who can do what² (not based on X.509 or PGP)

This is a broader applications than just
a DNS name. New features would accelerate adoption in new markets.

Paul

>diving in, or ask someone who might be familiar, which
… You did not list SDSI/SPKI archives or PGP

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Wed, 8 Jan 2014 02:31:39 +0000

With the advent of DICE (DTLS in Constrained Environments), and similar attempts to discuss optimizations, it would seem that any discussion of "next generation" PKI discussions should include discussion on how to optimize the X.509 certificate/chain format. That appears to be missing in this conversation so far.

I agree that any replacement for our current PKI is going to run into the same complexities. So, rather than assume they don't exist, would it be reasonable to look at how to optimize the existing work? 

Some off the cuff examples to frame what I mean:
- Define a specific lightweight trust anchor format (yes, we can all use X.509 certs. But what about a canonical smaller format?) 
- Optimized version of the X.509 cert itself:
	Perhaps a compressed format similar to the (old, abandoned and incomplete)  http://tools.ietf.org/html/draft-pritikin-comp-x509-00 draft for compressed certs?
	Perhaps a v4 format that is restructured to provide easier/quicker parsing
	Or if a non-ASN1 format is truly preferred then such a format could be defined that is can carry the same semantics as the existing PKI (namely, if the problem is ASN1 then we can fix that without also re-inventing all the rest) 
	
Approaching the questions from this angle leads me to ask what _exactly_ the concerns with the current PKI are. Is it the ASN1, the CA infrastructure, the certificate chains, the cruft in each individual certificate, or? 

Thanks,

- max

---

From: Watson Ladd <[email-masked]>
Date: Tue, 7 Jan 2014 20:18:10 -0800

> I agree that any replacement for our current PKI is going to run into the same complexities. So, rather than assume they don't exist, would it be reasonable to look at how to optimize the existing…

For the PKI WG yes. For us no.

>From my perspective, it's a long and sad story about the semantics,
rather than the cruft.

First off, X.509 is as the name indicates part of a larger standard of
X.500 directory services, of which LDAP is a component.
LDAP was designed for hierarchical organizations: hence things like OU
etc. It works very well for this: the DOD uses it for access control
across a massive organization.

The problem is that this doesn't apply cleanly to the internet: PayPal
isn't part of Verisign in any meaningful sense, so why is Verisign
signing its certificate? (I just made this up: don't quibble) It gets
worse: with subdomains the idea of an intermediate certificate was
invented, but it took a while for the powers of the intermediate
certificate to be reined in with name restrictions.

The story gets worse when it comes to processing revocations. The DOD
has a CRL that is truly a wonder to behold, and OCSP doesn't work in
certain environments. The result is OCSP stapling, but it requires
cooperation from website admins, who I believe would refuse to pour
water on a burning man if it required a configuration change to a
webserver.

All of this annoyance and ugliness would be fine, if it wasn't for the
invisible hand. To the people paying for certs one CA is as good as
another, and the cheapest one wins. But that means extensive
verification and security measures aren't taken: commercial CAs will
meet the bare minimum to stay in the browser maker's good graces.
Anything more cuts into profits. Now, they aren't all like this, but a
lot of them are. End users have no idea what is really going on, and
can't make informed decisions. Heck, I don't know which CA's do a good
job and which don't.

Mix the three of these up, and we get things like Diginotar,
Turktrust, the recent flap over the French intermediate certificate
being stolen. Each one of these broke the security of the web for
everyone.

Lastly, X509 is good at expressing authenticity, bad at expressing
authority. It's not the only one with this problem: tracing who can
log in to what with SSH can be a real problem when transitivity is
noticed. Certificate transparency and pinning are ways around this,
but CT opposed by enough CAs to make it hard, and pinning requires
some work.

The net effect is Gmail has more security for me than Vanguard because
Gmail pins their certificate in Chrome, but Vanguard hasn't. Needless
to say this is very, very, subideal.  Furthermore, a huge number of
people can invisibly hijack any site they want.

None of this is that tied to what mistakes the standard groups made in
designing the mechanism, but rather the semantics they expressed
aren't a good fit for what we want. DANE is somewhat better, but won't
stop c1t1bank and related phishing fun.

Anyway, I think CFRG has very little role to play here. The issues are
mainly semantic, and there are several WGs addressing these issues.
Without a clear demand for our input I don't see why we need to spend
time on this.
Sincerely,
Watson Ladd

---

From: Sean Turner <[email-masked]>
Date: Tue, 7 Jan 2014 23:51:53 -0500

> With the advent of DICE (DTLS in Constrained Environments), and similar attempts to discuss optimizations, it would seem that any discussion of "next generation" PKI discussions should include disc…

Agreed but not sure the CFRG is the place to move the PKI' debates.

> - Define a specific lightweight trust anchor format (yes, we can all use X.509 certs. But what about a canonical smaller format?) 

There is the TAI in RFC 5914.

> 	Perhaps a v4 format that is restructured to provide easier/quicker parsing

This was exactly what I was planning on doing with my free time after March ;) I was hoping to get some folks together that want to run an experiment doing just this but with a twist.  Note I was specifically targeting experimental and folks who actually wanted to produce open source encoders and parsers - no interest in a compiler.

I was thinking we should ditch the X.509 baggage completely and not bother with “v4".  ITU-T is still defining extensions and additions to X.509 and I’d rather not get in the whole argument about a “v4" squatting on their numbers.  And, the changes I think we should propose are pretty radical and it wouldn’t like anything like v3.  Further, many protocols support an “other” certificate format including TLS, SMIME, and IKE so there’s really no need to stick with the X.509 baggage including the name - I’d not even call it a Certificate - call it an IKC (IRTF Key Container - while we’re experimenting).

My short list:

1. Define another Name choice or just don’t use Name :)  It could be the following purposely avoiding anything to do with SETs:

IRTFName ::= SEQUENCE OF AttributeTypeAndValue

AttributeTypeAndValue ::= SEQUENCE {
   type     AttributeType,
   value    AttributeValue }

Name ::= CHOICE { -- only one possibility for now --
     rdnSequence  RDNSequence }

Or we add a new Name Choice:

Name ::= CHOICE {
 rdnSequence RDNSequence, — never to be used in this new format
 internetName InternetName }

InternetName ::= SEQUENCE OF AttributeTypeAndValue

AttributeTypeAndValue ::= SEQUENCE {
   type     AttributeType,
   value    AttributeValue }

and prohibit the rdnSequence choice

2. Character Sets: The battle is over UTC8 won - we should just use it and use it everywhere therefore DirectoryString essentially becomes:

DirectoryString ::= UTF8String (SIZE (1..MAX))

You can profile it down or define a new structure I guess I’d go for new and a clean break.

3. Drop everything related to X.400.

4. Time - just use GeneralizedTime.

5. drop issuer & subject unique identifier

6. Some extension ranting:

AKI - does anybody actually use anything other than the keyIdentifier choice.  If the consensus is to use the keyIdentifier drop the other two field.

KU - drop NR :)

Simplify wherever possible.

> 	Or if a non-ASN1 format is truly preferred then such a format could be defined that is can carry the same semantics as the existing PKI (namely, if the problem is ASN1 then we can fix that without…

I hope to avoid the religious war because I think ASN.1 is just fine but *WOW* it could do with a good hair cut.  I was hoping we could do an ASN.1 profile for the IETF: iASN, ASN.l (l for light), or something like that and then do a quick survey of the RFCs we’ve defined and explicitly say they need not be supported.  A couple of things to experiment with:

1. Can we pick one rule with which to encode: KER (KISS Encoding Rules ;)

2. Could we get away with just primitive types for those that can now be either primitive or constructed?  E.g., do general purpose protocols need constructed bit/octet/character string encodings?

3. Can we do without indefinite length? 

4. Can we produce open source encoders/decoders to easy deployment?

5. Any reason we couldn't:

a. Use just two values for Boolean: 0x0 (false) and 0xff (true).

b. Can we do without: REAL, SET, SET OF, RELATIVE-OID, EMBEDDED PDV, EXTERNAL, CHARACTER STRING (Teletex, Videotext, Graphic, General, Universal, and finally BMP strings?), INSTANCE OF, and did I forget any?

6. Could we get away with just one tagging type (e.g., explicit so you might not have to guess so much)?

---

From: Sean Turner <[email-masked]>
Date: Wed, 8 Jan 2014 00:26:05 -0500

My list is kind of short:

0) Could the CFRG get behind these recommendations for RSA-OAEP/PSS or not:
http://www.ietf.org/mail-archive/web/saag/current/msg04481.html
http://www.ietf.org/mail-archive/web/saag/current/msg04482.html

If so, let’s do a draft!

1) Assuming RSA goes kaput, it seems like we’re moving towards EC (am I wrong here) then are these EC-based documents worth saying more about (e.g., in the next version of the protocol use this or run away in fear):
https://datatracker.ietf.org/doc/rfc6979/
https://datatracker.ietf.org/doc/draft-peck-ecdhpop/
https://datatracker.ietf.org/doc/draft-jivsov-ecc-compact/

2) Is QKD something we need to start considering:
http://tools.ietf.org/id/draft-nagayama-ipsecme-ipsec-with-qkd-00.txt
http://tools.ietf.org/id/draft-ghernaouti-sfaxi-ppp-qkd-00.txt

spt

---

From: Adam Back <[email-masked]>
Date: Wed, 8 Jan 2014 09:54:08 +0100

That is a good idea.  Without engaging in any hyperbole, most of the
complexity problems with actually coding TLS and the LoC of it come from the
cert format X509 including ASN.1 and X500 naming by reference.  TLS
specification itself is simple & clean, where it fails format complexity is
by abandoning that cleaness and referring to X509 which imports ASN.1 and
the multiple encoding, security risk of a complex compiled format language,
multiple encodings CER/DER/BER and X500 by reference.  Some of the X509
imported choices and level of flexibility in there are the antithesis of
KISS for a wire format and a security protocol.  (Complexity is the enemy of
security).

Even OpenPGP has a lot of bit-twiddling, such that if you try to implement
it, it becomes complex.  I found it took me 5x longer to match the format on
that after coding the obvious canonical TLS like format.  There is some
superfluous complexity & bit-twiddling in the OpenPGP format.

I would go further therefore and not try to work-around the ASN.1, X509,
X500 complexity with profile and special case parser hacks.

The best choice I argue would be make a simple format using TLS existing BNF
format that is extremely clean and simple, reboot the format from scratch
and do it the way it should have been done in a TLS BNF native format with
narrow focus on the job at hand to avoid even OpenPGP levels of mission
creep.

Adam

---

From: David McGrew <[email-masked]>
Date: Wed, 08 Jan 2014 06:06:51 -0500

Hi Sean,

> My list is kind of short:

thanks for sharing your top of mind list, it will help us to prioritize 
work.

> http://tools.ietf.org/id/draft-ghernaouti-sfaxi-ppp-qkd-00.txt

#0 and #1 are well worth discussion.   For now, I will only comment on #2.

Quantum Key Distribution does not provide a solution to any problem that 
we have at hand, and is not worthy of serious consideration for 
extensive use in the Internet.

The one benefit of QKD is that it does not rely on any computational 
assumptions for security.   However, it relies on physical assumptions 
for its security; that is, it can be attacked at the physical layer.   
This is a terrible tradeoff, since physical attacks are possible at any 
point between the encrypter and decrypter.   In addition, QKD requires 
large amounts of raw entropy, and entropy generation is a harder problem 
in the real world than pseudorandomnes.   (In other words: a QKD system 
could use AES-CTR to generate the large amounts of unpredictable 
elements that it needs, but if we trust AES-CTR, why not just use that 
algorithm directly to encrypt traffic?)

QKD relies on point-to-point secret keys, and it is inherently and very 
severely limited in what data rates and ranges that it can support.   
The claimed speed record the last time that I checked was one megabit 
per second at 20 KM range.   Using that technology, we need 10,000 
repeaters to get global scale communication.   This would require the 
pre-placement to 9,999 shared secrets between pairs of repeaters along 
the communication path, and it would require that infrastructure to be 
trusted.  There are theoretical designs for repeaters that would not 
need to be trusted,

The idea of "hybrid QKD", in which QKD is used to distribute keys for a 
conventional symmetric cryptosystem like AES, is a seriously bad idea.  
It suffers from the physical layer vulnerabilities of QKD as well as 
whatever vulnerabilities the symmetric cryptosystem has.   It is *more* 
vulnerable than a conventional symmetric system that uses the same 
cipher for both traffic encryption and key distribution.

QKD relies on the point to point transmission of individual photons, and 
thus is inherently incompatible with wireless technologies such as 4G 
and 802.11.   The photons used in WiFi have 100,000 times less energy 
than those used in the fibre optic links of QKD, and WiFi is not 
geometrically point to point.   So even if QKD didn't suffer from the 
problems described above, it would not be able to help the > 6 billion 
cellular wireless subscribers, or the vast number of WiFi users.

QKD is inherently unsuited for all of the important trends in 
information technology, including the "bring your own device" trend, 
Could, virtualization, and collaboration.

I gave an invited talk at the 2012 HP Information Security Colloquium 
Royal Holloway with the title "The Vernam cipher is better than quantum 
key distribution", which presented an analysis that backs up the claim 
in the title.   The important observation here is that the classical 
Vernam cipher, in which a long one-time pad is copied onto a portable 
storage medium then used for information-theoretically secure 
communication, is quantifiably better than QKD.   Vernam does not have 
any physical-layer vulnerabilities, it does not have any range 
limitations, and it can be used over wireless.   Its data rate will 
depend on how frequently new pad material can be transported by a 
trusted physical courier, but given the low data rates of QKD, a courier 
need not travel that often to match its data rate.   The important 
inference is: if we were actually concerned about the possibility that 
all symmetric ciphers could be vulnerable to cryptanalysis, then we 
would be pursuing Vernam-type information theoretic secure systems, and 
not QKD.   The reality is that there is no such concern, and interest in 
QKD is driven by its novelty, and not by any logical consideration of 
what would be useful in information security.

My talk isn't online (just mentioned but not archived 
http://bristolcrypto.blogspot.com/2012_12_01_archive.html)   If we need 
to get these points understood more widely, we could publish something 
on it.

David

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 08 Jan 2014 11:09:45 +0000

Hi Max,

On 01/08/2014 02:31 AM, Max Pritikin (pritikin) wrote:
> 
> With the advent of DICE (DTLS in Constrained Environments), and
> similar attempts to discuss optimizations, it would seem that any
> discussion of "next generation" PKI discussions should include
> discussion on how to optimize the X.509 certificate/chain format.
> That appears to be missing in this conversation so far.

True. OTOH, DICE is definitely predicated on DTLS so any
discussion on cert formats for that would fit into the TLS
WG discussion on 1.3. I've not however seen that listed on
any 1.3 wish-list so far so it seems unlikely to me at
least that DICE will push things along here.

> I agree that any replacement for our current PKI is going to run into
> the same complexities. So, rather than assume they don't exist, would
> it be reasonable to look at how to optimize the existing work?

I'm not sure. I think that might run the risk of inheriting
all the warts (e.g. policy mapping, the N-R bit) without
providing much incentive to change. When we were working on
RFC3280bis (which became 5280) we did try to do as much of
that as we could, but very few simplifications turned out
to be possible. It is fair to say though that a lot of the
real practical problems had not really bitten folks at
that stage though, so I guess its possible that the same
exercise done now might pay off.

> Some off the cuff examples to frame what I mean: - Define a specific
> lightweight trust anchor format (yes, we can all use X.509 certs. But
> what about a canonical smaller format?) - Optimized version of the
> X.509 cert itself: Perhaps a compressed format similar to the (old,
> abandoned and incomplete)
> http://tools.ietf.org/html/draft-pritikin-comp-x509-00 draft for
> compressed certs? Perhaps a v4 format that is restructured to provide
> easier/quicker parsing Or if a non-ASN1 format is truly preferred
> then such a format could be defined that is can carry the same
> semantics as the existing PKI (namely, if the problem is ASN1 then we
> can fix that without also re-inventing all the rest)  Approaching the
> questions from this angle leads me to ask what _exactly_ the concerns
> with the current PKI are. Is it the ASN1, the CA infrastructure, the
> certificate chains, the cruft in each individual certificate, or?

Personally, I think the main problems with X.509 PKI to date
have been around (the need for, and absence of widely supported
standard for) enrollment and (particularly name) constraints
when there are many CAs. Dealing with ASN.1 is a PITA, but a
well-known one, so that'd be low down on my list anyway. I
know you've spent a lot of effort trying to help with the
enrollment problem with EST and I do hope that works out,
but we don't know yet.

Again though, I don't think thrashing out the pros and cons
of X.509 on this list is a good plan. Better would be for a
bunch of really-interested parties to go into a huddle and
come up with a worked out proposal. (But if a bunch of
semi-interested parties ask for a new list to talk about
this, I've no problem helping that happen, though wouldn't
be very hopeful of a useful outcome.)

S.

>>>>> This is an intriguing thought, but probably something out of
>>>>> scope for CFRG.   (Seems more like a PKNG thing if I
>>>>> understand you right.)
>>> 
>> That was an IRTF RG. IMO it never had a cadre of researchers nor a
>> sufficient set of IETF participants who were interested in a
>> nextgen thing.
>> 
>>> This is an area where the IETF seems either too unfocused or
>>> mired in existing PKI to make progress.  Hence it's on my wish
>>> list ... Let me know if you have any suggestion for other viable
>>> forums in IETF for such a topic.
>> 
>> which has a broader remit. [1] That's discussing whether or not to
>> start a new CT WG in the IETF at the moment.
>> 
>> There's the wpkops WG for operational issues related to the web
>> PKI. [2] They could do with help in terms of cycles to do 
>> The PKIX list [3] is still open, and would be a good place to talk
>> about any X.509-related PKI stuff. Not so good for non X.509 based
>> PKI though maybe unless for an approach that's very much
>> evolutionary and starts from X.509.
>> 
>> And there's the saag list [4] which is for general security topics
>> if none of the above fit.
>> 
>> So stuff is happening and there are places to discuss and propose
>> stuff. And Sean and I would be quite happy to try help PKI nextgen
>> stuff progress in the IETF should there be credible proposals.
>> 
>> However, current PKI is not an easy thing to displace, no matter
>> how much you dislike parts or all of it. The main reasons IMO are
>> that replacements are likely to suffer a lot of the same (or
>> equivalent) complexity since its a complex problem, and that any
>> credible replacement will take at least a few years to work out and
>> them 5-10 to get deployed which seems to be beyond the horizon for
>> researchers (speaking as one who chases funding;-). One could argue
>> that that's why of all the "large DB of public keys" approaches,
>> only CT seems to be left standing.
>> 
>> One other thing - listing the problems with the current PKI is not
>> likely to be a useful place to start. We know those, and any
>> credible approach would start with a fairly well worked out
>> proposal, including consideration of that 5-10 year overlap period.
>> Its not easy;-)
>> 
>> Having said all that though, CT is I think a good proof of concept
>> that the large-DB-of-public-keys thing could be a runner, and we
>> have learned a lot about the wrinkles in X.509 based PKI over the
>> years so there is hope maybe.
>> 
>> S.
>> 
>> PS: For any of [1]-[4] please check the archives before diving in,
>> or ask someone who might be familiar, which could include me.
>> 
>> [1] https://www.ietf.org/mailman/listinfo/therightkey [2]
>> http://tools.ietf.org/wg/wpkops/ [3]
>> https://www.ietf.org/mailman/listinfo/pkix [4]
>> https://www.ietf.org/mailman/listinfo/saag
>> 
>> 
>> 
>> _______________________________________________ Cfrg mailing list 
>> [email-masked] http://www.irtf.org/mailman/listinfo/cfrg
>

---

From: "Paterson, Kenny" <[email-masked]>
Date: Wed, 8 Jan 2014 12:20:50 +0000

On 08/01/2014 12:06, "David McGrew" <[email-masked]> wrote:

>> If so, let¹s do a draft!
>> 1) Assuming RSA goes kaput, it seems like we¹re moving towards EC (am I
>>wrong here) then are these EC-based documents worth saying more about
>>(e.g., in the next version of the protocol use this or run away in fear):

<excellent explanation of the shortcomings of QKD excised>

>to get these points understood more widely, we could publish something

Thanks for the reminder about this talk, which I very much enjoyed at the
time.

A few years back, we wrote a paper [1] explaining why we believed that QKD
is not commercially interesting. Some of the points are orthogonal to
yours, some overlap.

[1] Quantum cryptography: a practical information security perspective.
Kenneth G. Paterson, Fred Piper, Ruediger Schack
http://arxiv.org/abs/quant-ph/0406147

Cheers

Kenny

---

From: Sean Turner <[email-masked]>
Date: Wed, 8 Jan 2014 10:27:18 -0500

> http://arxiv.org/abs/quant-ph/0406147

I love instant gratification! 

spt

---

From: Sean Turner <[email-masked]>
Date: Wed, 8 Jan 2014 10:29:34 -0500

> be very hopeful of a useful outcome.)

I’m keeping  list now :)

spt

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Wed, 8 Jan 2014 16:29:52 +0000

re: X509 PKI update discussion

We can (and probably will) quibble about the details in an other forum than CFRG. I'll watch for the conversation and am pleased to know Sean is keeping a list. 

On Jan 8, 2014, at 8:29 AM, Sean Turner <[email-masked]>
 wrote:

>> of X.509 on this list is a good plan.

Fair enough, the conversation steered that way but I'm happy to move to an alternate location.

The discussion started here is a good one. With DICE requiring DTLS and w TLS 1.3 ongoing the timing might be right.  

>> Better would be for a

I'm tentatively in agreement with much of the discussion so far. Particularly regarding the various and multiple principle name issues.

I'd like to add though that "PKI" includes more than just the "global internet" use case that has been much discussed. A valid use case we also need to consider involves enterprise specific key infrastructures.

I'll watch for the continued conversation elsewhere. Cheers,

- max

---

From: Dan Brown <[email-masked]>
Date: Wed, 8 Jan 2014 17:32:29 +0000

> From: Sean Turner
> Sent: Wednesday, January 08, 2014 12:26 AM
> 

Maybe CFRG should compare RSA-KEM to RSA-OAEP?  

Is there a signature analogue to RSA-KEM?

KEM is ISO 18033-2, but not in PKCS#1 (last I checked, which was long ago).

RSA-KEM looks cleaner and simpler, at least to me, though is perhaps less
efficient?

Since some in CFRG are interested in provable security, how do these two
compare on that front?  Especially, in the standard model?  A while back
several people (including) me found some theoretical impossibility results
against security proofs about RSA-OAEP and RSA-PSS in the standard model,
but since then I have mostly forgotten about that topic. These results
mostly concerned IND-CCA2 security.  I forget if these results apply to
RSA-KEM.  I vaguely recall some positive research results.

> 
> 1) Assuming RSA goes kaput, it seems like we're moving towards EC (am I
wrong
> here) then are these EC-based documents worth saying more about (e.g., in
the
> next version of the protocol use this or run away in fear):

Seems good.  In my own security analyses, one of the security arguments for
ECDSA needed the ephemeral keys to be message-constant to make the ROM work.
Maybe that was just a deficiency in my proof techniques.   I haven't
reviewed the specific algorithm in 6979, but I would be inclined to give a
slight edge to deterministic algs for ECDSA ephemeral keys.

> https://datatracker.ietf.org/doc/draft-peck-ecdhpop/

Seems good.  I had no idea the existing IETF POP excluded using ECDSA
signatures for ECDH keys. 

> https://datatracker.ietf.org/doc/draft-jivsov-ecc-compact/

I don't see a security problem.  Indeed, SEC1 permits similar filtering in
the key generation algorithm to facilitate accelerated verification of ECDSA
signatures.

The SEC1 encoding is really meant to be inserted wherever a definite octet
string is needed, mainly in ASN.1.  I believe the header byte was meant to
serve a dual tag-length role (that provided what was missing from the curve
id).  Maybe this I-D could propose something more specific to ASN.1.

I wonder if this compact representation might conflict with other proposals,
in that it becomes an untagged integer. 

> http://tools.ietf.org/id/draft-ghernaouti-sfaxi-ppp-qkd-00.txt

I am more interested in the issue of whether quantum computing (for Shor's
algorithm) will, or even has, become feasible? I am not an expert in the
area, but am interested.

Of course, we can just go ahead and get prepared with proposals for
postquantum algs.  That's great to do, but still doesn't address the
question. I expect some may argue that asking this whole question just begs
pointless speculation, on the grounds that if your adversary (soon) has a
QC, then you should have spent your time switching to PQ rather than
thinking about whether the adversary had a QC.  In other words, I'm
expecting some may say that consideration of postquantum crypto is perfectly
reasonable, but asking about the existence of a quantum computer is
pointless.  

But I think it is okay for CFRG to consider it, and, nay, even try to boldly
quantify these, say with likelihood 2^(-64) of some well-defined claim,
calculated via a series of estimates.  The status quo is to just claim that
algorithm X with key size provides 128 bit security, whatever that means,
perhaps adding the exclusion against quantum computers.  Adding an estimated
likelihood of a quantum computer gives a more meaning of what kind of
security is being claimed.  Maybe the postquantum researchers already have
made such an estimate, as part of an effort to justify a switch to
postquantum.  

I would understand if the CFRG chairs deem this out of scope for CFRG.  If
so, I hope that somebody could suggest to me off-list an alternative forum.

An informal, perhaps dubious, argument that comes to my mind is the
following.  The most likely party to have a quantum computer is a large
nation.  If they had such a thing, then they could break almost all IETF
crypto, except pre-shared key based stuff, and wouldn't have to resort to
any other chicanery.  But reports are now suggesting the latter.  Well, the
chicanery could all be just a cover-up ruse.  Or more realistically, maybe
the quantum computer is kept on reserve, and more mundane cryptanalysis is
used on a daily basis, maybe because it is cheaper.  Still, why not just lay
little lower, if a QC is available? Anyway, the loose inference I'm drawing
is that a quantum computer does not yet exist, and further that the most
likely parties to have one do not anticipate being able to have one in the
near future.  Well, this argument does not give any kind of quantified
likelihood. If I had to dead-reckon a likelihood, I'd make a wildly
different number every time, but most of them would be above 2^(-128),
unfortunately.  

I wonder if others have more substantial arguments. 

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Paul Lambert <[email-masked]>
Date: Wed, 8 Jan 2014 09:38:21 -0800

>> it be reasonable to look at how to optimize the existing work?

I think it could be much simpler.  If you start with just
keys and key hashes as identity, then you do not need CAs
or other naming authorities.

Of course Š as you then assign attributes to keys (that might include
names) and support delegation complexity arises, but you still
maintain a simple model for simple devices.

Note - assigning 'names to key¹s versus 'keys to names' are
two very different architectures.  It is not easy
to tweak 509 to be key centric.

So .. This thread may imply to different paths of work.

On CFRG work.

A key centric architecture would benefit from CFRG
recommendations for:
 1) recommendations for ³suitable" EC curves
   and associated methods
   (e.g. Brainpool or Ed25519)
 2 recommendations for how to use the same public
   key for signatures and key establishment
   (current architectures are complicated by this split)
 3) a canonical definition of public key representation
    for identification (e.g. Key hash) that provides
   - indépendance of representation to underlying
     Public key or hashing algorithms
   - considerations and options
     for human and machine readability and reliability
   - mutability of ID to support anonymity of visible
     Id binding to key
   - extensibility of cipher suites
   - optional opacity of cipher suite support
   - variable length of identification to support
     short forms that might be ambiguous when not viewed in context

Hummm Š maybe only the first two are CFRG items.

>> abandoned and incomplete)

There are completely different trust anchor models from X.509 and we
Should work to make a better distributed model for name spaces and
Trust delegation. Improvements are required in the:
 - semantics of the signatures, attributes and delegation
 - clear definition of useable constraints for extensible attributes
 - redefinition of name spaces to be anchored by keys
 - etc.

>be very hopeful of a useful outcome.)

Let me know Š I am interested and have some ideas on directions and
perhaps some code.

Paul

---

From: "Igoe, Kevin M." <[email-masked]>
Date: Wed, 8 Jan 2014 18:06:37 +0000

We really need to make sure at least some of the mailing list
has some expertise in a given area before we commit ourselves
to working in that area, and anything with "quantum" in the name
requires expertise I expect very few (if any) of the maining list
possess.  I suggest before committing to a topic we poll the
mailing list to see who has both expertise on a given topic and 
an employer who is willing to donate the time and resources 
needed to follow through.

> Sent: Wednesday, January 08, 2014 6:07 AM
> To: Sean Turner
> Cc: Igoe, Kevin M.; [email-masked]
> Subject: QKD is pointless (was: Re: considering new topics for CFRG)
> 
> Hi Sean,
> 
> > If so, let's do a draft!
> > 1) Assuming RSA goes kaput, it seems like we're moving towards EC (am
> I wrong here) then are these EC-based documents worth saying more about
> Quantum Key Distribution does not provide a solution to any problem
> that we have at hand, and is not worthy of serious consideration for
> QKD relies on the point to point transmission of individual photons,
> and thus is inherently incompatible with wireless technologies such as
> 4G

---

From: "Igoe, Kevin M." <[email-masked]>
Date: Wed, 8 Jan 2014 18:15:29 +0000

I'd like to see the CFRG investigate how far the DANE paradigm
can be pushed w/o bringing the system to a screeching halt.
For example, there is a group an NIST looking at the possibility
of leveraging DANE for use with e-mail.  Who else is out there 
hoping to piggy bank on DANE?  Can DANE be the new PKI?  If not,
what features does it lack & can it be "patched"?

---

From: Watson Ladd <[email-masked]>
Date: Wed, 8 Jan 2014 10:18:32 -0800

> needed to follow through.

My job is simple: do math. Granted, there is some other math/coding I
should be doing at the moment,
but I certainly can devote resources to this.
What does Post-Quantum Crypto require beyond some coding theory for
McEliece-Nedermeyer and some
algebraic geometry for Multivariate-Quadratic systems?

QKD is a different kettle of fish.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 8 Jan 2014 11:21:43 -0800

On Jan 8, 2014, at 10:15 AM, Igoe, Kevin M. <[email-masked]> wrote:

> of leveraging DANE for use with e-mail.

You mean like with draft-ietf-dane-smime and draft-ietf-dane-smtp-with-dane, both of which are already being discussed in the DANE WG? :-)

>  Who else is out there 
> hoping to piggy bank on DANE?  

And shouldn't those people tell the DANE folks about it?

> Can DANE be the new PKI?  If not,

The discussion of "could DANE or something like it be a new PKI" could happen here, but folks wanting to do so should read the archives of the DANE WG.

Any communications medium that has cryptographic protection and proof of origin can be a new PKI, or it can be part of the delivery for the old PKI. Keys-over-DNS is nothing new, as is keys-over-TLS, keys-over-IPsec, keys-over-CMS, and so on.

--Paul Hoffman

---

From: Paul Lambert <[email-masked]>
Date: Wed, 8 Jan 2014 17:09:42 -0800

> > >> >     to both sign data and be used to develop encryption keys

Here are the NIST guidelines that generated my wish:
   http://csrc.nist.gov/groups/ST/toolkit/documents/SP800-56Arev1_3-8-07.pdf

"A static key pair may be used in more than
one key establishment scheme. However, one
static public/private key pair shall not
be used for different purposes (for example, a
digital signature key pair is not to be used
for key establishment or vice versa) with the
following possible exception: when requesting
the (initial) certificate for a public static
key establishment key, the key establishment 
private key associated with the public key
may be used to sign the certificate request
. See SP 800-57, Part 1 on Key Usage for further information"

This immediately divides any PK architecture in half with
separate signature and key establishment PKs.

It's odd that the guidelines allow the key 
establishment key to sign once, but not after the
certificate request.

Questions for the group:
1) Are there any demonstrable attacks on the 
combined usage of key establishment and signature algorithms?

2) What are the known safe combinations?
(I've seen at least one Edwards curve paper on combined usage)

Paul

---

From: Paul Lambert <[email-masked]>
Date: Wed, 8 Jan 2014 17:55:55 -0800

> From: Cfrg [mailto:[email-masked]] On Behalf Of Igoe, Kevin M.
> Sent: Wednesday, January 08, 2014 10:15 AM
> To: 'David McGrew'; Sean Turner
> Cc: [email-masked]
> Subject: Re: [Cfrg] QKD is pointless (was: Re: considering new topics
> for CFRG)
> 
> I'd like to see the CFRG investigate how far the DANE paradigm can be
> pushed w/o bringing the system to a screeching halt.
> For example, there is a group an NIST looking at the possibility of
> leveraging DANE for use with e-mail.  Who else is out there hoping to
> piggy bank on DANE?  Can DANE be the new PKI?  
No. 

Nice hack, but lacking adequate semantics and constraint based
architecture to extend well beyond DNS based naming (email could work).

>If not, what features
> does it lack & can it be "patched"?
Anything could be patched ... but the core hierarchy structure
of DNS would be maintained and would always be of that flavor 
of that solution space. 

I'd like to see something that would work for mobile phones without
central servers ...

Paul

> > #0 and #1 are well worth discussion.   For now, I will only comment
> on
> > #2.
> >

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 9 Jan 2014 09:46:44 -0800

>> piggy bank on DANE?  Can DANE be the new PKI?  

Actually, yes it can, if you change your assumptions about what you want "the PKI" to be. The current "the PKI" assumes many things about how many trust anchors there should be and what names each of those trust anchors can vouch for. DANE, as a new "the PKI" makes different assumptions. There are operational advantages to each choice.

> architecture to extend well beyond DNS based naming (email could work).

Right: that's exactly the point of DANE. The semantics are purposely limited to the naming scheme people care most about on the Internet. What other names do you think are important for a new "the PKI" that can't be associated with the DNS?

> of DNS would be maintained and would always be of that flavor 

Quite right. That's considered a feature by many.

> I'd like to see something that would work for mobile phones without

Please say more. Are you assuming a mobile phone not connected to the Internet?

--Paul Hoffman

---

From: David McGrew <[email-masked]>
Date: Thu, 09 Jan 2014 19:02:24 -0500

Hi Kevin,

On 01/08/2014 01:06 PM, Igoe, Kevin M. wrote:
> to working in that area,

I completely agree, the RG needs to be cautious about making sure that 
it does not overcommit to work.

> and anything with "quantum" in the name

>> to get these points understood more widely, we could publish something

Instead of the last sentence, what I should have said is: if there is a 
need to better explain and/or defend the points outlined above, I 
personally would be willing to spend the time to write them up.

Speaking as an individual here: I don't think QKD is something worth the 
RG's time.   Post-quantum crypto, on the other hand, is something I 
would be very glad to see work on.

David

---

From: "Hilarie Orman" <[email-masked]>
Date: Thu, 9 Jan 2014 19:16:46 -0700

QKD married to Internet encryption protocols has been demonstrated, and
the physics is in flux (PI).  You may well see regional, multihop QKD
networks in the near future, as well as satellite communication secured
with it.  It seems a valid topic for the CFRG.

Hilarie

---

From: [email-masked]
Date: Fri, 10 Jan 2014 12:10:00 -0500

> redefining our usage of public keys.  Specifically - I'm an advocate of
 > keys as the primary identifiers.  A "key centric" approach is a dual model

Key-centric versus name-centric identity is The Question, is it not?

I rather doubt that the Administration's push for the NSTIC is
likely to settle in on key-centricity, but might you elaborate
on your preference for it?  I'm sympathetic to it on the grounds
that it directly enables multi-personna and, thus, data segmentation.

If I'm being obtuse, feel free to say so.

--dan

---

From: David McGrew <[email-masked]>
Date: Sun, 12 Jan 2014 08:39:28 -0500

Hi Dan,

some further thoughts on things quantum:

> algorithm) will, or even has, become feasible? I am not an expert in the

this is not an area that I actively follow, but I think the following 
description is accurate: quantum computing is an active area of 
research, and those working in the area believe that it can become a 
viable technology in the not-to-distant future, though there are also 
skeptics who feel that quantum decoherence may make it impossible to 
ever build a quantum computer that would be able to solve problems of 
cryptographic interest.   (An important side note: the D-Wave computer 
is not a real quantum computer in the Peter Shor sense; it does 
something more like simulated annealing).

> reasonable, but asking about the existence of a quantum computer is

This is my thinking, more or less.   I would put it more positively as: 
let's figure out how to use post-quantum cryptography in practice, 
because if there is a breakthrough in quantum computing, the mad rush 
will be ugly, and besides, we don't really know what capabilities our 
adversaries have now, or will have in a decade.

> made such an estimate, as part of an effort to justify a switch to

I don't think it would be fruitful to attempt to estimate the 
probability that a quantum computer can be built.   If someone did try 
to make such an estimate, it would make interesting reading, but I doubt 
that I would trust it, because the likelihood of new scientific advances 
cannot reliably be estimated.   The scenario here recalls that of the 
prominent physicists in the 1920s and 1930s who scorned H.G. Wells' 
predictions about nuclear power.  It is unlikely that those physicists 
would have done a better job with their prognostications if they had 
attempted to use a formal model for Bayesian inference, or some other 
framework for computing an exact probability.   (The model would just 
mathematically formalize their beliefs, which turned out to be wrong.)

As an aside, if it were possible to come up with accurate estimates for 
the likelihood of scientific advances, it would be reasonable to apply 
that methodology to other cryptographic questions.   By way of example, 
one could ask: are we more likely to see advances in the cryptanalysis 
of lattice-based cryptography, or code-based cryptography?    It is 
interesting to think about, but it does not seem like we should expect 
this sort of analysis to provide us with much concrete guidance on 
future standards.

Lenstra did consider the possibility of progress in cryptanalytic 
capabilities in his very thorough study of key lengths, and he noted 
that one must model advances for different cryptosystems differently.   
But he does not attempt anything as detailed as a probability estimate 
for a quantum computer; he says that "a clearly discernable and 
well-established past pattern in practical cryptanalytic progress is no 
guarantee that the future pattern will be the same or that there will 
not be any surprising breakthroughs with immediate practical 
consequences."   (The quote is from the handbook contribution online at 
http://www.keylength.com/biblio/Handbook_of_Information_Security_-_Keylength.pdf)

> nation.

Agreed.

> If they had such a thing, then they could break almost all IETF
> near future.

I agree with some of the logic, but not the conclusion, because 
intelligence agencies for large nations are likely to pursue all avenues 
that are available to them.   To continue the nuclear analogy from 
above, the vast arsenal of conventional bombs that the U.S. built in 
1944 should not have been taken as evidence that there was not an active 
and successful effort to build a nuclear weapon that was proceeding 
concurrently.

Thanks for the interesting discussion!

David

> Well, this argument does not give any kind of quantified

---

From: David Jacobson <[email-masked]>
Date: Sun, 12 Jan 2014 07:38:35 -0800

On 1/12/14 5:39 AM, David McGrew wrote:
> This is my thinking, more or less.   I would put it more positively 
> as: let's figure out how to use post-quantum cryptography in practice, 

[snip]

This is a volunteer group, and the energy that can be summoned depends 
on interest, excitement, fear, etc.  (Just note how CFRG has gone from a 
sleepy group with 2 or 3 messages per month to many messages a day since 
last summer.)  So, if we want to study post quantum computing, find 
promising algorithms, and evaluate them, we can do that if we have a 
sufficient set people with interest and expertise.  And I think we do.  
It is not like we are at a big company and we have to get some executive 
to give us a budget.

    --David Jacobson

---

From: William Whyte <[email-masked]>
Date: Sun, 12 Jan 2014 23:16:35 -0500

Hi all,

Sorry again for top-posting, that's gmail for you.

> I would put it more positively as: let's figure out how to use
post-quantum cryptography in practice, because if there is a breakthrough
in quantum computing, the mad rush will be ugly.

As I mentioned in a previous mail, I think the best way to do this is to
figure out how to avoid depending on a single public key algorithm in any
context, because all public key algorithms are potentially vulnerable to
technological and algorithmic breakthroughs. So combining public key
algorithms seems like a prudent approach. I know there are Certicom patents
on this but it seems that this shouldn't be insuperable.

> I don't think it would be fruitful to attempt to estimate the probability
that a quantum computer can be built.   If someone did try to make such an
estimate, it would make interesting reading, but I doubt that I would trust
it, because the likelihood of new scientific advances cannot reliably be
estimated.

I would say the question isn't so much "can a quantum computer be built?"
as "what size quantum computer can be built?" There's an interesting 2011
blog post on that subject that tries to derive a Moore's law for quantum
computer size:
http://www.quantenblog.net/physics/moores-law-quantum-computer. I don't
know how well reviewed this has been, but it's a start: key lines are "The
blue line is a fit to the data, indicating a doubling of the number of
qubits every 5.7±0.4 years." and "If you are bold enough to believe that
the same scaling continues even further, 2048-bit RSA keys would come under
attack somewhere between 2052 and 2059."

Cheers,

William

On Sun, Jan 12, 2014 at 8:39 AM, David McGrew <[email-masked]> wrote:

>  2) Is QKD something we need to start considering:http://tools.ietf.org/id/draft-nagayama-ipsecme-ipsec-with-qkd-00.txthttp://tools.ietf.org/id/draft-ghernaouti-sfaxi-ppp-qkd-00.txt
>
> description is accurate: quantum computing is an active area of research,
> and those working in the area believe that it can become a viable
> technology in the not-to-distant future, though there are also skeptics who
> feel that quantum decoherence may make it impossible to ever build a
> quantum computer that would be able to solve problems of cryptographic
> interest.   (An important side note: the D-Wave computer is not a real
> quantum computer in the Peter Shor sense; it does something more like
> simulated annealing).
>
> let's figure out how to use post-quantum cryptography in practice, because
> if there is a breakthrough in quantum computing, the mad rush will be ugly,
> and besides, we don't really know what capabilities our adversaries have
> now, or will have in a decade.
>
> I don't think it would be fruitful to attempt to estimate the probability
> that a quantum computer can be built.   If someone did try to make such an
> estimate, it would make interesting reading, but I doubt that I would trust
> it, because the likelihood of new scientific advances cannot reliably be
> estimated.   The scenario here recalls that of the prominent physicists in
> the 1920s and 1930s who scorned H.G. Wells' predictions about nuclear
> power.  It is unlikely that those physicists would have done a better job
> with their prognostications if they had attempted to use a formal model for
> Bayesian inference, or some other framework for computing an exact
> probability.   (The model would just mathematically formalize their
> beliefs, which turned out to be wrong.)
>
> the likelihood of scientific advances, it would be reasonable to apply that
> methodology to other cryptographic questions.   By way of example, one
> could ask: are we more likely to see advances in the cryptanalysis of
> lattice-based cryptography, or code-based cryptography?    It is
> interesting to think about, but it does not seem like we should expect this
> sort of analysis to provide us with much concrete guidance on future
> standards.
>
> capabilities in his very thorough study of key lengths, and he noted that
> one must model advances for different cryptosystems differently.   But he
> does not attempt anything as detailed as a probability estimate for a
> quantum computer; he says that "a clearly discernable and well-established
> past pattern in practical cryptanalytic progress is no guarantee that the
> future pattern will be the same or that there will not be any surprising
> breakthroughs with immediate practical consequences."   (The quote is from
> the handbook contribution online at
> that are available to them.   To continue the nuclear analogy from above,
> the vast arsenal of conventional bombs that the U.S. built in 1944 should
> not have been taken as evidence that there was not an active and successful
> effort to build a nuclear weapon that was proceeding concurrently.
>

---

From: Watson Ladd <[email-masked]>
Date: Sun, 12 Jan 2014 20:49:33 -0800

On Sun, Jan 12, 2014 at 8:16 PM, William Whyte
<[email-masked]> wrote:
>> post-quantum cryptography in practice, because if there is a breakthrough in
>> quantum computing, the mad rush will be ugly.
>

But that depends on at least one algorithm being postquantum secure,
and historically
we've not had any real surprises in the public key world.
Algorithms exist that do this, we just need to be ahead of the game in
specifying them. I'll see if McBits is amenable to standardization. Worst
case we wait for NTRU patents to expire, and adopt it. Yeah, we lose some
nice stuff in the post-quantum world, but most IETF protocols will survive
no problem. Signatures are a bit nasty in the present state of knowledge,
and there is protocol review work to do. Key sizes get massively bigger:
a lot of hardcoded limits will have to be revised.

However, McBits is slightly faster than existing techniques including ECC,
so the big issue is really size, not speed.

> I would say the question isn't so much "can a quantum computer be built?" as
> "what size quantum computer can be built?" There's an interesting 2011 blog
> post on that subject that tries to derive a Moore's law for quantum computer
> size: http://www.quantenblog.net/physics/moores-law-quantum-computer. I
> don't know how well reviewed this has been, but it's a start: key lines are
> "The blue line is a fit to the data, indicating a doubling of the number of
> qubits every 5.7±0.4 years." and "If you are bold enough to believe that the
> same scaling continues even further, 2048-bit RSA keys would come under

That's a serious underestimate because it ignores the possibility of a
breakthrough
in making qubits. Once you get a method that scales up, it is likely
to be a large jump
rather than incremental increase.

>> and those working in the area believe that it can become a viable technology
>> in the not-to-distant future, though there are also skeptics who feel that
>> quantum decoherence may make it impossible to ever build a quantum computer
>> that would be able to solve problems of cryptographic interest.   (An
>> important side note: the D-Wave computer is not a real quantum computer in
>> the Peter Shor sense; it does something more like simulated annealing).
>>
>> the 1920s and 1930s who scorned H.G. Wells' predictions about nuclear power.
>> It is unlikely that those physicists would have done a better job with their
>> prognostications if they had attempted to use a formal model for Bayesian
>> inference, or some other framework for computing an exact probability.
>> (The model would just mathematically formalize their beliefs, which turned
>> out to be wrong.)
>>
>> methodology to other cryptographic questions.   By way of example, one could
>> ask: are we more likely to see advances in the cryptanalysis of
>> lattice-based cryptography, or code-based cryptography?    It is interesting
>> to think about, but it does not seem like we should expect this sort of
>> analysis to provide us with much concrete guidance on future standards.
>>
>> This transmission (including any attachments) may contain confidential
>> information, privileged material (including material protected by the
>> solicitor-client or other applicable privileges), or constitute non-public
>> information. Any use of this information by anyone other than the intended
>> recipient is prohibited. If you have received this transmission in error,
>> please immediately reply to the sender and delete this information from your
>> system. Use, dissemination, distribution, or reproduction of this
>> transmission by unintended recipients is not authorized and may be unlawful.
>>
>>
>>

---

From: Yoav Nir <[email-masked]>
Date: Mon, 13 Jan 2014 06:23:17 +0000

On Jan 13, 2014, at 6:49 AM, Watson Ladd <[email-masked]>
 wrote:

> case we wait for NTRU patents to expire, and adopt it. 

Just as a procedural note, we don't have to wait for any patents to expire. We can specify standards that use these patents, as long as those patents are disclosed. As in https://ietf.org/ipr/231/ .

There is a general attitude in the IETF that standardizing patented technology is bad, because it discourages open source implementations, but with such old patents (they were issued in '97, no?) that is far less a concern.

When we do standardize patented technology, implementers have four choices:
 1. Get a license
 2. Decide that the patent is bogus, and fight it in court.
 3. Wait for the patent to expire.
 4. Ignore the technology.

All implementers have lawyers, and all implementers hate paying for IPR, so #1 and #2 hardly ever happen (with notable exceptions such as RSA years ago and some codecs).

Considering that we have no proof of any adversary having a quantum computer just yet, #3 and #4 are more likely, but that's a choice for implementers to make. We can lead a horse to water and all that.

Yoav

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 13 Jan 2014 10:01:22 +0000

On 01/13/2014 06:23 AM, Yoav Nir wrote:
> All implementers have lawyers, and all implementers hate paying for
> IPR, so #1 and #2 hardly ever happen (with notable exceptions such as
> RSA years ago and some codecs).
> 
> Considering that we have no proof of any adversary having a quantum
> computer just yet, #3 and #4 are more likely, but that's a choice for
> implementers to make. We can lead a horse to water and all that.

And its also worth noting that the IETF at least also doesn't
tend to want to take on work where #3 or #4 are likely to
apply - there's enough pressing work to be done that that'd be
seen as a waste of effort by many, given the short term nature
of much IETF work. I think the non-deployment of EKE and similar
protocols is really good evidence that patents in this space
are quite effective at blocking deployment of potentially
useful technology.

But I think work on crypto for a world that contains a real
general purpose quantum computer might fit very well for CFRG
if there're enough interested and capable folks. Just don't
expect that to translate into IETF work very quickly in the
absence of a pressing demand.

S

---

From: William Whyte <[email-masked]>
Date: Mon, 13 Jan 2014 05:32:15 -0500

Hi Yoav,

> There is a general attitude in the IETF that standardizing patented
technology is bad, because it
> discourages open source implementations, but with such old patents (they
were issued in '97, no?)

The original NTRU patents were applied for in 1997, so expire in 2017.
There are a number of improvements which are also patented and expire
later.

Note that if the concern with patents is that they discourage open source
implementations, the NTRU patents are free to implement under GPL and a
number of other FOSS licenses, and this grant of rights to use the patents
is permanent and irrevocable.

https://github.com/NTRUOpenSourceProject/ntru-crypto/blob/master/LICENSE.m
d
https://github.com/NTRUOpenSourceProject/ntru-crypto/blob/master/FOSS%20Ex
ception.md

Cheers,

William

-----Original Message-----
From: Cfrg [mailto:[email-masked]] On Behalf Of Yoav Nir
Sent: Monday, January 13, 2014 1:23 AM
To: Watson Ladd
Cc: [email-masked]
Subject: Re: [Cfrg] likelihood that someone has a quantum computer (was:
Re: considering new topics for CFRG)

On Jan 13, 2014, at 6:49 AM, Watson Ladd <[email-masked]>
 wrote:

>>> post-quantum cryptography in practice, because if there is a
>>> breakthrough in quantum computing, the mad rush will be ugly.
>>
>> As I mentioned in a previous mail, I think the best way to do this is
>> to figure out how to avoid depending on a single public key algorithm
>> in any context, because all public key algorithms are potentially
>> vulnerable to technological and algorithmic breakthroughs. So
>> combining public key algorithms seems like a prudent approach. I know
>> there are Certicom patents on this but it seems that this shouldn't be
insuperable.
> and historically we've not had any real surprises in the public key
> world.
> specifying them. I'll see if McBits is amenable to standardization.
> Worst case we wait for NTRU patents to expire, and adopt it.

Just as a procedural note, we don't have to wait for any patents to
expire. We can specify standards that use these patents, as long as those
patents are disclosed. As in https://ietf.org/ipr/231/ .

There is a general attitude in the IETF that standardizing patented
technology is bad, because it discourages open source implementations, but
with such old patents (they were issued in '97, no?) that is far less a
concern.

When we do standardize patented technology, implementers have four
choices:
 1. Get a license
 2. Decide that the patent is bogus, and fight it in court.
 3. Wait for the patent to expire.
 4. Ignore the technology.

All implementers have lawyers, and all implementers hate paying for IPR,
so #1 and #2 hardly ever happen (with notable exceptions such as RSA years
ago and some codecs).

Yoav

---

From: David McGrew <[email-masked]>
Date: Mon, 13 Jan 2014 07:02:59 -0500

Hi Watson,

> so the big issue is really size, not speed.

Agreed; hash based signatures and code based encryption seem to be good 
candidates for post-quantum crypto standards, and the main issues with 
the use of those technologies will be in the amount of data that needs 
to be transported, rather than the computational cost.   I would guess 
that a key size of 100KB or so could be usable in many Internet 
applications, but not constrained devices of the Internet of Things 
variety.

David

---

From: David McGrew <[email-masked]>
Date: Mon, 13 Jan 2014 07:17:32 -0500

Hi William,

> there are Certicom patents on this but it seems that this shouldn't be 

I am skeptical about the approach of combining multiple public key 
algorithms, especially for postquantum algorithms.  This is partly 
because of the complexity of the specification and the implementation, 
but also because it would require double the amount of work from 
authors, reviewers, and implementers in order to be successful.   
Patents could also be a significant issue, as you note.

David

---

From: William Whyte <[email-masked]>
Date: Mon, 13 Jan 2014 05:48:48 -0500

Hi Watson,

> But that depends on at least one algorithm being postquantum secure, and
> historically we've
> not had any real surprises in the public key world.

I wouldn't say it "depends" on it. I would say that we know that ECC and RSA
aren't postquantum
secure and that other algorithms may be, and that using two algorithms in
parallel allows us to
deploy systems that use a newer algorithm without having to rely on it 100%.
That allows
us to start making a transition before we absolutely have to, which is
always the best time to
make it.

I don't think you can say that just because there have been few
discontinuities in the
security of algorithms there will be no discontinuities in the future. There
might be,
and if it does happen unexpectedly it'll be a big problem. It's not a
problem we need
to work on right now, but, again, that makes this a really good time to
address it.

>> Moore's law for quantum computer
>> size: http://www.quantenblog.net/physics/moores-law-quantum-computer.

> breakthrough in making
> qubits. Once you get a method that scales up, it is likely to be a large
> jump rather than
> incremental increase.

I think you're probably right and wasn't endorsing that particular page's
results, just
putting it forward as the only estimate of its type that I've seen. I agree
that it seems
more likely to be a no-later-than than a no-earlier-than estimate, but this
isn't
really my area of expertise.

Cheers,

William

-----Original Message-----
From: Watson Ladd [mailto:[email-masked]]
Sent: Sunday, January 12, 2014 11:50 PM
To: William Whyte
Cc: David McGrew; Dan Brown; [email-masked]; [email-masked]
Subject: Re: [Cfrg] likelihood that someone has a quantum computer (was: Re:
considering new topics for CFRG)

> there are Certicom patents on this but it seems that this shouldn't be

But that depends on at least one algorithm being postquantum secure, and
historically we've not had any real surprises in the public key world.
Algorithms exist that do this, we just need to be ahead of the game in
specifying them. I'll see if McBits is amenable to standardization. Worst
case we wait for NTRU patents to expire, and adopt it. Yeah, we lose some
nice stuff in the post-quantum world, but most IETF protocols will survive
no problem. Signatures are a bit nasty in the present state of knowledge,
and there is protocol review work to do. Key sizes get massively bigger:
a lot of hardcoded limits will have to be revised.

>> estimate, it would make interesting reading, but I doubt that I would
>> trust it, because the likelihood of new scientific advances cannot
>> reliably be estimated.
>
> I would say the question isn't so much "can a quantum computer be
> built?" as "what size quantum computer can be built?" There's an
> interesting 2011 blog post on that subject that tries to derive a
> Moore's law for quantum computer
> size: http://www.quantenblog.net/physics/moores-law-quantum-computer.
> I don't know how well reviewed this has been, but it's a start: key
> lines are "The blue line is a fit to the data, indicating a doubling
> of the number of qubits every 5.7±0.4 years." and "If you are bold
> enough to believe that the same scaling continues even further,
> 2048-bit RSA keys would come under attack somewhere between 2052 and
> 2059."

That's a serious underestimate because it ignores the possibility of a
breakthrough in making qubits. Once you get a method that scales up, it is
likely to be a large jump rather than incremental increase.

>> algorithm) will, or even has, become feasible? I am not an expert in
>> the area, but am interested.
>>
>>
>> skeptics who feel that quantum decoherence may make it impossible to ever
>> build a quantum computer
>> important side note: the D-Wave computer is not a real quantum
>> computer in the Peter Shor sense; it does something more like simulated
>> annealing).
>>
>> question. I expect some may argue that asking this whole question
>> just begs pointless speculation, on the grounds that if your
>> adversary (soon) has a QC, then you should have spent your time
>> switching to PQ rather than thinking about whether the adversary had
>> a QC.  In other words, I'm expecting some may say that consideration
>> of postquantum crypto is perfectly reasonable, but asking about the
>> existence of a quantum computer is pointless.
>>
>>
>> But I think it is okay for CFRG to consider it, and, nay, even try to
>> boldly quantify these, say with likelihood 2^(-64) of some
>> well-defined claim, calculated via a series of estimates.  The status
>> quo is to just claim that algorithm X with key size provides 128 bit
>> security, whatever that means, perhaps adding the exclusion against
>> quantum computers.  Adding an estimated likelihood of a quantum
>> computer gives a more meaning of what kind of security is being
>> claimed.  Maybe the postquantum researchers already have made such an
>> estimate, as part of an effort to justify a switch to postquantum.
>>
>>
>> estimate, it would make interesting reading, but I doubt that I would
>> trust it, because the likelihood of new scientific advances cannot
>> reliably be
>> power.
>> It is unlikely that those physicists would have done a better job
>> with their prognostications if they had attempted to use a formal
>> model for Bayesian inference, or some other framework for computing an
>> exact probability.
>> (The model would just mathematically formalize their beliefs, which
>> turned out to be wrong.)
>>
>> As an aside, if it were possible to come up with accurate estimates
>> for the likelihood of scientific advances, it would be reasonable to
>> apply that
>> could
>> interesting
>> to think about, but it does not seem like we should expect this sort
>> of analysis to provide us with much concrete guidance on future
>> standards.
>>
>> quantum computer; he says that "a clearly discernable and
>> well-established past pattern in practical cryptanalytic progress is
>> no guarantee that the future pattern will be the same or that there will
>> not be any surprising
>> I would understand if the CFRG chairs deem this out of scope for
>> CFRG.  If so, I hope that somebody could suggest to me off-list an
>> alternative forum.
>>
>> following.  The most likely party to have a quantum computer is a
>> large nation.
>>
>>
>> Agreed.
>>
>> crypto, except pre-shared key based stuff, and wouldn't have to
>> resort to any other chicanery.  But reports are now suggesting the
>> latter.  Well, the chicanery could all be just a cover-up ruse.  Or
>> more realistically, maybe the quantum computer is kept on reserve,
>> and more mundane cryptanalysis is used on a daily basis, maybe
>> because it is cheaper.  Still, why not just lay little lower, if a QC
>> is available? Anyway, the loose inference I'm drawing is that a
>> quantum computer does not yet exist, and further that the most likely
>> parties to have one do not anticipate being able to have one in the
>> near future.
>>
>>
>> the vast arsenal of conventional bombs that the U.S. built in 1944
>> should not have been taken as evidence that there was not an active
>> Well, this argument does not give any kind of quantified likelihood.
>> If I had to dead-reckon a likelihood, I'd make a wildly different
>> number every time, but most of them would be above 2^(-128),
>> unfortunately.
>>
>> This transmission (including any attachments) may contain
>> confidential information, privileged material (including material
>> protected by the solicitor-client or other applicable privileges), or
>> constitute non-public information. Any use of this information by
>> anyone other than the intended recipient is prohibited. If you have
>> received this transmission in error, please immediately reply to the
>> sender and delete this information from your system. Use,
>> dissemination, distribution, or reproduction of this transmission by
>> unintended recipients is not authorized and may be unlawful.
>>
>>
>>

--
"Those who would give up Essential Liberty to purchase a little Temporary
Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: arne renkema-padmos <[email-masked]>
Date: Mon, 13 Jan 2014 15:57:06 +0100

On 13/01/14 11:48, William Whyte wrote:
> security of algorithms there will be no discontinuities in the
> future. There might be,
> to work on right now, but, again, that makes this a really good time >
to address it.

It makes sense to have a fallback algorithm set, as ETSI has done with
the 3GPP algorithms:

http://www.etsi.org/services/security-algorithms/3gpp-algorithms

They standardised both KASUMI and SNOW 3G with the requirements for SNOW
3G as fallback algorithm being:
* maximizing "cryptographic distance" from KASUMI
* minimizing potential vulnerability to algebraic attacks
See:
https://www.cosic.esat.kuleuven.be/ecrypt/courses/end/slides-28/8-gilbert.pdf

Cheers,
arne

--
Arne Renkema-Padmos
@hcisec, secuso.org
Doctoral researcher
CASED, TU Darmstadt

---

From: "Igoe, Kevin M." <[email-masked]>
Date: Mon, 13 Jan 2014 18:25:07 +0000

I believe there is a consensus on the mailing list for the RG to commit
to identifying public key algorithms suitable for use should advances in 
quantum computing make Shor's algorithm a viable threat. I agree with 
William that the transition should start before we are forced to do so. 
As JFK said, "The time to repair the roof is when the sun is shining".

Volunteers for authors greatly appreciated. No need to limit ourselves
to a single technology/draft this early in the process.

Any dissenting voices out there should speak up now.

-----Original Message-----
From: Cfrg [mailto:[email-masked]] On Behalf Of arne renkema-padmos
Sent: Monday, January 13, 2014 9:57 AM
To: [email-masked]
Subject: Re: [Cfrg] likelihood that someone has a quantum computer

On 13/01/14 11:48, William Whyte wrote:
> discontinuities in the security of algorithms there will be no 
> discontinuities in the future. There might be, and if it does happen 
> unexpectedly it'll be a big problem. It's not a problem we need to 
> work on right now, but, again, that makes this a really good time >
to address it.

It makes sense to have a fallback algorithm set, as ETSI has done with the 3GPP algorithms:

They standardised both KASUMI and SNOW 3G with the requirements for SNOW 3G as fallback algorithm being:
* maximizing "cryptographic distance" from KASUMI
* minimizing potential vulnerability to algebraic attacks
See:
https://www.cosic.esat.kuleuven.be/ecrypt/courses/end/slides-28/8-gilbert.pdf

Cheers,
arne

---

From: David Wagner <[email-masked]>
Date: Mon, 13 Jan 2014 15:32:06 -0800

I agree 100% with David McGrew's message and
recommendations for the group.  I agree with his
assessment of QKD; QKD is pointless.  At present
it doesn't solve any real-world problem we actually
have.  Also, all considered, I agree that it is not a
good use of CFRG's time to develop QKD protocols
or I-D's describing how to do QKD.

Basically, I second everything David McGrew wrote.

-- David

---

From: William Whyte <[email-masked]>
Date: Mon, 13 Jan 2014 19:05:12 -0500

We can write an I-D on NTRUEncrypt and other NTRU algorithms, though this
won't happen until the end of this quarter.

I'm also still interested in combining public-key algorithms, see separate
thread.

William

-----Original Message-----
From: Cfrg [mailto:[email-masked]] On Behalf Of Igoe, Kevin M.
Sent: Monday, January 13, 2014 1:25 PM
To: 'arne renkema-padmos'; [email-masked]
Subject: Re: [Cfrg] likelihood that someone has a quantum computer

I believe there is a consensus on the mailing list for the RG to commit to
identifying public key algorithms suitable for use should advances in
quantum computing make Shor's algorithm a viable threat. I agree with
William that the transition should start before we are forced to do so.
As JFK said, "The time to repair the roof is when the sun is shining".

Volunteers for authors greatly appreciated. No need to limit ourselves to
a single technology/draft this early in the process.

-----Original Message-----
From: Cfrg [mailto:[email-masked]] On Behalf Of arne renkema-padmos
Sent: Monday, January 13, 2014 9:57 AM
To: [email-masked]
Subject: Re: [Cfrg] likelihood that someone has a quantum computer

to address it.

It makes sense to have a fallback algorithm set, as ETSI has done with the
3GPP algorithms:

https://www.cosic.esat.kuleuven.be/ecrypt/courses/end/slides-28/8-gilbert.
pdf

Cheers,
arne

---

From: William Whyte <[email-masked]>
Date: Mon, 13 Jan 2014 21:04:12 -0500

Hi Arne,

So is the idea that all devices have to implement both algorithms? Is
there a mechanism in place for declaring one broken and requiring that the
other is used at all times?

TBH I'm less concerned about catastrophic failure of symmetric algorithms
than public-key algorithms, but I'm very interested in processes to
replace algorithms.

Cheers,

William

-----Original Message-----
From: Cfrg [mailto:[email-masked]] On Behalf Of arne renkema-padmos
Sent: Monday, January 13, 2014 9:57 AM
To: [email-masked]
Subject: Re: [Cfrg] likelihood that someone has a quantum computer

to address it.

Cheers,
arne

---

From: William Whyte <[email-masked]>
Date: Mon, 13 Jan 2014 21:15:57 -0500

Hi David,

>> I am skeptical about the approach of combining multiple public key
algorithms, especially for postquantum algorithms.  This is partly because
of the complexity of the specification and the implementation, but also
because it would require double the amount of work from authors, reviewers,
and implementers in order to be successful.

I’m not sure it’s necessarily that complex. If we have an asymmetric key
transport mechanism KT that transports key material k and is semantically
secure, and we have a secure KDF, it seems that

Transport: KT1(k1), KT2(k2), KT3(k3), …

Secret k = KDF(k1, k2, k3, …)

..will also be semantically secure. Obviously this would need to be
demonstrated rigorously, but rather than seeing “double the amount of work”
from the standardization point of view, I see one task to define a secure
combination mechanism, and then a series of tasks to standardize individual
key transport mechanisms, where this series of tasks would have to be done
anyway by people who wanted their algorithms adopted.

For signatures, assuming we’re looking only at diversity in public key
algorithms and not hash algorithms, it’s the same: the message simply takes
two signatures, one from each algorithm.  Again, this would have to be
specified rigorously. I think diversity in signatures is less urgent than
for encryption algorithms, because of the risk of an attacker storing
messages for a long time and decrypting them when possible, but it’s worth
considering.

Similarly, implementations have one additional task rather than double the
amount of tasks. Testing may be more complicated if all pairwise
combinations of algorithms are to be tested, but I expect the total number
of algorithms will never be too big.

Finally, authenticating the public keys may require building support for
new algorithms into CAs, which could be laborious (though again, I would
argue that you should do this when you don’t have to).

> Patents could also be a significant issue, as you note.

Yes, agreed. This would need to be looked into.

Cheers,

William

*From:* David McGrew [mailto:[email-masked]]
*Sent:* Monday, January 13, 2014 7:18 AM
*To:* William Whyte
*Cc:* Dan Brown; [email-masked]; [email-masked]
*Subject:* Re: [Cfrg] likelihood that someone has a quantum computer

Hi William,

Hi all,

I am skeptical about the approach of combining multiple public key
algorithms, especially for postquantum algorithms.  This is partly because
of the complexity of the specification and the implementation, but also
because it would require double the amount of work from authors, reviewers,
and implementers in order to be successful.   Patents could also be a
significant issue, as you note.

David

---

From: David McGrew <[email-masked]>
Date: Tue, 14 Jan 2014 09:42:48 -0500

Hi William,

On 01/13/2014 09:15 PM, William Whyte wrote:
> I’m not sure it’s necessarily that complex. If we have an asymmetric 
> key transport mechanism KT that transports key material k and is 
> semantically secure, and we have a secure KDF, it seems that
>
> demonstrated rigorously, but rather than seeing “double the amount of 
> work” from the standardization point of view, I see one task to define 
> a secure combination mechanism, and then a series of tasks to 
> standardize individual key transport mechanisms, where this series of 
> tasks would have to be done anyway by people who wanted their 
> algorithms adopted.
>

Let me explain my skepticism by pointing out some places where 
complexity could arise in this scenario.  What you describe would work 
for key transport, but not for key exchange, which excludes DH and 
ECDH.   For a protocol that negotiates algorithms, how would this 
combination be negotiated?   In TLS, for instance, would there need to 
be a ciphersuite for each possible combination of public key 
algorithms?    Or would there need to be two parallel negotiations, with 
an assurance that any possible combination of algorithms that might 
result from the negotiation can be used together?   If the protocol 
aimed to provide identity hiding, would it be expected that both KT 
algorithms would be run twice, once anonymously and once otherwise?  
Would the algorithms use the same nonces?   If so, what if the number of 
messages exchanged in the KT protocols are different?

It is important to establish what the goals would be in using two 
different algorithms.  One goal that some users have is to protect 
traffic with two completely independent crypto implementations, e.g. 
sourced from two different vendors, and thus designed, implemented, and 
tested by two independent teams.   This is done today to provide a 
higher level of assurance using commercial cryptography, by running two 
products that implement standards like IPsec, TLS, or SRTP so that the 
encrypted traffic from one implementation is treated as the plaintext 
traffic by the other implementation. Using two layers protects against 
the possibility that one of the implementations contains an exploitable 
vulnerability or a significant flaw.  This idea is used by the US govt 
information assurance program (see for instance Section 4.4 of 
http://www.nsa.gov/ia/_files/VPN_CP_v2.pdf ) and other nations as well 
(though I can't point to public information for the other cases that I 
know of).   An important property of a two-layer scheme is the 
independence of the two crypto implementations, and it seems that this 
property would be lost in the parallel key transport idea that you 
outlined above.

> algorithms and not hash algorithms, it’s the same: the message simply 
> takes two signatures, one from each algorithm.  Again, this would have 
> to be specified rigorously. I think diversity in signatures is less 
> urgent than for encryption algorithms, because of the risk of an 
> attacker storing messages for a long time and decrypting them when 
> possible, but it’s worth considering.
>

It seems that signatures would be easier to do, since signing could be 
done in parallel.  But what is not clear is that we would want or need a 
new signature standard to do this. A CA could create two certificates, 
one with each algorithm, using existing standards. (Probably the 
standards could be improved to better allow the selection of appropriate 
certificates by applications.)

Speaking as an individual member of the RG: I am not opposed work on the 
use of multiple algorithms, but I do not see it as a high priority right 
now, and I feel strongly that such work would be most impactful and 
beneficial if it enabled the use of two completely independent crypto 
implementations.

regards,

David

> Similarly, implementations have one additional task rather than double 
> the amount of tasks. Testing may be more complicated if all pairwise 
> combinations of algorithms are to be tested, but I expect the total 
> number of algorithms will never be too big.
>
> Finally, authenticating the public keys may require building support 
> for new algorithms into CAs, which could be laborious (though again, I 
> would argue that you should do this when you don’t have to).
>
> *From:*David McGrew [mailto:[email-masked] <mailto:[email-masked]>]
> *Cc:* Dan Brown; [email-masked] <mailto:[email-masked]>; 
> [email-masked] <mailto:[email-masked]>
>     As I mentioned in a previous mail, I think the best way to do this
>     is to figure out how to avoid depending on a single public key
>     algorithm in any context, because all public key algorithms are
>     potentially vulnerable to technological and algorithmic
>     breakthroughs. So combining public key algorithms seems like a
>     prudent approach. I know there are Certicom patents on this but it
>     seems that this shouldn't be insuperable.
>
>

---

From: arne renkema-padmos <[email-masked]>
Date: Tue, 14 Jan 2014 23:48:51 +0100

>From what I could find KASUMI (UEA1,UIA1) and SNOW 3G (UEA2,UIA2) are
the "preferable HW [hardware] profile for UMTS", whatever that means:

http://docbox.etsi.org/workshop/2008/2008_securityworkshop/s8_2_taizo_shirai.pdf

I'm not sure what mechanism is in place for fallback and would
appreciate if others could chime in.

> than public-key algorithms, but I'm very interested in processes to

I agree that this is more of a general problem that is not algorithm
bound. It's not even a problem bound to cryptography, although I guess
we might be able to identify best practices (or whatever you'd like to
call them) specific to cryptography in informing algorithm roll-out.

Cheers,
arne

-- 
Arne Renkema-Padmos
@hcisec, secuso.org
Doctoral researcher
CASED, TU Darmstadt

---

From: "Igoe, Kevin M." <[email-masked]>
Date: Wed, 22 Jan 2014 17:29:52 +0000

If we were to put "key centric" on the CFRG agenda for IETF-89, do we 
have a speaker willing to give a presentation?  If this is too short of a 
deadline to meet, we can always have a presentation at a later meeting?

Three options: 
	1) discuss at nest meeting
	2) discuss in the near future but not at the next meeting
	3) no support for a presentation in the near future. Maybe sometime later.
	4) Utter silence on the mailing list.

As to #4, the Germans have a saying "Keine Antwort ist auch eine Antwort"
(no is answer is also an answer).

> From: Cfrg [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Friday, January 10, 2014 12:10 PM
> To: Paul Lambert
> Cc: Sean Turner; David McGrew; [email-masked]
>  > A useful mechanism, but it would be better to start with reexamining
> and  > redefining our usage of public keys.  Specifically - I'm an
> advocate of  > keys as the primary identifiers.  A "key centric"
> approach is a dual model
> I rather doubt that the Administration's push for the NSTIC is likely
> to settle in on key-centricity, but might you elaborate on your
> preference for it?  I'm sympathetic to it on the grounds that it
> directly enables multi-personna and, thus, data segmentation.
>

---

From: Paul Lambert <[email-masked]>
Date: Thu, 23 Jan 2014 10:37:01 -0800

Hi Kevin,

On 1/22/14, 9:29 AM, "Igoe, Kevin M." <[email-masked]> wrote:

>have a speaker willing to give a presentation?
Thank you for your interest in the topic. I would be very willing and
interested in presenting on Œkey centric¹, however for the first time
in many years the IETF is occurring the same week as the Wi-Fi
Alliance Š so I¹m not available that week.

>If this is too short of a
Yes.  That would work well.

Paul

---

From: David McGrew <[email-masked]>
Date: Fri, 24 Jan 2014 07:34:24 -0500

Hi Kevin and Paul,

I think the key-centric stuff is interesting and worthwhile, but to some 
extent it is outside the scope of CFRG.   Can I ask that the CFRG 
presentation on this topic cover the crypto mechanisms and protocols 
that are relevant for a key-centric architecture, rather than focus on 
the public-key authentication architecture itself?

Not trying to discourage work in this area, just trying to make sure 
that agenda time covers algorithms and protocols first.

David

---

From: Paul Lambert <[email-masked]>
Date: Fri, 24 Jan 2014 14:38:31 -0800

David,

]Hi Kevin and Paul,
]
]I think the key-centric stuff is interesting and worthwhile, but to some
]extent it is outside the scope of CFRG.  
Perhaps yes since it's not just number theory.  However I'm not sure 
where else any discussion would belong in the IETF.  I also just noticed my 
response to Dan's last question on this topic is still dormant 
in my drafts box, so I will dump one more note to this list ... 
Advice on any forum to discuss non-X.509 public key architectures
would be appreciated.

] Can I ask that the CFRG
]presentation on this topic cover the crypto mechanisms and protocols
]that are relevant for a key-centric architecture, rather than focus on
]the public-key authentication architecture itself?

???  
Protocols should be defined by the use cases and architecture.

The grab-bag of mechanisms is still an interesting list, but 
Might be confusing when taken out-of-context from the use
Case analysis and overall architecture.  I've already been
asking related questions to the list.  Mechanism specific
topics related to a 'key centric' architecture might
include:  
 - public key algorithms and alternative algorithms 
   (like Edwards curves)
 - public key algorithm representation, identification and enumeration
   (partial proposal previously posted to list on naming 
   ... no response)
 - definition of cipher suites in to facilitate
   the clear semantics of public key usage in combination
   with the other necessary cryptographic mechanisms.
   Public keys and associated hashes, kdfs, encryption 
   Are handled in various ways in Internet protocols.
   If the semantics of a public key is to be well defined, it
   needs to be clearly associated with a set of appropriate
   algorithms.
 - privacy and anonymity mechanisms related to encodings
   of key and key identifiers
 - definition and of suitable crypto 
   mechanisms/standards for generation of key identifiers
 - definition of suitable encoding mechanism for binary
   identifiers and keys (human readable)
 - clear definition and enumeration of crypto mechanisms
   suitable for particular public key types
   (e.g. earlier discussion of encrypting and signing 
   with the same public key)
 - cryptographic protocols using public keys to
   support various types of authentication and
   the bootstrapping of 'key centric' identities.
   The protocols need to be tuned to the use case 
   requirements.  

On protocols ... is the discussion of set theoretic 
protocol semantics (like RT) a viable topic area for this group?
Or ... is this group limited to number theoretic discussions?

]]Not trying to discourage work in this area, just trying to make sure
]that agenda time covers algorithms and protocols first.

First - when you say agenda, is it the yet to be scheduled 
invited F2F presentation (likely would have been July)
or the agenda of this mailing list?

Algorithms would never be the first thing I'd present.
So, your limitations are very discouraging.  I was at first 
enthusiastic that there was any interest in my proposed 
set of architectural concepts. Now, rather than being able to
present a coherent set of ideas, you are telling me to 
focus on the 'math/crypto'.  The architectural concepts 
need to defined before the math.   I'd be happy to have
review of material prior to a f2f presentation and
adjustments could be made at that point. 

I will just move my work to non-IETF forums if 
contributions are discouraged or if they are not able 
to make any impact. The impact of a 'research' group
is questionable by definition and I fear I am wasting 
my time participating on this mailing list.

Paul

]
]David
]
]On 01/23/2014 01:37 PM, Paul Lambert wrote:
]> Hi Kevin,
]>
]> On 1/22/14, 9:29 AM, "Igoe, Kevin M." <[email-masked]> wrote:
]>
]>> If we were to put "key centric" on the CFRG agenda for IETF-89, do we
]>> have a speaker willing to give a presentation?
]> Thank you for your interest in the topic. I would be very willing and
]> interested in presenting on Œkey centric¹, however for the first time
]> in many years the IETF is occurring the same week as the Wi-Fi
]> Alliance Š so I¹m not available that week.
]>
]>> If this is too short of a
]>> deadline to meet, we can always have a presentation at a later
]meeting?
]> Yes.  That would work well.
]>
]> Paul
]>
]>> Three options:
]>> 	1) discuss at nest meeting
]>> 	2) discuss in the near future but not at the next meeting
]>> 	3) no support for a presentation in the near future. Maybe
]sometime
]>> later.
]>> 	4) Utter silence on the mailing list.
]>>
]>> As to #4, the Germans have a saying "Keine Antwort ist auch eine
]Antwort"
]>> (no is answer is also an answer).
]>>
]>>> -----Original Message-----
]>>> From: Cfrg [mailto:[email-masked]] On Behalf Of [email-masked]
]>>> Sent: Friday, January 10, 2014 12:10 PM
]>>> To: Paul Lambert
]>>> Cc: Sean Turner; David McGrew; [email-masked]
]>>> Subject: Re: [Cfrg] considering new topics for CFRG
]>>>
]>>>
]>>>   > A useful mechanism, but it would be better to start with
]>>> reexamining and  > redefining our usage of public keys.
]>>> Specifically - I'm an advocate of  > keys as the primary
]identifiers.  A "key centric"
]>>> approach is a dual model
]>>>   > to Kohnfelder/X.509   The SDSI/SPKI work did progress work in
]this
]>>>   > direction, but failed for a variety of reasons.
]>>>
]>>> Key-centric versus name-centric identity is The Question, is it not?
]>>>
]>>> I rather doubt that the Administration's push for the NSTIC is
]>>> likely to settle in on key-centricity, but might you elaborate on
]>>> your preference for it?  I'm sympathetic to it on the grounds that
]>>> it directly enables multi-personna and, thus, data segmentation.
]>>>
]>>> If I'm being obtuse, feel free to say so.
]>>>
]>>> --dan
]>>>
]>>> _______________________________________________
]>>> Cfrg mailing list
]>>> [email-masked]
]>>> http://www.irtf.org/mailman/listinfo/cfrg
]> .
]>

---

From: Rene Struik <[email-masked]>
Date: Fri, 24 Jan 2014 18:17:25 -0500

Hi Paul:

It may help to write a short I-D where you introduce the topic of 'key 
centric' architecture, so that people who are unfamiliar with the topic 
area have context and a potential problem statement to work from 
(researchers like problem statements...). This also makes it easier to 
add to this than going over past emails sent to mailing lists.

I can imagine this would fit with saag or cfrg, depending on details.

It would be great to see you in Toronto in July.

Best regards, Rene

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Richard Barnes <[email-masked]>
Date: Sat, 25 Jan 2014 09:21:02 +0100

+1 to an I-D

Key centric architecture sounds like something I would be interested in.  I
think I've got a rough idea of what Paul means based on his mail, but would
appreciate more detail on what he's thinking.

On Sat, Jan 25, 2014 at 12:17 AM, Rene Struik <[email-masked]> wrote:

> (researchers like problem statements...). This also makes it easier to add
> to this than going over past emails sent to mailing lists.
>

---

From: David McGrew <[email-masked]>
Date: Sun, 26 Jan 2014 04:17:44 -0500

Hi Paul,

> ]the public-key authentication architecture itself?

What I'm asking is just that the presentation cover topics in the RG 
charter.   From the list you provide below, it looks like this won't be 
a problem.

> Case analysis and overall architecture.

Yes, by all means explain the architecture.

>    I've already been

Good topic, IMO.

>     of key and key identifiers

Another good topic.

>     mechanisms/standards for generation of key identifiers

And another.

> Or ... is this group limited to number theoretic discussions?

Short answer: no.   Long answer: please see the charter at 
http://irtf.org/cfrg

> or the agenda of this mailing list?

We requested a slot at IETF 89 in London, 
http://www.ietf.org/meeting/89/index.html and when I said "agenda" I was 
referring to that meeting.   Yes, I realize now that you will be at IETF 
90 but not IETF 89.

> my time participating on this mailing list.

I think you misunderstood me.   As you know, one of the responsibilities 
of a chair is to make sure that either the group stays within its 
charter, or changes its charter when needed.   At any rate, after seeing 
the list of topics that you intend to address, I don't have any concerns.

David