Subject: [Lurk] getting started with lurking

From: Stephen Farrell <[email-masked]>
Date: Tue, 19 Jan 2016 17:46:19 +0000

Hiya,

There're ~50 people subscribed now which is enough to get
started. My take so far is that this topic likely needs a
bit of f2f discussion so for now, I think we're aiming for
a BoF at IETF95. ('course I may be wrong - that isn't at
all uncommon:-)

I guess the first order of business is to try figure out
if there's a problem here that folks are interested in
solving in the IETF, and if so, with what scope.

I think the "offload TLS without giving the CDN my private
key" use-case seems to be the thing from which to start,
so:

- Who's interested in there being a standards track RFC
  for that? (Or who thinks that'd be a bad plan?)

- Should we generalise from the above to include within
  scope other uses of asymmetric private keys? If so,
  what scope would you suggest? If not, why?

- Who has written (or is planning to write) an I-D related
  to this? (If written, please send link. If to-be-written,
  please do that and then send link:-)

Thanks,
S.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 19 Jan 2016 17:48:34 +0000

Yes a BoF.

I'm interested in a standards-track RFC.  I think CDN use is useful, but perhaps more generally it's any "cloud provider"  E.g., I'd like to keep my keys private and not share them with, say, IBM's smartcloud.

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

---

From: Dmitry Belyavsky <[email-masked]>
Date: Tue, 19 Jan 2016 22:22:36 +0300

Hello Stephen,

>   for that? (Or who thinks that'd be a bad plan?)

I am not sure it should be a RFC specifying the protocol. It seems more
reasonable to have a RFC describing BCP.

Thank you!

-- 
SY, Dmitry Belyavsky

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 19 Jan 2016 19:41:32 +0000

Hi Dmitry,

> reasonable to have a RFC describing BCP.

I'm not sure I get what you mean there sorry. Can you
elaborate?

The way I've been thinking about this is that there'd
be a need for some new protocol between (at least) a TLS
server and the private key holder, and that that protocol
would need to allow the private key holder to authorize the
TLS server (somehow). So in my mind, a BCP [1] doesn't
seem like the right kind of output, since a new protocol
seems to be needed.

Thanks,
S.

[1] https://tools.ietf.org/html/bcp9#section-5

> 
> Thank you!
> 
> 
> 
> _______________________________________________
> Lurk mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lurk
>

---

From: "Mishra, Sanjay" <[email-masked]>
Date: Tue, 19 Jan 2016 15:04:50 -0500

Could someone please point me to the use case referred to in the email below? 

-Sanjay

-----Original Message-----
From: Lurk [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Tuesday, January 19, 2016 12:46 PM
To: [email-masked]
Subject: [Lurk] getting started with lurking

Hiya,

There're ~50 people subscribed now which is enough to get started. My take so far is that this topic likely needs a bit of f2f discussion so for now, I think we're aiming for a BoF at IETF95. ('course I may be wrong - that isn't at all uncommon:-)

I guess the first order of business is to try figure out if there's a problem here that folks are interested in solving in the IETF, and if so, with what scope.

I think the "offload TLS without giving the CDN my private key" use-case seems to be the thing from which to start,
so:

Thanks,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 19 Jan 2016 20:09:56 +0000

Hiya,

> Could someone please point me to the use case referred to in the email below? 

There's no current document describing that (and I hope there
won't be, mail should be fine) but it's what one cdn has I
think called "keyless ssl." Other folks who've done similar
stuff have different names I think but that should be enough
to figure out the "what" (the "how" would be for later)

S

---

From: Dmitry Belyavsky <[email-masked]>
Date: Tue, 19 Jan 2016 23:21:37 +0300

Hello Stephen,

On Tue, Jan 19, 2016 at 10:41 PM, Stephen Farrell <[email-masked]

> seem like the right kind of output, since a new protocol

I am not sure that there should be a one universal protocol
(at least binary/JSON variants of transport are possible),
but there are common design requirements to make any
such a protocol secure.

So if a set of design principles and recommendations does not
match the BCP description, it may be a common part of all such protocols
(or the only one).

-- 
SY, Dmitry Belyavsky

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 19 Jan 2016 20:33:23 +0000

> (at least binary/JSON variants of transport are possible),

Possible yes, but I'm not seeing why >1 way of doing
this is desirable. Why do you think that?

> but there are common design requirements to make any

Yes, I get what you mean now thanks.

I'm not sure how that'd get us interop between the
TLS server and private key holder though, but one
could take a framework-ey approach, sure. If folks
like/dislike that idea, saying so would be good as
they respond to the other questions I sent.

S.

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Tue, 19 Jan 2016 21:25:23 +0000

>to figure out the "what" (the "how" would be for later)

Note that there is a data center use case that is similar enough we should be able to use the same protocol: I don't want the private keys to be directly accessible from the memory of an HTTPS server running in a container, because I don't trust the isolation that the container system provides.

-- 
Joe Hildebrand

---

From: Nick Sullivan <[email-masked]>
Date: Tue, 19 Jan 2016 13:51:12 -0800

There is a current draft called Session Key Interface (SKI) for TLS and DTLS
 (https://tools.ietf.org/html/draft-cairns-tls-session-key-interface-01),
does this describe what you are looking for?

Nick

On Tue, Jan 19, 2016 at 12:09 PM, Stephen Farrell <[email-masked]

> > There're ~50 people subscribed now which is enough to get started. My
> take so far is that this topic likely needs a bit of f2f discussion so for
> now, I think we're aiming for a BoF at IETF95. ('course I may be wrong -
> that isn't at all uncommon:-)
> >
> > I guess the first order of business is to try figure out if there's a
> problem here that folks are interested in solving in the IETF, and if so,
> with what scope.
> >
> > I think the "offload TLS without giving the CDN my private key" use-case
> seems to be the thing from which to start,
> > so:
> >

---

From: Daniel Migault <[email-masked]>
Date: Tue, 19 Jan 2016 22:12:12 +0000

Hi , 

I support the BoF and would like the "offload TLS without giving the CDN my private key" use-case being solved by a standard track RFC.

We have already published a an architecture draft [1], a use-case draft [2] and a requirement draft [3]. I am planning to provide an abstract API draft soon too.  

Feel free to provide feed backs! Comments are more than welcome!

BR, 
Daniel

[1] https://tools.ietf.org/html/draft-cairns-tls-session-key-interface-01
[2] https://tools.ietf.org/html/draft-mglt-lurk-tls-use-cases-00
[3] https://tools.ietf.org/html/draft-mglt-lurk-tls-requirements-00

-----Original Message-----
From: Lurk [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Tuesday, January 19, 2016 12:46 PM
To: [email-masked]
Subject: [Lurk] getting started with lurking

Hiya,

Thanks,
S.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 20 Jan 2016 00:31:39 +0200

> On 19 Jan 2016, at 7:48 PM, Salz, Rich <[email-masked]> wrote:
> 
> Yes a BoF.
> 
> I'm interested in a standards-track RFC.  I think CDN use is useful, but perhaps more generally it's any "cloud provider"  E.g., I'd like to keep my keys private and not share them with, say, IBM's smart cloud.

Right, and the same goes for hosting services.

I think there are several ways to tackle this, in all of them the CDN, or cloud or host don’t get the customer’s private key. Let’s use the example of www.ietf.org and CloudFlare.

One way (and I think CloudFlare is doing this) is to have a connection between cloudflare and the IETF so that when the TLS protocol calls for some buffer to be signed by the private key, this buffer is forwarded to a signing server hosted by the IETF, and that server performs the signature. This has several downsides. First, it adds latency at least for the handshake. Second, the trust required becomes very hairy, because the signing server is basically signing whatever hash is presented to it. But worst of all, IMO, it requires the customer (the IETF in this case) to have as much scalability and availability as the CDN or cloud provider. Whenever the IETF server is not available due to software failure, hardware failure or trouble in some ISP or router between the IETF server and the cloud, the website is down, or at least no new handshakes can be performed.

Another way would be to modify TLS to have signature sub-keys. This is essentially another layer of certification except you don’t call it that. So the customer signs a DH share for the CDN server and that signature is valid for a short time (minutes or hours) and the server can then perform the handshake. Note that this would require changes to TLS, because the signature is over the share only, not all the transcript. The TLS working group considered this a few IETFs ago. Ultimately it was rejected, among other reasons because it creates new certificates without all the infrastructure that surrounds real certificates - no revocation for example.

Yet a third way would be for redirection. When I lookup the address for www.ietf.org, I get a CNAME record for www.ietf.org.cdn.cloudflare-dnssec.net. If only I could trust this CNAME record, I wouldn’t need www.ietf.org.cdn.cloudflare-dnssec.net to present a certificate for www.ietf.org; it would work well if that server presented a certificate for www.ietf.org.cdn.cloudflare-dnssec.net - its true DNS name. So if DNS was secure, like if DNSSEC was universally deployed and checked by OS resolvers, we could just use the DNS. This idea was discussed a while ago in DANE (where else?) but it has the drawback that it relies on universal deployment of DNSSEC. Perhaps some other secure redirection mechanism can be deployed instead.

The first of these methods has the draw that it can work changing neither the TLS protocol or the clients or the DNS. To me it is much too complicated and negates a lot of the benefits of these providers. Ultimately, I think the right thing is redirection. But I’m not sure how we can get there without relying on a secure DNS. I believe there is more than one approach, so we should definitely have a BoF, but it probably won’t be WG-forming.

Yoav

---

From: Martin Thomson <[email-masked]>
Date: Wed, 20 Jan 2016 12:00:03 +1100

>   please do that and then send link:-)

I have a proposal.  To be written, unfortunately.

I'm still not 100% convinced that it's a good idea, but then anything
of this nature doesn't have 100% of the security properties we might
like to have.