[Lurk] IETF-96 LURK raw minutes

[[e-mail]]

minutes were taken at  
<http://etherpad.tools.ietf.org:9000/p/notes-ietf-96-lurk> by Jeff  
Hodges and Lucas Jones (i hope i got your name right..).

here's the a raw text export of the minutes right after the session ended...


LURK - IETF-96 Berlin
Monday 18:00-20:00, Potsdam III
Chairs: Eric Burger (remote) and Yaron Sheffer

> Chairs intro (Eric and Yaron, 10 min.)

* Chair Slides  
<https://www.ietf.org/proceedings/96/slides/slides-96-lurk-0.pdf>

Yaron Sheffer (ys) goes thru chair slides...


###
> Use cases (Daniel Migault (dm), 20 min.)

* LURK Use Cases  
<https://www.ietf.org/proceedings/96/slides/slides-96-lurk-1.pdf>

[ daniel goes thru slides... skipped the LURK Requirements slides 6 & 7 ]

dmitry belyavskiy: points at CDN Interconn use case -- CDN1 and CDN2  
and content owner... need to have interactions between CDN2 and the  
key server

dm: use cascading contractual arrangements

ekr: question for chairs -- is there supposed consensus on these use cases?
ys: we will discuss one specific use case in scope of the charter, use  
case 3 "content owner / content provider" use case -- this is the only  
one in scope for the proposed charter (it is the one agreed to on the  
mailing list)

subodh(?): <missed it>
marting thomson(mt): i am cdn provider, i have boxes in hostile  
environs, having them use lurk addresses this and, yeah, is same use  
case...

MT: all these [use cases] boil down to same use cases..?
ekr: says the 1st use case doesn't

dkg: wrt cnt owner / cnt provider (CP) use case -- nothing prevents  
the CP serving the wrong data, right?  ie we don't prevent them  
impersonating us, but if we wish them to stop, we have the ability to  
stop them, yes?  this is what we're talking about?
dm: correct.

subodh: the charter is only for cert-b ased authn?  preiously...only  
recently added lifetime restrictions for certs...are we doing only  
that?  is the WG going to work on solns for the things that aren't  
presently addressed?
ys: we haven't discussed those from formal perspec, charter is about  
certs, <personal hat> if things can be added w/o client-side changes,  
then maybe -- client-side changes are out-of-scope (in proposed charter)

alexander mayrhofer: did u consider case for dnssec where u are  
signing a zone?  have u discussed dns zone signing as use case?

ys: we have discussed it a little bit, there was not enough intereset,  
out of scope for now

subdoh: do you wish to take ? on too?

ys: this is not wg yet.....the draft u refer to might mean client side  
changes and x509 tweaks and it is out of scope per proposed charter...


###
> Certificate delegation (Yaron, 10 min.)

* Certificate Delegation  
<https://www.ietf.org/proceedings/96/slides/slides-96-lurk-2.pdf>
[ yaron goes thru slides...]
wrt: draft-sheffer-lurk-cert-delegation-00

ys: on slide 3, notes that is proposing sending the priv & pub keys to  
CDN, would be nicer to use a CSR...
ekr: can send a CSR without a pub key
dkg: am not understanding this - what is the extra step of lurk when I  
already have ACME?
ys: it is the finishing the URLs for the REST protocol, btwn CDN and  
content-owner (CO). That is, the CO gets certificate via ACME, then  
shares certificate w/ CDN using lurk restful protocol
dkg: this is how you avoid changes to the client side ie CO doesn't  
become a CA?
ys: yes

slide 4: upon compromise (what to do)
slide 5: sec cons
ys: cdn could use acme to get itself cert(s) to long-term pose as the  
legit site
ted hardie (th): there is work in acme that may address this, please  
write a draft if you feel it is new work for acme and we're  
rechartering and may include it

ys: will wait for lurk (if created) to come up with a solution and then (?)

th: please dont wait [...?], raising these points to the mailing list  
would be useful

subdoh: somthing that would be useful is if u could req certs that are  
skewed towards past (?)
phb: this is why most short-lived certs [have issues?] due to clock  
skew -- you're not able to use the web pki unless ur clock is sync'd  
to [ntp] within a day...

ben schwartz: primary use for this is for users who are actually under  
attack, who use CDNs and are concerned that their keys at the CDN  
might be compromised. ppl in that position often use CDNs because they  
cant spin up enough infrastructure to fend off DDoS. maybe giving CDN  
restricted access to CA could be a better solution [...?]

ys: yes, delegating the authority to issue limited-time certs is  
interesting but more complex than what this proposes, but yes that is  
an option

dkg: wrt Cert Transp -- CT logs get larger with # issued certs, and so  
this will cause a CT log expansion... just something to be aware of....


###
> Protocol (Daniel, 10 min.)

* LURK-TLS Protocol  
<https://www.ietf.org/proceedings/96/slides/slides-96-lurk-3.pdf>

daniel(dm): this is a very early draft proposal

slide 4: ECDHE Security - signing oracle
ekr: ths is not correct -- the diff is the suffix is always under  
control of the edge server -- so, any tls 1.2 server exposes a signing  
oracle of first 32 bytes, plausible best case for lurk is the edge  
server has control of ....

dm: I'm coming to that in next slide...

slide 5: ECDHE Sec: cross protocol attacks

slide 6: ECDHE sec: cross prot attacks cont'd
ekr: thinks misunderstanding the issue, the concern is that he (edge  
server) forges a non-tls msg and signs it with the tls priv key -- it  
is not cross-prot between TLS versions, it is between TLS and other  
prots.  [ see discussion on-list ]
   what we are trying to do is harden the system against abuse by edge  
svr -- thinks this is a tough problem and ought to just accept that  
and admit signing oracle prob can be mitigated but not solved...

ys: charter is vague about this point because it looks like the  
signing oracle can be mitigated, but not be solved, so this room needs  
to decide whether partial oracle w/ caveats ... we are interested in  
such a solution [...?]



phb: cant see why tls uses ? sig and key exchange -- need to  
reengineer tls - shud not have signature in key agreeement...

subodh: [can do whole svr key exchange on part of content owner ?]

dm: well, what we are preventing is the 'leak' -- we need to make  
tradeoff between mitigation and centralization of control into the key  
server (KS) -- simply isolating the key is a significant problem

ekr: this proposal handles only ephmeral cipher suites, so, opening  
bid for this bof is to not break tls clients -- so what about TLS  
RSA-static clients?  you break them, yes?

rsalz: breaks zero clients because they all support ephemeral (?) does  
it have to be a client written in this century?

dkg: ...

ys: goto charter discussion....


###
> Proposed charter (Eric and Yaron, 10 min.)

* Proposed Charter  
<https://www.ietf.org/proceedings/96/slides/slides-96-lurk-4.pdf>
[ room reads proposed 2-page charter ]

ys: notes that "widely deployed TLS cipher suites" includes RSA w/BER  
format (?) due to wide deployemnt (?)




###
> Open discussion (30 min.)

tero kivinen: wrt widely deployed ciphers if it is only 2..3% some  
cdns might say it is ok to not support them...

eric nygren(en): might be ok to have specs talk about just two  
different servers playing roles rather than hard code the roles as CO  
and CDN...would be nice to keep out of scope tunneling thru the TLS  
connections...


phb: not to keen on this, we need to first agree on approach, [...]  
and remote key use. if you look at short-lived certs, it'd be better  
to recharter ACME with short-lived certs. there's also use cases eg  
sfwr signing...

stephen farrel(sf): we had this discussion (where?) and only use case  
folks have raised is the CDN one...

phb: if tied to tls, you're tied to tls "now", and if you do  
tls-future you may want to do remote use differently

dkg: am simpathetic with the goals, but not convinced that the gain  
and the engineering works will result in us ending up in a better  
position. no changes on the client side [...]
is not convinced the secret keys are more valuable than the content  
they are protecting, eg this could be used for surveillance in a  
std'zd fashion

ys: there are two existing protocols out there today that do what  
you're proposing (directed at dkg?)

ekr: ? wrt not changing client -- we can deploy large % of TLS client  
very quickly via browser update -- if the prot u deign leaves a  
substan % clients broken....need to figure out how big that % is (why?)

ben schwartz: looked at ssllabs.com, no version of IE on WinXP  
supports forward secrecy, so all IE users on XP (a lot in some  
countries) are in your category. it seems like we could get what you  
want to do using a one-call REST API. post key-pair to a REST URL, set  
up a cronjob, I'm done. worried there is to much work here,  
overcomplicated solution

rsalz: static RSA is impt, need to address it.  have servers in  
hostile lands (china russion virginia) and customers don't want to  
give those serers private keys...

martin thompson: I wanna hear from ppl, apparently they have a  
solution currently, so if there is just one person in the room who has  
this, we're done. (asks people to stand up if they do, did someone  
come forward?)

subodh: our use case is not the CDN use case, but the "we have  
server", technical aspects the same, but focusing on CDN use case may  
cause us ending up with a too specific solution. only thing that  
concerns me

jhild: do care about the container use case

andrei popov: we have use case where we have svrs in untrusted locs,  
but dont thing lurk soln for that, rather short term certs better, RTT  
btween edge svr & key svr adds latency, and where edge svr needs to  
authn to key svr, and key svr might be in untrusted loc...

ys: we will decide on those specifics if & when we have a working group...

erik nygren: while I work for CDN, primary interest is actually  
interactioon between our servers. even if it ends up not being used  
widely between different parties, [...]. we should work through the  
different cases and [...], so that other ppl working on the same thing  
don't cut themselves on the sharp edges

ys: if we stick to cdn use case, does that allow us to address tech  
issues well enough such that it covers other use cases you have in mind?

erig nygren(en): ?  contstrain to tls svrs in diff domains...?

?: from my point of view the restriction of (?)

thomas fossati: as long is simple enuff to impl is ok w/us

diego lopez: apart from CDN which is interesting case [...].  
addressing this in the scope of ? would make sense



mt: andrei reminded me of key point not yet addressed: reason you put  
edge svr in untrust locs is there's users there and want to lower  
latency -- is adding latency w/lurk reasonable then?

phb: the lurk part is only a small portion of interactions so won't  
overwhelm latency

sanja: even cdni ?   but cdn deleg is useful

sf: puzzled -- lots of folks said similar things last time but nothing  
occured on mailing list aftwards...

phb: unless u design lurk so it is tls-only, "it works" but if you  
generalize it, will break...

ys: ?  [something about it iwll be same scope...]


joe h: [agreed with a prior speaker]



phb: if CT can't deal with 360 certs per endpoint per year. the idea  
of having a franken(?)-group, (?). reduction of cert life-cycle is  
going to happen anyway

ys: mention cdn is because I  think of short-term cert -- my focus is  
the CDN case -- almost everything discussed has been about CDN -- tho  
it is somewhat different today....

phb: you got to choose an approach before you charter, you can't  
charter and then decide between two completely different ways of doing  
it. if you're going to propose a way of short lived certs (?)

sean leonard (jabber): with all of the private keys floating around on  
various services with the proposed LURK model, it would make sense to  
label or annotate private keys in a common way, to designate its  
intended use, or sensitivity. (These would be considered intrinsic  
properties of the private key, although they are not mathematical  
properties.) Perhaps common labels or attributes for private keys  
intended for remote-use (or for keys used for authenticating the  
untrusted entity to a LURK server) may make sense. Such common  
labeling might also help with identifying when to rotate keys out of  
service, for example.

dm: we are interested in this solution and (will?) use it for our  
customers (?)  -- preefer interaction with key server w/0 sort-term  
certs, do it every txn.  not much disc on mailing list, then if one  
usecase is addressed then others are also (in general)

ys: but the cipher suite isseus are affted by the use cases, eg the  
static RSA issue

dm: yeah, so we had the discussion on the ciphers, the one ppl thought  
were userful whatever the use case, so I think its a good question,  
but I think we adressed this question too. so the question might be,  
what cipher we want to support rather than what use case, because it  
depends on use case and deployment. so maybe the real question is  
which cipher

stephan emile (se): have a question regarding use case: is the CDN  
interconnection covered by this use case here?

ys: atm not

se: ?

ys: we saw very little traction, which is why theres only the basic  
CDN model on this slide (i.e. the charter)

mike bishop: (1) have to agree w/phb that shortlived certs will occur  
anyway, so maybe we should just rcmd this work to acme recharter (s)  
dont' need to supp widely deployed ciphersuites, have to support all  
widely deployed tls clients....

ys: that was actually the way I understood [...]. the wording is not  
very good, it'd include some weird algos as well as PSK which is never  
used on the open internet, so the intention is to support nearly 100%  
of clients and ?


ben schwartz:  I agree that short-lived certs are going to happen and  
are not a reasonalbe work item. use a cdn to get thruput advantage --  
there handshake latency and long-term connection latency bennies
running your own SSH (?) cerver, no availability advantage, if server  
goes down site goes down. in terms of security, (lurk?) compared to  
shortlived terms, revocation is shorter by a few days. window of  
benefit here is incredibly small

ys: based on what we heared there, i'm kind of two minds if we need to  
talk about use case and will ask ADs advice

sf: if the mailing list comes to life to discuss the other use cases  
maybe will change opion, right now not hearing we're ready to go fwd  
to a WG -- want to challenge that?  am proposing to not take the  
ususal set of hums...

ys: so....as one who added short term certs into the mix -- let's take  
'em out and then ask the room if what we're doing is 'remote signing  
for tls' does that make things better?


yoav nir: the working group shouldn't try to do that (what?, not sure  
if referring to w/ short-lived certs or w/o)

joehildb: thinks there's some edges here that need to be addressed,  
but doesn't need a WG

ekr: have a # props for having a key owner and a server and to arrange  
for the priv key to be on the edge svr -- sounds like it is a solvable  
prob [w/o a WG(?)]

?: yes

dm: the product already exists, so the question is whether we want to  
have just one verison, i.e. one standard?

rsalz: an alt proposal woon't meet akamai needs....we are most  
interested in the draft rsalz proposed....

ys: I said remote signing for TLS, dont think that excludes your  
proposal and certainly does not specify one protocol or draft


sf: is clear we are not forming WG today -- have further disc on the  
mailing list -- need to see if approp for rechartered ACME...

tedhard: rogue CDN server needs to be brought to ACME, during rechart  
phase in september, need to have I-Ds available to discuss -- current  
focus is to complete ACME v1 -- if there's delay  they are busy doing  
the latter...


###
> Open discussion (30 min.)

N/A


###
> BoF questions and wrap up (Eric and Yaron, 30 min.)

did not happen


n/a


end