[06:54:26] --- KMK has become available
[06:54:49] --- Melinda has become available
[06:58:16] --- andrewdmcgregor@jabber.psg.com has become available
[06:58:44] --- fanf has become available
[07:01:31] --- smb has become available
[07:01:41] --- WH has become available
[07:01:45] --- shima has become available
[07:01:52] --- artur has become available
[07:02:05] --- hartmans has become available
[07:05:24] --- faw has become available
[07:05:44] --- warlord has become available
[07:06:25] --- shep has become available
[07:07:42] --- dku has become available
[07:07:44] --- jishac has become available
[07:08:49] --- Ed J. has become available
[07:09:01] --- Ed J. has left: Logged out
[07:09:10] --- Ed J. has become available
[07:09:53] --- Ed J. has left: Disconnected
[07:10:45] --- ekr has become available
[07:10:57] <ekr> Anyone there?
[07:11:22] <andrewdmcgregor@jabber.psg.com> No scribe here, many listeners.
[07:11:24] --- alfredo.matos has become available
[07:11:39] <Melinda> I'm here (not there)
[07:11:40] --- Tsubasa has become available
[07:12:21] <ekr> I'm not super-excited about this terminology.
[07:12:22] <shep> knock knock
[07:12:49] <ekr> The property of not being able to determine that two transactions were performed by the same user is often called unlinkability.
[07:12:52] --- dumdidum has become available
[07:13:21] --- hartmans has left: Lost connection
[07:13:33] --- hartmans has become available
[07:14:23] <hartmans> ekr: Sure, but for what they are trying to do anonymous >> unlinkable seems reasonable
[07:14:27] --- Tsubasa has left
[07:14:28] --- warlord has left: Lost connection
[07:16:15] <ekr> I don't see how. it seems to me that this definition of anonymity implies unlinkability.
[07:16:26] <ekr> (or the second half "two acts" is irrelevant)
[07:16:27] --- warlord has become available
[07:16:27] --- nov has become available
[07:17:00] <andrewdmcgregor@jabber.psg.com> I agree, that definition of anonymity goes a bit far.
[07:17:31] <fanf> is there space between pseudonymity and unlinkability?
[07:17:52] <ekr> Well, you can get probabilistic linkability.
[07:18:30] <hartmans> Are they saying there definition does not imply unlinkability?
[07:19:34] <ekr> Well, their definition says that you can't tie back two events to A. Either that implies unlinkability (you can't tie event 1 to event 2) or it's redundant, since there's no more information than knowing that you can't tie event 1 to identity A.
[07:19:43] <shep> i recall some work 5 or so years ago that showed how to take the timing and size information of encrypted frames on a link and sort them (mostly correctly) into which frames were part of which connection.
[07:20:21] <shep> That makes me wonder if you watched timing information if you could construct a link between two otherwise unlinkable exchanges on the net.
[07:20:30] <andrewdmcgregor@jabber.psg.com> Which is such a subtle leak... hopefully we don't have to go that far.
[07:20:35] <ekr> Probably.
[07:20:36] <andrewdmcgregor@jabber.psg.com> You certainly could.
[07:20:43] <andrewdmcgregor@jabber.psg.com> It'd be a bit probabilistic.
[07:21:37] --- jeffa has become available
[07:22:01] --- FDupont has become available
[07:22:45] --- peetu has become available
[07:23:38] --- jhutz has become available
[07:23:39] <shep> ... so it will be difficult to make credible claims that a system or technique or protocol provides unlinkability
[07:23:51] <ekr> yes, very
[07:24:14] <andrewdmcgregor@jabber.psg.com> Who was that at the mic?
[07:24:16] <jhutz> I think I just figured out what the distinction is they're making wrt unlinkability
[07:24:46] <smb> shep: there have been a number of papers attacking anonymity protocols. It's really hard to do. You may be thinking of the paper on a Fourier analysis of TCP packet timing.
[07:25:41] <jhutz> Their definition of anonymity applies to the _identifiers_, not to the events. That is, they consider the requirement met if you can't tell just by looking at the identifiers that two events were performed by the same person
[07:26:16] <jhutz> So anonymity requires unlinkability of identifiers in a vacuum, but not full unlinkability of actions they perform.
[07:26:17] <shep> ... but perhaps the goal of "Unlinkability of identifiers" that Pekka has up on the slide is a reasonable goal.
[07:26:28] <jhutz> And I agree with ekr; I'm not excited about the terminology
[07:26:30] --- tlr has become available
[07:26:57] <jhutz> Yeah, I think that is a reasonable goal.
[07:27:08] <jeffa> name was something like Alper Yegin
[07:27:22] <andrewdmcgregor@jabber.psg.com> Ta
[07:27:33] <smb> Here are some papers on attacking anonymity schemes: http://portal.acm.org/citation.cfm?id=570689 http://www.cl.cam.ac.uk/users/sjm217/papers/oakland05torta.pdf http://freehaven.net/doc/e2e-traffic/e2e-traffic.pdf
[07:28:35] --- dthaler has become available
[07:30:04] <tlr> "you securely share a key somehow" is a strong assumption.
[07:30:16] <ekr> indeed.
[07:30:49] <ekr> i'm waiting to see how he's going to deal with ip address.
[07:30:57] <ekr> while still having routing work.
[07:31:42] <andrewdmcgregor@jabber.psg.com> Securely share a key WITHOUT a stable identifier, even during the exchange. That's hard.
[07:31:53] <artur> changing TCP ports is also a very strong assumption: what about two daemons on the same host?
[07:31:57] --- jgirao has become available
[07:32:13] --- Tsubasa has become available
[07:32:26] --- hsantos has become available
[07:32:30] <artur> andrew: you can have a long term key per identity which you try to hide
[07:32:40] <artur> (see GSM)
[07:32:49] <hartmans> You can losen requirements somewhat and for example do a DH-protected key exchange where only parties involved see the identifier. It depends on what you are protecting against
[07:33:09] <jhutz> Well, you could continuously rotate the host parts of IP addresses between a pair of networks. Of course, you'd have ordering issues
[07:33:19] <andrewdmcgregor@jabber.psg.com> Sure. Presharing is always possible to some extent.
[07:33:32] <andrewdmcgregor@jabber.psg.com> jhurts: hmm, yes.
[07:33:57] <ekr> this seems to me to be a rather weaker notion of anonymity than originally advertised.
[07:34:01] <jhutz> And certainly you could randomize ports between a pair of hosts, with the same ordering issue
[07:34:29] <jgirao> I was also thinking about a keyed lamport hash chain, couldn't this "help" the problem of the sequence?
[07:34:40] <artur> jhurtz: if you have two independent applications, i don't see how this can be done - what about conflicts?
[07:35:07] <jhutz> You do it in the network stack
[07:35:20] <ekr> i don't see the point of randomizing all this TCP crap. If you don't tweak the IP address, then the stream is trivially correlated.
[07:35:27] <artur> ah here we are :)
[07:35:36] <jhutz> true
[07:36:42] <smb> and what about the timestamps in the TCP header
[07:36:54] <tlr> (and what about the application-level content when you don't encrypt)
[07:36:57] <fanf> ekr: perhaps the IP addrs are randomized at each router
[07:37:20] * hartmans is puzzled
[07:37:29] <shep> ah, by "send ACK in both", he means not including the just received packet.
[07:37:47] <jhutz> You could randomize the IP addrs at each router (well, between each pair of routers). But continuous variation is still quite hard, and that requires state in the network which could result in a big outage if a router reboots
[07:37:48] <shep> i.e. throw the just received packet away, and send dupacks on both.
[07:37:50] <hartmans> When I approved this I thought it was about EAP identifier privacy, that sort of thing. Fairly well understood but requiring implementation guides.
[07:38:05] <hartmans> Nothing on the slides so far has been in the realm of things for which implementation guides are appropriate.
[07:38:25] <andrewdmcgregor@jabber.psg.com> Quite academic for the moment... Pekka admitted that.
[07:38:36] <ekr> Sam: totally agree.
[07:38:53] <shep> Pekka also mentioned possibly wanting to form an IRTF RG, and perhaps he's providing motivation for that now.
[07:38:57] --- justino.santos has become available
[07:39:04] <ekr> That's the only way I could see this work chartered.
[07:39:22] <andrewdmcgregor@jabber.psg.com> Lets see what the other proposals are.
[07:39:28] <jhutz> Yeah; this really sounds like motivation for an RG. It's not well-understood enough for engineering. IT sounds cool, though.
[07:39:29] <shep> perhaps someone should ask Pekka where he wants these thoughts to go....
[07:39:45] <hartmans> O, he's not talking about per-packet stuff, only changing things when you need to.
[07:39:45] <jhutz> And yeah, perhaps what Sam expected is later in the session.
[07:39:59] <ekr> Well, there's an *enormous* amount of research in anonymous communications (onion routing, etc.)
[07:40:00] <hartmans> Interesting. I wonder how much shim6+esp could get you.
[07:40:32] <hartmans> Where need to is based on trying to hide your long-term identity
[07:40:49] <andrewdmcgregor@jabber.psg.com> I think one of the points here is you can even hide from the peer. In other words, log analysis will buy very little.
[07:41:15] <smb> log analysis or packet analysis?
[07:41:20] <jhutz> either
[07:41:23] <andrewdmcgregor@jabber.psg.com> either
[07:41:33] <jhutz> That is, as a server, I don't know if two connections come from the same peer
[07:41:39] <andrewdmcgregor@jabber.psg.com> but especially logs
[07:41:41] <andrewdmcgregor@jabber.psg.com> yes
[07:42:19] <smb> packet analysis gives a lot more data -- thing of the clock skew-based fingerprinting
[07:42:44] <jhutz> thinking about timing hurts my brain, steve
[07:43:20] <smb> sure -- but what's the threat model? Who is the enemy?
[07:44:03] <jhutz> I'm not sure.
[07:44:21] <jgirao> maybe I misunderstood but, these IDs, if used for routing, won't you need a lot of state on the network?
[07:44:44] <jhutz> Yes, I think so.
[07:44:44] <artur> theoretically anybody but the party whom you share the keys with is a potential enemy
[07:45:10] <jhutz> That's not the only possible threat model
[07:45:38] <artur> no, but the most general, seems to me
[07:45:52] <jgirao> in case of mobility models, most of the times, you just don't trust people in the access network.. or is this too light?
[07:46:19] <jhutz> Well, it's not necessarily the case that there are keys to share. WRT anonymity, the enemy may actually be the peer
[07:46:55] <jhutz> Well, often you trust people in your home network more than people in the access network or in the internet core
[07:46:59] <ekr> this is making my head hurt. We should have the threat model first.
[07:47:07] <jhutz> who is at the mic?
[07:47:16] <ekr> Greg Daley.
[07:47:17] <jeffa> Greg Daly
[07:47:17] <dthaler> Greg Daley
[07:47:24] <ekr> Greg Daley :)
[07:47:29] <jeffa> :)
[07:47:55] <artur> jhurtz: if there is no trust between parties, then the question is very different, yes.
[07:48:37] <warlord> Hmm, as a server maintainer I WANT to know when a peer is connecting multiple times.. That way I can block them when they misbehave.
[07:48:43] <andrewdmcgregor@jabber.psg.com> Who's this?
[07:48:48] <ekr> greg daley?
[07:48:57] <warlord> Alper
[07:48:57] <andrewdmcgregor@jabber.psg.com> after greg
[07:49:08] <ekr> I just felt like saying greg daley,.
[07:49:15] <warlord> (can't read the last name)
[07:49:18] <andrewdmcgregor@jabber.psg.com> Ahh, ok.
[07:49:26] <artur> warlord: that's why i would say you have a trust with the client and that's what i would base anonymity on (anonymity against third party)
[07:50:19] <warlord> artur: I think we really need to hear the threat model, as EKR said. The rest is somewhat pointless to discuss until we understand what we're trying to protect against.
[07:50:41] <jgirao> if the identifier is routable, then you limit the amount of unlinkability you can achieve..
[07:50:47] <jhutz> except that anonymity usually means the party you are talking to doesn't know who you are, either. That's not always required, but you want it sometimes. And yeah, ==warlord
[07:51:08] <tlr> but if you are looking for anonymity against third party, how is this stuff superior to mixes, reply blocks, and encryption?
[07:51:19] <tlr> re warlord, +1
[07:51:41] <andrewdmcgregor@jabber.psg.com> Who was the last question? I'm not picking up names very well.
[07:51:51] <hsantos> Dave Thaler
[07:51:52] <jhutz> True. The anonymity set is bascially the set of hosts behind the same router. With IPv6 you get a big enough address space to maybe do something useful there; with IPv4 I'm not so sure
[07:51:53] <dthaler> me (Dave Thaler)
[07:51:55] <andrewdmcgregor@jabber.psg.com> ta
[07:52:08] <artur> jhurtz: it could be a question of security level - i might know who MY client in my client space is but i shouldn't know what his physical identity is
[07:53:01] <jhutz> True. You might have a client who is anonymous at the network layer but not at the app layer.
[07:53:21] <jhutz> You might also have a client with a pseudonymous app-layer identiy, which is actually _really_ common.
[07:54:14] <shep> as far as I am aware, nobody uses MIP, instead everyone uses VPN stuff.
[07:54:28] <ekr> That makes it very private :)
[07:54:41] <andrewdmcgregor@jabber.psg.com> Because MIP is so riddled with deployment hassle.
[07:54:44] <artur> right. that's how i see the stuff. that's why mutual trust does not distrub me. i suppose that the server really needs to know who is accessing to it. but it does need to know what provider i'm using, where i live, etc. and vice versa: my ISP obviously has some data on me, but he does not need to know that i'm customer x at the server X
[07:54:57] <jhutz> And yet I think we have 3 WG's dealing with various aspects of MIP
[07:55:18] * hartmans begins a rant
[07:55:21] <ekr> The technical term for this is "error 33"
[07:55:22] <andrewdmcgregor@jabber.psg.com> 3GPP
[07:55:38] <hartmans> It's all well and good for us to ask people to define a threat model up front. It's great when they can do that.
[07:55:55] <warlord> ekr: #define EDOM 33 /* Math argument out of domain of func */ ???
[07:56:06] <hartmans> But sometimes when designing a system, you just don't have that written down; you have some mechanisms and an intuitive feeling that they protect against the problem you want to solve.
[07:56:24] <warlord> I'm still not even sure what problem they're trying to solve.
[07:56:40] <jhutz> I'm fine with replacing "what is your threat model?" with "what problem are you trying to solve?"
[07:56:44] <hartmans> We as a community need to get better at dealing with that situation: inferring a threat model, working to see if that threat model is good enough, and pulling all that together with the evolving mechanism discussion.
[07:57:07] <shep> http://catb.org/~esr/jargon/html/E/error-33.html
[07:57:14] <hartmans> At the end, you do in fact need a single written agreed threat model. But I'm not sure we are being realistic in our demands for threat models up front.
[07:57:17] * hartmans end rant
[07:57:37] <warlord> hartmans: what about a fully fleshed out problem statement up front?
[07:57:55] <ekr> Somebody ask "if nobody uses MIP6, what's the point of this?"
[07:58:40] <jhutz> ekr, did they say "nobody uses MIP6" ?. If not, I think that question is inflammatory.
[07:58:44] <andrewdmcgregor@jabber.psg.com> Unfortunately, it's a mandatory part of 3G cellular, so it is deployed, and the regulators care about these issues within telco systems.
[07:58:59] <andrewdmcgregor@jabber.psg.com> Which is why the work goes on.
[07:59:13] <shep> I guess the question is will anybody ever use MIP6 in the Internet.
[07:59:14] <ekr> and on and on.
[07:59:20] <hartmans> warlord: When I'm doing design I often find my problem statement evolves along with the rest. I find my intuition is typically significantly ahead of anything I have written.
[07:59:23] <jhutz> What's a mandatory part of 3G cellular? MIP?
[07:59:27] <shep> ... and I would guess that the answer is no, it will never be used.
[07:59:39] <andrewdmcgregor@jabber.psg.com> MIP6 is part of 3G
[07:59:53] <shep> 3G != The Internet.
[08:00:07] <andrewdmcgregor@jabber.psg.com> But it's a major user of IETF protocols.
[08:00:22] <shep> (If I understand correctly, MIP6 is used internally within the 3G infrastructure.)
[08:00:46] <warlord> He says this is "without the VPN overhead" -- but I don't buy that conclusion.
[08:01:08] <andrewdmcgregor@jabber.psg.com> VPNs are usually very simple code, MIPv6 is not.
[08:01:12] <hartmans> Part of 3gp2 or all 3g?
[08:01:25] <andrewdmcgregor@jabber.psg.com> But many folks in this space assume the presence of MIPv6
[08:01:37] <andrewdmcgregor@jabber.psg.com> Who's at the mic?
[08:01:52] <warlord> can't read the nametag -- arms are crossed.
[08:01:54] <dthaler> Hesham Soliman
[08:02:02] <dthaler> is at back mike
[08:02:24] <warlord> I'm going to start yelling at people to state their names.
[08:02:26] <jhutz> the person at the front mic isn't speaking
[08:02:31] <jhutz> warlord, do it
[08:03:06] --- raeburn has become available
[08:05:17] <ekr> This is making my head assplode.
[08:05:44] <andrewdmcgregor@jabber.psg.com> mip does that
[08:06:05] <ekr> We *so* need onion routing,
[08:06:18] <ekr> thus guaranteeing that the Internet will never work.
[08:06:27] <andrewdmcgregor@jabber.psg.com> Full service HIP RVS servers everywhere could do that.
[08:06:28] <jhutz> The BOF description on the agenda page clearly is consistent with what they're talking about now and does not appear to be about EAP identifiers.
[08:06:29] <warlord> hey, onion routing works.
[08:06:44] <hartmans> ekr: How do you think we feel on the IESG when we get a load of L3VPN documents or MIP optimization?
[08:06:48] <warlord> c.f. TOR
[08:07:48] <jhutz> well, some of us didn't volunteer to be on the IESG :-)
[08:07:59] <hartmans> jhutz: I think my one sentence summary of what I expected was well rushed; EAP identifiers was overly constrained.
[08:08:25] <jhutz> Why does he write "bot" as if it's an acronym?
[08:09:40] <smb> warlord: did you look at the URLs I sent out? onion routing is not that easy to make secure....
[08:10:17] <jhutz> Perhaps, but this really seems to be about hiding a user's "long-term network-layer identity". That's meaningful wrt MIP; I don't know what else they mean it to include
[08:10:36] <warlord> smb: secure against which threats?
[08:10:36] <shep> (smb pops out of his chair)
[08:11:07] --- m.behringer has become available
[08:14:38] <andrewdmcgregor@jabber.psg.com> speaker is?
[08:14:43] <dthaler> Hesham Soliman
[08:14:49] <andrewdmcgregor@jabber.psg.com> thx
[08:20:06] <ekr> aren't bofs supposed to like not be all presentations and some discussion?
[08:20:46] <andrewdmcgregor@jabber.psg.com> Yep. I think the agenda is a bit backwards, but that wasn't obvious to start with.
[08:21:04] <ekr> well, it was as soon as we realzied that they were doing the threat model last.
[08:21:20] <jhutz> Not necessarily. A BOF is usually about the question "should we do this work", and spending much of the time on background seems appropriate to me
[08:22:12] <jhutz> OTOH, Sam's rant notwithstanding, if they think they _have_ a threat model, I think it is reasonable to ask for it to be presented before the things tghat attempt to address it
[08:22:53] <jhutz> What is "momipriv" ?
[08:23:21] <ekr> I think it's when you don't know who your mom is.
[08:23:27] <jgirao> mobility and multi homing privacy ?
[08:23:52] <dthaler> yes (from the title of draft-haddad-momipriv-problem-statement-01.txt)
[08:24:44] <artur> ekr: lol
[08:26:10] <andrewdmcgregor@jabber.psg.com> So spoof your MAC.
[08:26:29] <ekr> this is not exactly what I had in mind vis-a-vis threat model.
[08:26:49] <jgirao> I don't think it's that simple.. since you have to use different L3 ids per different L2 id (at least)
[08:27:34] <andrewdmcgregor@jabber.psg.com> Sure, you have to do a bit of messing around to actually help much.
[08:28:33] <jgirao> On the other hand, if L2 frames payload is encrypted, you can better layer the problems
[08:29:09] <andrewdmcgregor@jabber.psg.com> Indeed... even WEP helps some there.
[08:29:24] <jgirao> I wouldn't say WEP, since it's a group key
[08:29:47] <andrewdmcgregor@jabber.psg.com> Sure, but to be able to start correlating, you need to actually have it.
[08:30:03] --- raeburn has left: Disconnected
[08:30:32] <andrewdmcgregor@jabber.psg.com> That only helps if the malicious node is not part of the network in question.
[08:30:52] <jgirao> or hasn't been your neighbor for more than a week :)
[08:31:02] <andrewdmcgregor@jabber.psg.com> Sure.
[08:31:46] <smb> WEP had many independent mistakes. Group keying is one of them regardless of the other issues.
[08:31:54] <jgirao> what is really not so clear to me (especially now that we touch loc priv) when SEC touches architecture problems
[08:33:27] --- jhutz has left: Logged out
[08:33:47] --- jhutz has become available
[08:34:42] --- shima has left
[08:34:43] --- shima has become available
[08:36:28] --- nov has left
[08:36:45] --- raeburn has become available
[08:36:53] --- KMK has left
[08:38:14] <m.behringer> I thought mobile phones have also an ID?
[08:38:20] <ekr> well, that too.
[08:38:45] <m.behringer> Isn't that how they identified the London bomber in Italy? Same mobile, different SIM?
[08:38:49] <ekr> The fingerprinting technique was designed for anti-cloning for AMPS phones.
[08:39:00] <ekr> because they just broadcast the ESN in the clear.
[08:39:08] <m.behringer> ESN?
[08:39:19] <ekr> Electronic Serial Number.
[08:39:27] <m.behringer> thx
[08:39:30] <jhutz> Hm; I wasn't aware of that history, but radio fingerprinting is clearly possible.
[08:39:51] <ekr> It's not totally straightforward, but it is doable...
[08:40:17] <andrewdmcgregor@jabber.psg.com> Some 802.11 radios are capable of doing that fingerprint of their peers too.
[08:40:24] <andrewdmcgregor@jabber.psg.com> I have a few of those.
[08:40:35] <jgirao> some operators (vodaphone that Iknow) have this as a service... depending on the coverage, they can give something like a 15m error on a webpage map
[08:40:36] <ekr> you know which model #s?
[08:41:01] <andrewdmcgregor@jabber.psg.com> ST Microelectronics chipset, made by a company in Taiwan called Remotek.
[08:41:06] <ekr> thx.
[08:41:23] <jhutz> jgirao, I think you're talking about location, not fingerprinting
[08:41:45] <jgirao> yeap, I'm just saying that not only they have your location, they sell it to your wife :)
[08:41:52] <shep> radio transmitter fingerprinting has been done for all sorts of different radios. It is very difficult to build RF oscillators that run at exactly the same frequency and very hard to build PLL synthesizers that ring in exactly the same way, and difficult to build RF amplifiers that ramp up in power in exactly the same way.
[08:42:16] <andrewdmcgregor@jabber.psg.com> Exactly, and an OFDM radio can get at that data.
[08:42:24] <andrewdmcgregor@jabber.psg.com> If the right APIs are there.
[08:42:37] <shep> so if you have a receiver that sees enough information, no two transmitters appear to be exactly alike.
[08:42:55] <smb> precisely.
[08:42:55] --- WH has left: Disconnected
[08:43:06] <raeburn> What about building transmitters that can vary those parameters on command, even if not to specific values?
[08:43:28] <andrewdmcgregor@jabber.psg.com> The Remotek/ST cards can also do that to some extent.
[08:43:37] <jhutz> ==shep. Every component has variations in various characteristics, all of which lead to sublte but detectable differences
[08:43:59] <jhutz> Well, it's common to have transmitters that can vary frequency on demand :-)
[08:44:35] <shep> raeburn--- I dunno. It'd be a game of how accurately you can vary those parameters on command, and how accurately can the receiver measure those parameters.
[08:45:10] <jhutz> And you certainly could build amplifiers and other devices in which some components are adjustable. But even given that, there may be detectable consistencies.
[08:45:24] <smb> this is the security area -- we're used to that sort of arms race... but I suspect that here, the analyst will always win.
[08:45:30] <andrewdmcgregor@jabber.psg.com> I believe the transmitter will lose with present devices, but can win in general.
[08:46:20] <shep> jhutz--- transmitters that can very frequency on demand often use PLL synthesizers (which tend to ring a bit in frequency, as the PLL loop is not perfectly stable) or use some sort of direct digital synthesis (which will have different quantization noise that looks noticably different as the ratio between the frequency that it is generating and the frequency it is being clocked at varys.
[08:46:24] <andrewdmcgregor@jabber.psg.com> The ST radios have 17 DACs setting bias in their analog stages. There aren't enough bits of precision to win this game at present, but there's no fundamental reason why you can't beat a receiver at this game.
[08:46:27] <jhutz> winner vs loser oscillates in an arms race, by definition.
[08:46:41] <jhutz> The best we can do is keep the duty cycle mostly on the side of us winning :-)
[08:46:43] <hartmans> OK, so I'm all for evolving your threat model along with your mechanisms and designs.
[08:47:03] <hartmans> But, before you go presenting you should double check that there exists a threat model that is consistent to your mechanisms.
[08:47:34] <ekr> indeed.
[08:48:10] <hartmans> I see no such model here. The solutions are all over the map.
[08:48:55] <ekr> yah.
[08:49:51] <andrewdmcgregor@jabber.psg.com> Sam's question precedes any of what's on that slide.
[08:50:14] <hartmans> Someone want to discuss whether they understand the problem well enough?
[08:50:40] <tlr> I think they have their agenda backwards here.
[08:51:04] <ekr> sam: i think that may be your job. :)
[08:52:58] <shep> I don't think it is clear enough for me to hum either way.
[08:55:10] --- tlyu has become available
[08:55:26] --- sureshk has become available
[08:56:02] <jhutz> how can you decide whether to divide the work if you don't know what the work is?
[08:57:02] <jhutz> Figure out what the work is, then whether we should do it, _then_ how to divide it up
[08:57:10] <andrewdmcgregor@jabber.psg.com> If there are some things that are clearly part of it and relatively doable, why not attack them first?
[08:58:07] <ekr> well, because I don't think they actually know what those things are.
[08:58:46] <shep> jhutz---- exactly my confusion. I don't know what exactly he is proposing to have the WG work on.
[08:59:36] <jhutz> "guidelines on how to use existing protocols". To do what, I'm not sure. :-)
[09:05:41] <andrewdmcgregor@jabber.psg.com> Who is this?
[09:05:48] <dthaler> John Loughney
[09:06:54] --- danwing has become available
[09:08:14] --- danwing has left
[09:09:31] --- dumdidum has left: Replaced by new connection
[09:10:30] <shep> good point he (not sure his name) just made at the mic.... there will be no privacy pixie dust. Privacy probably needs to be designed into protocols from the beginning.
[09:10:43] <smb> quite often.
[09:13:53] --- raeburn has left: Disconnected
[09:13:55] <jhutz> So, did Aaron Falk know they were going to propose RG formation?
[09:14:16] --- tlr has left: Disconnected
[09:14:58] <jhutz> Why does he keep saying "IETF including IRTF"?
[09:15:34] <jhutz> Well, at least he's asking "should we do the work" before "how should we divide it up", sort of
[09:17:43] <andrewdmcgregor@jabber.psg.com> ekr: Those radios... I understand the capability exists, but I don't think the drivers to do it do.
[09:18:25] <shep> yeah, the IRTF is not run exactly like the IETF.
[09:18:40] <jhutz> No; the IRTF is not run anything like the IETF
[09:19:23] <smb> sure -- most poeple don't have the need to do RF fingerprinting.
[09:23:29] --- Tsubasa has left
[09:23:31] --- artur has left: Lost connection
[09:26:17] --- jgirao has left: Logged out
[09:27:03] --- smb has left
[09:27:17] --- jhutz has left
[09:27:21] --- justino.santos has left
[09:27:22] --- m.behringer has left
[09:27:25] --- FDupont has left
[09:27:29] --- warlord has left
[09:27:39] --- fanf has left
[09:27:41] <shep> the BOF has adjourned.
[09:27:46] --- hsantos has left: Logged out
[09:27:46] --- jeffa has left
[09:28:12] --- shep has left
[09:28:30] --- tlyu has left
[09:28:38] --- alfredo.matos has left
[09:29:35] --- faw has left
[09:29:43] --- peetu has left
[09:29:57] --- jishac has left
[09:30:19] --- andrewdmcgregor@jabber.psg.com has left
[09:35:16] --- dthaler has left
[09:35:30] --- hartmans has left
[09:39:47] --- Melinda has left
[09:44:54] --- shima has left
[09:45:37] --- dku has left: Disconnected
[09:56:15] --- dthaler has become available
[09:56:16] --- dthaler has left: Disconnected
[09:56:31] --- dthaler has become available
[09:56:33] --- dthaler has left: Disconnected
[09:56:54] --- dthaler has become available
[10:03:00] --- raeburn has become available
[10:06:50] --- raeburn has left
[10:09:57] --- ekr has left: Online
[10:10:03] --- shima has become available
[10:13:46] --- dku has become available
[10:17:54] --- dthaler has left
[10:26:29] --- dku has left: Replaced by new connection
[10:26:30] --- dku has become available
[10:26:39] --- dku has left
[10:29:20] --- shima has left
[10:29:32] --- shima has become available
[10:29:52] --- endoh has become available
[10:31:25] --- endoh has left
[10:34:06] --- nov has become available
[10:54:27] --- nov has left
[11:05:07] --- WH has become available
[11:06:11] --- shima has left
[11:06:11] --- shima has become available
[11:10:36] --- WH has left
[11:33:23] --- sureshk has left
[11:53:27] --- shima has left
[11:53:27] --- shima has become available
[12:23:04] --- shima has left
[12:39:42] --- artur has become available
[14:23:12] --- artur has left: Disconnected