Subject: [Lurk] New documented submitted

From: "Salz, Rich" <[email-masked]>
Date: Fri, 18 Mar 2016 19:03:56 +0000

https://datatracker.ietf.org/doc/draft-erb-lurk-rsalg/

A PFS-preserving protocol for LURK.  If the WG is created, we will ask the group to adopt it.

There is an IPR disclosure that is in the system. Our intent is royalty-free for anyone who cross-licenses their patents to us.

--
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 18 Mar 2016 19:56:52 -0400

On Fri, Mar 18, 2016 at 3:03 PM, Salz, Rich <[email-masked]> wrote:
> There is an IPR disclosure that is in the system. Our intent is royalty-free
> for anyone who cross-licenses their patents to us.

"   The protocol should not become a generic signing oracle, even if it
   is suboptimal with regard to network bandwidth utilization.  This is
   done by not simply signing values, but by computing the full
   signature hash at the KeyOwner."

I started off with that as a requirement. Then I deleted it.  The
reasoning is as follows:

First, what does the limitation get us? Is a TLS signature key to be
shared with any other purpose? I really hope not. That would be very
bad indeed. So what does this restriction achieve?

There is a measurable cost. It makes the protocol specific to TLS and
specific TLS key agreements to boot. It also breaks with existing
APIs. I won't be able to use your approach with IIS unless and until
they update the TLS implementation. If I use another Web server I have
to wait for implementation in OpenSSL or whatever or have to deal with
custom patches.

Many existing servers already have a socket for plugging in custom
crypto to support accelerator boards. I agree we should not limit
ourselves to that API but we definitely need to support it.

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 19 Mar 2016 00:50:20 +0000

> First, what does the limitation get us?

Protection against the next DROWN?  Protection against poor key hygiene?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 18 Mar 2016 22:13:57 -0400

> Protection against the next DROWN?  Protection against poor key hygiene?

Is that a practical proposition though?

Is it going to be possible to have a server with two different certs
and keys for doing two different versions of TLS?

This approach does impose quite severe limitations on implementation
that a lot of folk won't be able to cope with. I accept it as a valid
option but I don't think it can be the only option offered.

My much bigger remote key concern right now is software jockeys losing
their code signing keys. There are umpteen bazillion different code
signing schemes out there. I would like to get them tamed.

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 19 Mar 2016 02:31:01 +0000

> Is that a practical proposition though?

Is what a practical proposition?  DROWN or key re-use?  To me, the answer is both.

But if the WG doesn't think so, they're free to not pick up the draft.

> This approach does impose quite severe limitations on implementation that a
> lot of folk won't be able to cope with. I accept it as a valid option but I don't
> think it can be the only option offered.

Agree not the only one.  But it does address the main use case picked so far.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 18 Mar 2016 22:40:46 -0400

> Agree not the only one.  But it does address the main use case picked so far.

What worries me is that if we tie this to TLS we will end up with it
tied to a specific version of TLS and then we will find we have to do
changes in both places to move ahead.

We need that flexibility more often than it might appear.

I can drop in the TLS specific agreement to my code without
difficulty, I just don't have any way to test it in situ right now.

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 19 Mar 2016 16:48:19 +0200

> But if the WG doesn't think so, they're free to not pick up the draft.
I agree with Rich that we need to protect people who are reusing their 
TLS server key as a code signing key.

Thanks,
     Yaron

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 19 Mar 2016 11:23:01 -0400

On Sat, Mar 19, 2016 at 10:48 AM, Yaron Sheffer <[email-masked]> wrote:
> I agree with Rich that we need to protect people who are reusing their TLS
> server key as a code signing key.

I agree with that. But there are other ways to achieve the same thing.

For example, in my draft I suggest using a split key system with the
server and the device each holding part of the private key
corresponding to the public key in the certificate. That is very
straightforward if we are doing ECDH key agreement as the basis.

Since the key we need to protect here is the authentication key and
since we haven't yet considered how to put the new CFRG curves into
certificates, we have a lot of flexibility here. We can specify a new
TLS key exchange at the same time.

I can add in a mechanism to enforce perfect forward secrecy in the
LURK Server as well.but ideally what I would want is to allow
enforcement by both the client and the server.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 19 Mar 2016 13:47:33 -0400

OK, so how about this as a mechanism. Right now, when a key is
created, the administrator (in my terminology) can specify the key
uses by means of three binary flags for Signature, Encryption and Key
Exchange.

I suggest that this instead become a list of strings specifying
permissible uses and a registry to manage code points.

So if I want to have a key for unrestricted signing, when I do the
keygen the uses list would be

{...
"Uses" : ["signature"],
...}

If I want to bind to the TLS key agreement, or the scheme Rich
describes, or my threshold scheme it might be:

{...
"Uses" : ["tls_a", "tls_b", "tls_c"],
...}

This would also allow for a HSM that used LURK as its interface to
specify other constraints. For example, the key can only be used to
sign X.509v3 certificates.

{...
"Uses" : ["pkix"],
...}

Now obviously, there is a large potential here for this running away
with lots and lots of complexity and custom jobbies. And I really
don't want to see the interface turning into a Turing complete
language for describing key use constraints or anything close. So if
someone has something really complex they want to support on their
HSM, they can write a custom language and then use the digest of the
control file as the tag:

{...
"Uses" : ["MAK5Z-PEEEQ-PWT53-GRR55-MTBSF-UDVGM"],
...}

Yes, it might seem like overkill. But one of the nice things about
considering overkill in use cases is that it forces the design to
separate complexity out rather than allow 'just a little bit' in which
inevitably becomes a slippery slope.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 21 Mar 2016 12:53:42 +1100

> A PFS-preserving protocol for LURK.  If the WG is created, we will ask the

I have to ask, why support only the worst cipher suites?  I don't
think that it's unreasonable to ask for, or even demand, PFS on the
TLS connection as well.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 21 Mar 2016 01:55:45 +0000

> I have to ask, why support only the worst cipher suites?  I don't think that it's
> unreasonable to ask for, or even demand, PFS on the TLS connection as well.

Where did we do that?  Probably an editing error.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 21 Mar 2016 12:58:10 +1100

> Where did we do that?  Probably an editing error.

I didn't see anywhere that you have support for anything other than
TLS_RSA_* suites and RSA key exchange.  That gives you ephemeral
keying at the server, but the key owner remains a point of compromise.

Did you upload the wrong document?

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 21 Mar 2016 02:03:54 +0000

> TLS_RSA_* suites and RSA key exchange.  That gives you ephemeral keying
> at the server, but the key owner remains a point of compromise.

You mean, why didn't we define something like "ecclg" analogous to rsalg?  We will if there's interest.

If you mean something else, sorry, I don't understand.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 21 Mar 2016 13:08:40 +1100

> If you mean something else, sorry, I don't understand.

Sorry, I'm being obtuse.

I don't think that it is worth the time of this working group if we
only define solutions for non-PFS cipher suites.  And, to go further,
we should ONLY work on solutions for PFS suites.

I don't really care about the ECC/RSA choice.  I'd prefer something
that allows for either, of course.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 21 Mar 2016 02:16:26 +0000

> I don't think that it is worth the time of this working group if we only define
> solutions for non-PFS cipher suites.  And, to go further, we should ONLY work
> on solutions for PFS suites.

Thanks for the clarification.  FWIW I disagree.

---

From: Василий Долматов <[email-masked]>
Date: Mon, 21 Mar 2016 14:25:47 +0700

> 
> I don't really care about the ECC/RSA choice.

>  I'd prefer something
so would I, saying it ‘…for either or other’.

Technologies change rapidly, so new protocols should have the possibility to incorporate such chenges without being rebuilt from the scratch.

dol@

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 21 Mar 2016 14:36:35 +0200

> that allows for either, of course.
My reading of draft-erb-lurk-rsalg is that it supports all commonly used 
ciphersuites (DHE, ECDHE as well as plain RSA), while also adding a nice 
feature than only pertains to the non-PFS ciphersuites.

 From a requirements perspective, given that many clients still use RSA, 
CDNs must support them and therefore any solution we come up with must 
also support these ciphersuites, as much as we may dislike them.

Thanks,
     Yaron