XSF Discussion - 2014-01-16

hey Guys. Just want to hear if its ok to book a hotel room for one of my friends though the discount?.. Do we have enough for everybody then?

If they're attending the summit I don't see why not.

If they're not, it seems more dodgy.

he is not XSF.. and cant make it to the summit. He'll be there for FOSDEM

Kev: thats alright

Kev: No problem

I didn't give an answer.

Ohh I thought you said it was dodgy

I'd see what Dave/Ralph say :)

what that ever means

Dodgy/uncertain.

;-)

Ok

just wanted to hear your oppion

I think there are people going just for the summit, so in practical terms if he's going just for FOSDEM, it sounds like there should be rooms.

Kev: so its ok to give him them link?

See what Dave/Ralph think.

I have no authority here :)

Kev: Thanks!

Steffen Larsen, I'm not against using our discount for people not attending the summit, if they're XMPP related folk. If they aren't at all, then I don't mind them using the discount *later* - after most people are booked.

dwd: ok thats all fair.

http://www.keepcalm-o-matic.co.uk/p/keep-calm-and-encrypt-your-im/ anyone?

dwd: The guys is a sysadm. - one of my friends.. not directly XMPP related. So I guess I wait untill all have booked

dwd: Dave, how do we/I know when all people have booked?

Steffen Larsen, We don't. :-) Florian can watch the numbers though.

dwd: ohhh..

Steffen Larsen, Using the entire block is actually a good thing; gives us more bargaining power next year.

dwd: true true

Steffen Larsen, And of course it doesn't cost the XSF anything.

dwd: even better

dwd: BTW what did we agree about the dinner? was it saturday or?

Saturday, usual place and rules.

Steffen Larsen: you mean you don't read the logs here?

So XSF Members and XSF Dinner sponsors only.

cool

ralphm: sorry no

dwd: yes i know

.

oops

dwd: keep calm and order those shirts ;)

keep calm and federate?

hmm

ralphm, Yeah, it's not quite right, I agree.

http://www.keepcalm-o-matic.co.uk/p/keep-calm-and-federate--1/

(I'm spending too much time in inkscape these days, it seems)

Keep Calm and Use XMPP might work better with the lightbulb. (Or Use Jabber, mind)

Or KEEP CALM and JABBER SECURELY?

Just to check, we don't feel that Keep Calm And... has been overdone as a meme, do we?

I want to play the security card a lot, because this seems to be the right bandwagon to jump on (and we have a legitimate claim to a seat on this bandwagon)

I keep having ideas like "Let's chat about trusting servers" pop into my head, but I don't think they really tell the story.

"Trust your provider. Host IM yourself." or something?

I'm thinking along those lines.

Or "Keep Jabbering with those you trust" or ... something.

Kev, I think, BTW, that the meme has been so overdone it's almost meta.

"Talk about federated security"..

In TLS we trust

ha ha

dwd: I do think that ... and encrypt your IM works for FOSDEM

I'm reminded about that quote of Woddy Allen's quote about masturbation - "Don't knock it, it's sex with someone you really love."

Haha

"We trust in the Federation"

I've made myself giggle :)

but people might think that we mean e2e

dwd: classic Woody

Why does no-one like my Star Trek joke? I don't believe for a moment that you're not sufficiently nerdy :p

Kev, Other than I did "Federation: Not just for Star Trek" a year or two back?

http://www.juxtapost.com/site/permlink/b15477f0-f5df-11e1-8de6-fba9fc1c5f14/post/bye_bye_robot_poster_the_federation_needs_you/

dwd: I don't remember that at all.

I do

My wife is suggesting singing "I'm XMPPY, I'm XMPPY, I know I am - I'm sure I am - I'm XMPPY!"

I'd be happy to reserve a slot for her at the Lounge.

Live entertainment is something we didn't do much about, still

(She also suggests a school choir singing it. Obviously well in-tune with current tech thinking)

wow that could be cool

Perfect. Let me know which day/time.

Just thinking about the encryption stuff - I think we need to be a little careful with the message as there may be a number of people (especially hardcore techies) in the 'you mean you weren't already?' camp.

*nod*

That has crossed my mind a few times, but actually I haven't seen anyone react that way yet

I think it's just something to be sensitive to

After all, the web is far less encrypted than XMPP is

Exactly

As is email.

We just need to make sure the message is positive

and in the background get our house in order.

Ash, I think we need to ensure we're being honest, open, and seeking improvement.

And the message is: "we are raising the bar even further and making sure it works" ;-)

basically it comes down to good configuration (not lazy about certs / DNS etc) rather than something inherently wrong with XMPP's core design.

dwd: I'm not saying we shouldn't be honest, but we just need to make sure the message has the right spin on it.

and keep pointing people to xmpp.net to test their sit.

site

simon and winfried: definitely :)

simon, RIght. We can discuss how we've held strong-auth interop tests (including CRLs etc) several years back; it's now a case of ensuring deployment, not even implementation.

Definitely. I was just worried that people might hear the message as 'we're starting to encrypt communications' rather than 'we're phasing out unencrypted communications'.

@Ash: it more like: "We are phasing out all but the most secure configurations" ;-)

even better!

winfried: well, we're not able to enforce authentication... so i don't think saying this is a good idea

Geez - winifried is an excellent marketer. I'm nominating him to write xmpp.org content.

simon: who are you?

ralphm - I believe we've met at the odd XMPP event before.

How can I be sure it's you?

Because Simon says… he's Simon.

That's how you play the game.

until xmpp.org does cert verification or DANE, you can't.

simon, That won't help.

simon: using anonymous.jabbix.com is the other extreme, though

short of using corkscrew and some socks5 tunneling, I'm behind a crappy corp fw.

simon, That's what 3G is for. :-)

what's the preferred XMPP client on android these days?

xabber doesn't work on newish Prosody, but jTalk might be OK.

I want to say Xabber, but I can't use it

Yaxim, but it doesn't do MUC yet

dwd, it doesn't? Why?

MattJ, Because it breaks.

(because it has some issues and development seems stalled or at least invisible)

Yaxim is actively developed, supports XEP-0198 and Carbons

https://github.com/redsolution/xabber-android/issues/264

Completely open-source, and MUC is coming soon

ralphm, nice

it doesn't work on "newish Prosody"? I don't think we've ever had a release that would accept unescaped ampersands...

MattJ: I don't think this particular bug is something related to Prosody at all

MattJ: I did a c2s tcpdump for it, and decoded it with my server's key

Fancy

fippo, you are right, we can't centrally 'phase out' anything in the XMPP network, but the current campaign is as close as we can get

I suppose in the future you can't do that anymore, right?

In any case, I would not go as far as calling XMPP secure, as it has many facets

:-) temporally disable FS

winfried: I assume in the future, clients will require that?

point taken

I though the idea was to create a 'jabber' network of public xmpp servers which enforced encryption. i.e. you can run an xmpp server and do whatever you like, but to interface with the 'jabber' network you need to enforce encryption rules. Although I may have missed a whole bunch of discussion somewhere.

phasing out is perhaps the wrong way to view it. But being able to connect to some servers will mean you need to get your own server configured correctly.

so anyway, besides heckling simon a bit, I agree with Ash' earlier point

buddycloud.org /com already reject servers with invalid certs.

simon: and without encryption, too?

:) no - all s2s is encrypted.

so you can't use your imaginator.com address

that's still google :) but the new buddycloud server uses DNS discovery so you can run one alongside a google apps domain #thanks-lloyd.

simon: yeah, I knew that the domain was with Google

simon: what, you mean you have two different servers listening for the same domain and you use some DNS trickery to make buddycloud choose the non-google one?

Buddycloud is magic!

magic is cool, but I hope I misunderstood

there is a difference between encryption and authenticated encryption in terms a what attacks it protects you against

To be fair, BTNS mitigates a set of attacks that are a proper subset of those mitigated by authenticated encryption.

ralphm: buddycloud server still does disco lookups, but if there's a specific SRV record it'll use the result of that to direct it to the other server. No magic - magic sucks.

It still seems a bad idea to have two different servers at the same address

I.e. if this is a special case for servers that are not up-to-spec (like Google's), I don't like it at all

If I misunderstood, please elaborate, though.

It suggests there's no commonality between a buddycloud server and an XMPP server, at least.

Its a special case for people who can't install a buddycloud component on their xmpp setup

so we run another xmpp server with the buddycloud component connected and use that

Lloyd: While I admire that stand point, it seems to me that this solution breaks the network.

how does it break the network?

By connecting to other servers based on something outside of the XMPP realm itself

simon, You're offering XMPP based services using a protocol that's no longer interoperable with XMPP?

Using XMPP to exchange data between components is breaking network? I must have misread a XEP somewhere.

simon, Well, it sort of depends on whether you're thinking that introducing a new SRV records etc is actually still XMPP. An unmodified XMPP server wouldn't connect, right?

The server isn't modified at all. I think maybe something has been lost in the text description.

What does the SRV lookup?

(for the buddycloud discovery)

the buddycloud component. It still uses DISCO however.

Yes exactly

So when is the SRV thing happening and why?

And what will it actually try to resolve?

If I do disco against imaginator.com and see there's no buddycloud component I do an SRV record check which tells me that there's a buddycloud component sitting at channels.imaginator.com and to talk to that.

buddycloud runs as a component and components talk to eachother using XMPP. buddycloud components can optionally fall back to using a SRV lookup in the case of a domain not running their own XMPP server.

As I said, I want to be wrong about this and would be happy if buddycloud is pure XMPP

channels.imaginator.com is still running as a component on an xmpp server.

Lloyd: So what you're actually saying isn't anything about SRV. Just that even if there's no advertised service, it'll try to connect on a default domain as if it had been advertised?

So it is really a fallback on channels.domain

IMHO, the notion that I have to do everything to do with one domain through one server is a wrong assumption. Far better to use DNS delegate services for domains than bottleneck everything through a single server (or cluster).

ralphm yes, disco+ so to speak (probably a *really* bad term)

simon: There's nothing that suggests that you should be using one server for everything.

kev it'll try and connect on domain anyway, if no advertised service will see if there's a DNS hint.

simon: you may disagree and actually implement things in the background, but just doing something else entirely protocol-wise doesn't seem proper

if there's no dns hint, well other service doesn't run buddycloud :)

Kev: my understanding too.

blah.doomsong.co.uk could be on the moon, and have no link to doomsong.co.uk other than S2S.

I understand that you have to work around servers (like Google's) that you can insert disco records on

Ralphm: not sure I really understand your concern.

simon: Because you're making something simple sound like you're re-inventing the wheel.

simon: well, the description of what was happening initially sounded really horrible

If you said "If there isn't a service in disco for the domain, we'll try channels.domain anyway" it would be much less scary.

simon: now I understand better I'm milder in my judgement

Misleading is the enemy of good, and all that.

Don't think I claimed that this was rocket science. Just a nice way to host instances outside of their XMPP domain.

*ahem* "maybe something has been lost in the text description" …. or gained as the case may be :)

simon: arguably, nothing in XMPP is rocket science. But I dread having incompatible systems referred to as XMPP

like, say, whatsapp

ralphm, I think by your definition, if you haven't been following Buddycloud, it took that route long ago

It uses XMPP purely as a transport mechanism nowadays

MattJ: I haven't followed it closely, true, and I knew there was a mechanism for finding servers if you're on a hosted service, but the description of doing something else because of a special SRV record sounded really bad

MattJ: turns out it has nothing to do with SRV in principle

ralphm: bc is designed to run as a component on any XMPP server that understands 114. Finding other servers can be done using disco for the corresponding remote component. This DNS discovery is used in the situation that there isn't a buddycloud component discovered.

isn't that what I said?

the initial explanation was worse

and also, what if there is no SRV record for channels.domain but there's a server listening on port 5269? Does that work?

You mean on the A or AAAA record listed for channel.domain?

yes

ralphm: yes, standard disco is the preference, DNS is the fallback

see this is the confusing bit

So, normal 6120 §3.2 behaviour?

if you say 'channels.' is the fallback, *then* it is clear

You don't need to talk about DNS in the case, even though it is involved

it falls back to looking for a SRV record - if that isn't there then it gives up.

so that's unlike normal lookup for s2s

who said it was s2s.

Well, that's what you were implying earlier, as I understood it.

You did, implicitly, when you said you were doing standard XMPP.

component to component if you want to name it.

There is no XMPP component to component protocol.

component1->server1->server2->component2

So, S2S, then.

thanks MattJ.

So if there's a XEP that says how components should be delegated, I'd love to see it.

XEP-0114 is a server side protocol, totally irrelevant for inter server communication in any sense

but since there isn't I don't think applying the entire s2s stack to discovery makes sense.

the entire s2s stack isn't much is it

it is setting up streams between servers

Note that I am trying to be very exact here

simon: A component is, to the outside world, just another server.

while Google is one big distributed beast posing as many servers

why would a buddycloud component need care about s2s if it knows what remote component to talk to? All it cares about is discovering the remote component and connecting to the right XMPP server.

s2s-wise you can't tell the diff

simon: It doesn't talk to a component. It talks to a server.

simon: I don't care how buddycloud's organised internally

I only care about the edges, in this case s2s

Similarly, protocol-wise, there's nothing to prevent having MUC rooms and user accounts at the same domain

(say, ralphm@jabber.org and jdev@jabber.org)

Prosody allows it :)

ralphm:so if a domain doesn't have a buddycloud server (perhaps it's hosted on bc-hosting-cloud.org - how should the lookup work?

apparently 'try channels.bc-hosting-cloud.org' instead

without any additional changes

really?

I assume you know how it works

that seems to do away with a lot of the correctness of using SRV to say this is the service that runs X.

wat?

once you are ready to try channels.domain, you try dns srv, if missing dns a and aaaa and [ort 5269

like s2s always does?

you are assuming that you know the name of the remote component running buddycloud. If I want to follow ralphm-on-buddycloud@ik.nu, (and ik.nu doesn't run a buddycloud server) my buddycloud component now has to assume that all buddycloud servers are channels.ik.nu.

Sure.

correction that the remote server is channels.ik.nu

Then try the hosts and ports for s2s as per 6120 §§ 3.2.1 – 3.2.2.

why would it try channels.ik.nu and not other-service-name.ik.nu?

remember if you user@domain.com on buddycloud not user@buddycloud-component.domain.com

https://github.com/buddycloud/buddycloud-xep/blob/master/buddycloud.xml#L483

(XEPign now)

simon: because you just defined it would, if no other service was disco'd on ik.nu

fair enough. I just don't think it's a great idea to hardcode expected hostnames into code.

it's not like we expect to connect to XMPP.domain.com as a fallback for discovery.

simon, you misunderstood. You're defining a fallback for your BC disco.

As far as I understand, you defined this as channels.domain

I explained that you don't know the component on the remote server that offers buddycloud services.

Does this help http://imgur.com/4y2BTvd ?

Exactly how does DNS lookup say it should talk to channels.capulet.lit in this case, and which part of this diagram is resolving it? Meaning: what DNS query is made? Is this happening in the buddycloud component, and will that component use the found name in a regular fashion, that is: ask montague.lit to route it to whatever is discovered?

_buddycloud-server._tcp.imaginator.com. (code for the curious: https://github.com/buddycloud/buddycloud-server-java/pull/114)

simon: now it is clear. Thanks.

ralphm: :)

simon: I'm not sure why it took this long to get to this :-(

You should've pointed to this commit immediately. Would've saved a lot of discussion.

simon: I also think this was the feared answer

I do like some parts of this solution (the indirection), but not the fact that it is done as a SRV record pointing to a server that talks (some form of) XMPP

How does that work with IDNA?

A PTR would be better suited, a la DNS-SD

Without DNSSEC (and we'll be without DNSSEC for a while), isn't relying on DNS for this insecure?

intosi: agreed. DNS-SD is great for this

waqas: I wanted to leave DNSSEC out of this particular discussion

it is rather orthogonal

(but it is insecure ;) )

MattJ: what ever, man

Well, there is no trust here if there's a third-party able to send DNS responses to the client

MattJ: live a litte. On the edge, man!

waqas: the same thing happens with normal s2s or c2s traffic. We're talking about how buddycloud solves a particular discovery mechanism for servers that you don't control, but you do 'control' the DNS

ralphm: That's not true, in normal s2s or c2s traffic, assuming TLS is in effect and certs are verified, you can't pretend to be someone you are not. In this case, the entire trust model is only DNS, nothing else.

ralphm: So if I as an attacker can hack DNS, should I be able to pretend to be the buddycloud server of any arbitrary user?

ralphm: "SRV record pointing to a server that talks (some form of) XMPP": once you have discovered the remote bc component, you are using the s2s connection between the two xmpp servers. We can debate the inscurity of the DNS system if you want but it seems that the road to solving that is well defined with DNSSEC deployment.

waqas: in this implementation, yes. If he used PTR records, it would be better

simon: no, because the discovery doesn't do fallback on A/AAAA records

how is fallback magically secure?

simon: intosi is right in saying you should have used PTR here. Then, you'd point to the domain where a service is hosted, and then do the *normal* s2s stuff

(the key here is *domain* v.s. server)

My point is that at no point is the original server asked over a secure channel whether the buddycloud server is valid for that host. I'd much prefer e.g., a POSH like approach where the discovery is over https, not insecure DNS

waqas: yes, that can't happen for something like Google Talk

waqas: Because in this scenario that server does not support that

waqas: that's why it is there to begin with

For sane servers, this isn't needed at all.

POSH is an alternative, sure

So.. is there a server which gets to be /the/ gtalk buddycloud server?

I don't see how this solves the gtalk issue, gtalk isn't going to change their DNS

waqas: if you host your domain at google

waqas: you control your own DNS, but not the server implementation

waqas: so you can't rely on disco

Ah, I see, in which case you can do POSH too, no?

waqas: yes

And POSH in that case would be secure, as opposed to DNS? :)

Anyway, I'm dragging this on, ignore me

waqas: imho the correct solution is for the XMPP community to make a concerted effort on getting good DNSSEC support in all servers (I like Proosdy's progress on this).

POSH will remain much easier for quite a few years I think

simon: that still makes your solution suboptimal

waqas: I think that it would be good enough if you did PTR records and have proper certs at the server being pointed too

(-o)

If your DNS is poisoned, how does PTR help over SRV?

Indeed, I don't see how PTR is any more secure

I am not talking about DNS poisoning. It is orthogonal to SRV being a bad choice for pointing buddycloud to another domain

which was the discussion originally

waqas: it's not about being more secure, it's about using the appropriate record the the job.

Ah, k

Yes, POSH or DNSSEC would make the whole thing more trusted. But just for this particular problem, having an DNS PTR (even if the DNS might be compromised) with proper certs at the endpoint is good enough, I think.

ralphm: From a security perspective, or without considering security?

from a security perspective

Certs being proper does nothing to establish that serverA trusts serverB with this service

Side note: by using PTR, the local buddycloud component must go through a bunch more roundtrips for disco-ing the right component.

simon: no. The component will just use the name returned and use that as the remote component domain.

I'm confused still. So the SRV is looked up, and returns IN SRV 5 0 5269 buddycloud.imaginator.com, right?

The XMPP server the component is connected to will route it.

What does the local component route to here?

dwd: no the actual machine

dwd: so, say, 'spock.imaginator.com'

I'm not sure which domain is used within XMPP at that point, by the way

ralphm, I'm using the example on the pull request.

ralphm, Exactly. Does the component use "buddycloud.imaginator.com", and therefore that *too* has SRV records, this time for xmpp-server?

If you want to use it as an alternative to disco, that's the only way it should work.

OK, but what do the port numbers mean? ANd what's the handling for multiple SRV?

dwd: that's why I suggested SRV was the wrong record, and PTR should be used instead.

There's also a URI records somewhere

Zash, NAPTR? Yay!

Zash, Actually the URI variant is U-NAPTR, pronounced "Unapointer", a bit like the Unabomber, and almost as scary.

:)

And again introduces priority and weight.

Although it's probably more appropriate than using SRV.

intosi, Anything other than CNAME will have some case of multiple records.

intosi, CNAME, mind, seems like a reasonable option.

dwd: I was thinking of https://tools.ietf.org/html/draft-faltstrom-uri-06

Could be.

CNAME or PTR are both more appropriate for this than SRV.

I also assume that 'buddycloud' is not a registered service at IANA. I don't recall if PTR has that restriction.

but SRV does

Although resolvers might try to get the A or AAAA of a CNAME automatically.

^resolvers^resolver libraries

buddycloud-api is registered with IANA. If needed, a SRV could be. (https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=buddycloud)

ah, cool

simon: but I would definitely switch to something based on PTR

or at least not using SRV like it is now

(buddycloud-api is used by mobile clients needing to find the HTTP endpoint for API calls)

does *that* use PTR?

TXT by the looks of things.

I'd say a U-NAPTR would be more appropriate ;)

ralphm: TXT as defined in the DNS-SD RFC https://groups.google.com/d/msg/buddycloud-dev/ww0yjdwRuNY/Qf7930KxG7MJ

Ah, the iPod RFC.

dwd: hah!

The format actually makes a lot of sense for describing how to connect to remote services.

You've read it too, huh?

simon, Yes, it's a sane protocol. Just a real shame that it didn't go through the IETF standards process, and most of the edits seemed to be updating Apple product names.

They had working implementations before writing the spec. Shocker!

Yes... So?

dwd: looks like it is going through ietf https://tools.ietf.org/html/rfc6763

simon, Oh, so it did eventually go through standards track. It was originally going to be Informational. But the Appendix G, "All Apple product names I can think of" is still there.

simon: I like implementations before writing specs. I don't like reinventing stuff that already has established solutions. Apple is notorious for just doing whatever pleases them.

IMHO it's a good spec. Don't know why we're talking about Apple here.

simon, The IETF developed Zeroconf and a slew of supporting tech, and Apple developed DNS-SD instead. And eventually specified it with Appendix G.

simon, Most of the edits to the spec for the past few years were to update various Apple product names in Appendix G, and not to do anything else with the protocol.

simon, Any changes were rejected because they'd already deployed, of course.

simon, I agree that DNS-SD is a good spec. So was Zeroconf, but Apple effectively destroyed that one.

dwd: hm? I thought DNS-SD built on Zeroconf, I don't know the history much

No, parallel development. Apple was involved in both IIRC.

They're *very* similar.

oh

dwd: you mean the old link local name resolution drafts?

I can't make out the difference from the wikipedia page

"local link multicast name resolution"

The differences are small but incompatible, according to Appendix G.

oh, but that's Microsoft's stuff, right?

Yeah, isn't there a Microsoft one too

LLMNR, what simon mentioned

Which one is mDNSSD then?

mDNS an DNS-SD are two things

mDNS is for doing DNS on lans

with .local

and multicast

right

hence the m

seems like there was a lot of unhappiness about the Link Local Multicast Name stuff: http://www.ietf.org/mail-archive/web/ietf/current/msg37393.html

I so wish that more things supported mDNS and DNS-SD

So happy that my Ubuntu laptop can find my printer at officejet.local

Unfortunately, support in Android is non-existant

I SSH between my boxes at home with .local addresses exclusively

Android music strategy is currently "send everything over bluetooth" which seems rather daft.

wait huh?

unless I missed a new app that lets me stream to my raspberryPi via wifi.

I use ChromeCast, but yes, that space is still a bit of a mess

(ralphm: one thing that Zeroconf solved nicely on the Apple side was announcing music recivers via Bonjour/Zeroconf/mDNS)

although UPnP also builds on stuff like zeroconf/mDNS/DNS-SD

UPnP, the SOAP-over-HTTP-over-UDP thing?

simon: indeed, my Rhythmbox announces itself as Ralphonics and Apple devices can play from it

visa versa is horrible because of Digital Restrictions

Zash: soon over XMPP

Zash: you are going to liason, right?

Yes, let me control port forwarding in my router with XMPP please!

port forwarding is so ipv4 :)

Simon: open ports in your IPv6 firewall. Same stuff, different proto.

My router has Port Forwarding → Basic IPv6 → bunch of forwarding stuff

my router has openwrt. Job done.

simon: how is that relevant?

simon: the idea is that there is a standard protocol for modifying firewall settings

While UPnP might be horrible in some respects, at least there's something

Ralphm: I totally get that.

Zash: I was being serious about the liason thing

ralphm: There's a Port Control Protocol being developed, with less SOAP iirc

PCP, really?

ralphm: Huh, to who where?

Zash: http://mail.jabber.org/pipermail/members/2013-December/007496.html

Did that involve NDAs?

intosi: https://datatracker.ietf.org/wg/pcp/

Oh, there's an {rfc 6887} already

Zash: Port Control Protocol (PCP). D. Wing, Ed., S. Cheshire, M. Boucadair, R. Penno, P. Selkirk. April 2013. (Status: PROPOSED STANDARD) http://tools.ietf.org/html/rfc6887

I was chuckling about the acronym.

Naming protocols after drugs and all.

Zash: there's still some discussion on the extend of NDAs here