Subject: Re: Semantics of HTTPS

From: Mark Nottingham <[email-masked]>
Date: Thu, 13 Sep 2012 15:06:24 +1000

I haven't seen any more discussion of this. 

Being that both the TLS WG Chair and at least one security AD have both unambiguously said that it should be considered an e2e protocol (please correct if I'm wrong), we return to the original question --

Should we state that the HTTPS URI scheme implies end-to-end security (i.e., between the user-agent and the origin server)?

Regards,

On 26/08/2012, at 11:51 AM, Eric Rescorla <[email-masked]> wrote:

> On Mon, Aug 6, 2012 at 3:39 PM, Adrien W. de Croy <[email-masked]> wrote:
>> Anyone here from the TLS WG able to comment on whether there are plans to
>> combat MITM in this respect?  It's interesting to see the comment about
>> recent TLS WG rejection of support for inspection.
> 
> As TLS WG Chair:
> 1. As Stephen says, the TLS WG saw a presentation about explicit support
> for proxies and there was very little support in the room for that idea. This
> isn't to say that some future version of this idea would not be accepted,
> but there are no current plans in this area.
> 
> 2. RFC 2818 was a TLS WG item, so any updates to that would really need
> to be done by the TLS WG.
> 
> -Ekr

--
Mark Nottingham   http://www.mnot.net/

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 13 Sep 2012 15:30:40 +1000

For tracking: http://trac.tools.ietf.org/wg/httpbis/trac/ticket/383

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 13 Sep 2012 07:47:57 +0200

Hi Mark,

On Thu, Sep 13, 2012 at 03:06:24PM +1000, Mark Nottingham wrote:
> Being that both the TLS WG Chair and at least one security AD have both
> unambiguously said that it should be considered an e2e protocol (please
> correct if I'm wrong), we return to the original question --
> 
> Should we state that the HTTPS URI scheme implies end-to-end security (i.e.,
> between the user-agent and the origin server)?

I have thought a bit about the arguments made in favor of this and my
opinion has evolved on the subject. I think that we should probably keep
the https scheme as "end-to-end" so that the user is sure about this,
but in this case we'd need another scheme for the https from proxy to
origin server that browsers would switch to for a given site when the
proxy would refuse access. Basically it would look like this :
  - user types https://forum.example.com/ in his browser
  - proxy says "NAK, switch to insecure mode if you want"
  - browser asks "Proxy can't let you go there without inspecting contents,
    do you agree to let it see the contents you're accessing ?"
  - if the user clicks YES, then the browser uses the hop-by-hop scheme for
    every attempt to access https://<this site> and makes it quite clear
    (eg: by changing the color of the URL bar).
  - if the user clicks NO, then no access is performed.

I think it can be a bit complex to implement in browsers but they're already
handling per-site certificate exceptions, so I don't think it would be
something very different.

And the benefit of the alternative scheme is that non-browser clients could
easily be configured to make use of it (eg for automatic software updates,
etc...).

Regards,
Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 13 Sep 2012 05:49:55 +0000

In message <[email-masked]>, Mark Nottingham wri
tes:

>Should we state that the HTTPS URI scheme implies end-to-end security 
>(i.e., between the user-agent and the origin server)?

Given the current hostile actions in the certificate-space, I think such
a statement should be footnoted with something like:

	Please notice that "end" in this context merely means "where
	the SSL/TLS session terminates".  Only proper handling and
	examination of the involved cryptographic keys can provide
	assurance that the other "end" is where it claims to be.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 13 Sep 2012 09:30:31 +0100

Hi Willy,

> but in this case we'd need another scheme for the https from proxy to

Do you mean another URI scheme?

That might be a way forward since it'd allow both ends (UA, site)
some choice in whether they'd allow middlebox snooping.

>   - user types https://forum.example.com/ in his browser

But that uses the https URI scheme, that we just agreed is
defined to have e2e security properties. I'm confused now.

> something very different.

Asking the user if they approve of a middlebox "seeing" their
traffic seems fairly broken to me really. Why would we expect
that'd make any sense to users?

Cheers,
S.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 13 Sep 2012 18:52:37 +1000

> some choice in whether they'd allow middlebox snooping.

I really think a new scheme is a non-starter here...

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 13 Sep 2012 10:19:28 +0100

> I really think a new scheme is a non-starter here...

Tend to agree. That's why Willy's mail confused me.

S.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 13 Sep 2012 13:23:32 +0300

> that'd make any sense to users?

Someone would need to run usability tests on such interactions, but this is somewhat better than the certificate issue screens that we all know and love. 

With those you get a message like "You have asked Firefox to connect securely to www.example.com, but we can't confirm that your connection is secure"

In most cases the information in this message is correct, but it's not a good indication of whether there is really an attack or whether the site administrator is just lazy. 

In the case of an explicit proxy the message can be very definite: There is a proxy called "sslproxy.example.com" that wants to decrypt your traffic. All passwords, CC numbers and personal information will be visible to this proxy. You should never accept this with an untrusted proxy. Accept/Deny?

The difference here is that the attack is definitely happening. Of course this message cannot tell the user whether the middlebox is scanning for malware, phishing for credentials and credit cards, or looking for subversion. I don't think the data we have on the certificate issue screens (that users treat them as barriers to be overcome) will definitely apply to such messages.

OTOH I wouldn't want us to standardize protocols (including my own proposal) that lead to such interaction before someone does perform a usability study to see if users will just click through or not.

Yoav

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 13 Sep 2012 12:23:35 +0200

> Do you mean another URI scheme?

Yes, which would be just for the browser, not for web sites.

> defined to have e2e security properties. I'm confused now.

This is e2e, the user asks https for e2e.

> that'd make any sense to users?

Exactly for the same reason right now we ask them if they still want to
connect to a site with an invalid certificate chain. Either they accept
a lower security level (eg: to consult forums when looking for some info)
or they refuse it (eg: to connect to their bank).

This is a way to let the user decide what is done with his connection and
to ensure that "https" in the URL bar always means e2e security.

Regards,
Willy

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 13 Sep 2012 19:39:36 +0900

> Yes, which would be just for the browser, not for web sites.

I'm not exactly sure I understand this. If the browser shows it in the 
address bar, then users will copy it, and use it on other occasions. 
Also, web developers will copy it and use it. Of course, most of that 
would be accidental, not on purpose.

On the other hand, I can't see much use in using it on purpose. Surely, 
no web site in their right mind would want to use it, because it 
essentially says "we are secure, but don't really think we need to be". 
Intranet applications wouldn't need to use it either, because for their 
own stuff, companies have easier ways to verify that there are no 
viruses,... around.

So all in all, an URI scheme doesn't seem to fit here. To me, it seems 
more like a case for a separate indication in the browser (a lock with a 
different color or a half-broken lock or some such, better ideas welcome).

Regards,   Martin.

---

From: Karl Dubost <[email-masked]>
Date: Thu, 13 Sep 2012 06:49:14 -0400

Le 13 sept. 2012 à 06:39, Martin J. Dürst a écrit :
> I'm not exactly sure I understand this. If the browser shows it in the address bar, then users will copy it, and use it on other occasions. Also, web developers will copy it and use it. Of course, most of that would be accidental, not on purpose.

Somehow, it doesn't matter (aka be accidental or on purpose), there is no border. If something is public and implemented, it will be used. A new scheme that would be active only on one side doesn't work.

-- 
Karl Dubost - http://dev.opera.com/
Developer Relations, Opera Software

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 13 Sep 2012 20:59:06 +1000

We're getting off track here -- this issue is about the semantics of the HTTPS scheme, in the context of HTTPbis, not potential future work.

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 13 Sep 2012 21:02:18 +1000

> 	assurance that the other "end" is where it claims to be.

HTTPS isn't specific to TLS -- that's just one way to provide the semantics of the scheme. 

What you're saying is more like implementation notes -- useful, but probably doesn't belong in the spec.

Cheers,

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 13 Sep 2012 07:40:26 -0400

I think that the parentheses need to disappear:

HTTPS URI scheme implies end-to-end security between the user-agent and the
origin server

End-to-end is meaningless unless the specific ends are specified. From a
security point of view the ends that actually matter are usually people and
organizations rather than machines.

I am not sure that the term user-agent is right though since we use HTTPS
for Web Services that have no users involved and I am not sure how the
qualifier origin helps on the server. By definition a server is a
destination.

-- 
Website: http://hallambaker.com/

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 13 Sep 2012 13:50:49 +0200

On Thu, Sep 13, 2012 at 08:59:06PM +1000, Mark Nottingham wrote:
> We're getting off track here -- this issue is about the semantics of the
> HTTPS scheme, in the context of HTTPbis, not potential future work.

OK but it was a proposal to address some people's concern that "https"
means "end-to-end" to people while currently at more and more places
this is not true anymore.

So the idea was to address this specific concern (which is a UI concern
in my opinion) by proposing a different scheme in the browser.

It looks like it's not a good idea in the end considering some of the
points that were made.

Going back to https, PHK is right that ends should be clearly defined,
at least to the user. In my opinion, https could be end-to-end where
one end is the local proxy. All we're dealing with is a matter of trust,
which is not a technical thing to debate on but a user choice.

If my browser tells me "You asked me to securely connect to this site,
but the proxy refuses. I can only securely connect to the proxy which
will securely connect to the site, and will be able to see and modify
all your exchanges on your behalf. Are you sure you still want to connect?"
then I know what I'm going to decide based on which site I want to visit.

The technical point is if we permit the secure end to start at the proxy,
then we need to ensure that what is announced to the user is what is
going to be performed.

Regards,
Willy

---

From: Carl Wallace <[email-masked]>
Date: Thu, 13 Sep 2012 08:03:29 -0400

>which is not a technical thing to debate on but a user choice.

This gets more complicated where mutual auth is employed and the
destination server does not want to authenticate the proxy, i.e. e2e
authentication.  It'd be nice to have a means of allowing a client to
issue a (short lived) proxy certificate to the proxy to use when
authenticating to the destination, enabling the destination server to
authenticate the client by checking the last non-proxy certificate in the
path.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 13 Sep 2012 15:45:05 +0200

On Sep 13, 2012, at 12:39, "Martin J. Dürst" <[email-masked]> wrote:

> "we are secure, but don't really think we need to be".

Security is not a binary thing.

There are historical reasons why we only have a binary flag to express security policy in a URI.

It is not quite clear that the URI is the right place for expressing security policy.
We are developing out-of-band mechanisms to express security policy that attach to the URI (e.g., HSTS).

Where we continue to put policy into the URI, the following things seem to be pretty much cast in concrete:
-- a different scheme means a different namespace (so you can't change the policy separately from changing the resource as well),
-- the https scheme is used both by people, where we have achieved some basic awareness and consensus about its meaning, and in a programmatic way,
-- the latter is largely broken in practice (e.g., see the recent brouhaha about Apple in-app payments),
-- the wide deployment in a user-visible fashion means that we have to curate the scheme with a dominant objective of avoiding security-relevant surprises.

So the question is less "what should be the semantics", but "how can we evolve the semantics without breaking too much".
It seems clear to me that the conservative thing is to stick with a narrow "end-to-end" understanding for https://

More interesting to me right now is how HTTP over TLS *should* be used in programmatic usage.
We are about to copy over the present unsatisfactory status quo from https to coaps, and I'm deeply concerned about that.
What part of the security policy should be encoded in the URI, what should be out-of-band, and what are the preferred mechanisms to deliver that out-of-band information securely?  E.g., how does HATEOAS obtain its security stance?
This question probably goes beyond the current charter of this group, but it would be worthwhile to look at the bigger picture.
It is probably impossible to do this for both the programmatic (web-services, M2M, ...) and user-visible domains, so I'd start with the former, very well knowing that there is some overlap.

Grüße, Carsten

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 13 Sep 2012 09:47:01 -0400

> authenticate the client by checking the last non-proxy certificate in the

-1

That would not be 'nice' at all.

I think we need to take a step back and talk about requirements here. In
particular, the 'client side proxy' is driven by an intercept requirement.
If people want to have a man in the middle modifying, storing, filtering,
censoring or otherwise involving itself in the protocol that is an
intercept requirement.

Lets not beat about the bush talking about 'proxies'. That only leads to
confusion as we have server side proxies as well as client side and those
have very different semantics and trust issues.

A very common implementation for server side is to have an SSL accelerator
box as a standalone component in front of a server. That has implications
for the protocol as it means that the HTTP layer cannot expect to see any
information from the SSL layer unless we define an explicit mechanism for
carrying the information from one layer to another. But it does not change
the trust model as hitting an SSL accelerator box owned by Google that is
talking to a Web server owned by Google is the same thing as far as
trusting Google goes.

Client proxies are a completely different beast because in the typical case
you have a user of the browser and an operator of the proxy and the two are
different entities and so you have issues of notice, knowledge and informed
consent (all of which are topics people have whole conferences on).

I see the following approaches as possible:

1) Do nothing

Ignore the issue completely, let parties work around the infrastructure as
deployed without making allowance for the requirement.

2) Attempt to disrupt

Attempt to design the protocol so that the intercept requirement cannot be
met in any circumstance. This is actually the traditional IETF approach.
The risk here is that people create their own work arounds and loopholes
and then demand that infrastructure supports it and the systems that result
do not provide for informed consent.

3) Provide a comprehensive mechanism that is conditioned on informed
consent.

If we decide that preventing intercept is possible the next best outcome is
to enable intercept but only with informed consent.

If we want to support that particular use case we have to have the client
delegate its whole process of trust evaluation to the accepted interceptor
and at minimum constantly inform the user that this has occurred. We may
also decide that we want to inform the service that the user is connecting
to that an intercept has occurred.

---

From: Carl Wallace <[email-masked]>
Date: Thu, 13 Sep 2012 09:58:24 -0400

From:  Phillip Hallam-Baker <[email-masked]>
Date:  Thursday, September 13, 2012 9:47 AM
To:  Carl Wallace <[email-masked]>
Cc:  Willy Tarreau <[email-masked]>, Mark Nottingham <[email-masked]>, Stephen
Farrell <[email-masked]>, Eric Rescorla <[email-masked]>, "Adrien
W. de Croy" <[email-masked]>, "[email-masked] Group"
<[email-masked]>
Subject:  Re: Semantics of HTTPS

> Attempt to design the protocol so that the intercept requirement cannot be met
> in any circumstance. This is actually the traditional IETF approach. The risk
> here is that people create their own work arounds and loopholes and then
> demand that infrastructure supports it and the systems that result do not
> provide for informed consent.
> 
> 3) Provide a comprehensive mechanism that is conditioned on informed consent.
> 
> If we decide that preventing intercept is possible the next best outcome is to
> enable intercept but only with informed consent.
> 
> 
> delegate its whole process of trust evaluation to the accepted interceptor and
> at minimum constantly inform the user that this has occurred. We may also
> decide that we want to inform the service that the user is connecting to that
> an intercept has occurred.

So you'd sacrifice e2e authentication.  That's one way.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 13 Sep 2012 13:30:26 +0000

>but the proxy refuses. I can only securely connect to the proxy which

Insert here: "claims it"

>then I know what I'm going to decide based on which site I want to visit.

In practice I expect browsers will grow some kind of "always trust
this proxy" checkbox, and that it will become an obvious attack vector.

>then we need to ensure that what is announced to the user is what is

Precisely.

One thing that worries me, is that there may be more than one proxy
in the chain that wants its fingers in the pie (dept, bigcorp, govt.)
and the notice/accept method needs to cope with that.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 13 Sep 2012 10:30:49 -0400

On Thu, Sep 13, 2012 at 9:58 AM, Carl Wallace <[email-masked]>wrote:

> Farrell <[email-masked]>, Eric Rescorla <[email-masked]>,
> "Adrien W. de Croy" <[email-masked]>, "[email-masked] Group" <
> [email-masked]>
>
> If we decide that preventing intercept is possible the next best outcome
> is to enable intercept but only with informed consent.
>
>
>

I did not state which of those choices I would take, I merely stated that
those are your choices. The choice that people seem to be 'choosing' here,
e2e security with MITM client-side proxies doth not exist. It is a
contradiction in terms.

It is possible to have e2e authentication without e2e confidentiality. But
TLS is really not designed to address that use case as they began with
confidentiality and added in integrity as an afterthought after Alan
Schiffman and I broke SSL 1.0. Mutual authentication was an afterthought on
an afterthought.

What I am trying to push people towards here is to face the decision they
are making. If you want to put a proxy in the middle of the communication
and look at the packets then it isn't going to give e2e confidentiality, if
you want to allow the proxy to modify the packets then you haven't got e2e
integrity or authentication.

Those criteria are by definition.

If people want to argue that those cases should be supported and can
explain how notice, knowledge and informed consent can be achieved then we
can start a discussion about how to achieve them.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 13 Sep 2012 15:56:21 +0100

> 3) Provide a comprehensive mechanism that is conditioned on informed

I'm not at all sure that this option is even feasible for https.

There is a 4th option: leave the e2e semantics as-is and write an
RFC called "HTTPS MITM considered harmful" that explains the
issues and trade-offs and says why we don't want to standardise
that (mis)behaviour.

S

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 13 Sep 2012 11:22:54 -0400

On Thu, Sep 13, 2012 at 10:56 AM, Stephen Farrell <[email-masked]
> wrote:

> issues and trade-offs and says why we don't want to standardise

Isn't that what I proposed in 2?

I would be willing to contribute to/work on that draft.

Option 3 is certainly possible but I would see it as a separate browser,
lets call it PANOPTICON, for some reason all caps seem appropriate. This
would be something that enterprises could install on their internal
networks in environments where the intercept requirement applied.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 13 Sep 2012 15:30:37 +0000

In message <CAMm+Lwi-CYPbEXDucjSVM273LKkprBMY=[email-masked]>

>> issues and trade-offs and says why we don't want to standardise

Is it "misbehaviour" when mandated by law in supposedly civilized societies ?

Is it "misbehaviour" when security concious organizations or organizations
under legal mandate to record all communications want to do it ?

Better to standardize, and let the user know they have limited privacy,
than the current "we're to holy for this" attitude that forces people to
fudge certificates and leave the users with no clue to the privacy
invasion.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 13 Sep 2012 16:33:37 +0100

> Better to standardize, and let the user know they have limited privacy,

That's the thing. Its not better for all the options I've seen
so far anyway.

S.

---

From: Carl Wallace <[email-masked]>
Date: Thu, 13 Sep 2012 11:34:24 -0400

On 9/13/12 11:30 AM, "Poul-Henning Kamp" <[email-masked]> wrote:

>In message 
><CAMm+Lwi-CYPbEXDucjSVM273LKkprBMY=[email-masked]>

+1

---

From: Martin Thomson <[email-masked]>
Date: Thu, 13 Sep 2012 09:04:28 -0700

> There are historical reasons why we only have a binary flag to express security policy in a URI.

There are usability reasons as well.  Though I concede that it's not
clear that it actually aids usability in any meaningful way.

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Thu, 13 Sep 2012 23:46:22 +0000

------ Original Message ------
From: "Stephen Farrell" <[email-masked]>
To: "Phillip Hallam-Baker" <[email-masked]>
Cc: "[email-masked] Group" <[email-masked]>
Sent: 14/09/2012 2:56:21 a.m.
Subject: Re: Semantics of HTTPS
>issues and trade-offs and says why we don't want to standardise

"misbehaviour" in this context is a subjective opinion.

I think that pretty much amounts to sticking our heads in the sand.

If it's considered so harmful, why is pretty much every proxy vendor 
implementing it.

And is it more or less harmful than the harm caused by viruses, or 
browser hijacking sites which use HTTPS, for which we'd otherwise have 
no defence.

I don't know that it gets anywhere trying to make everyones' decisions 
for them.  We argue why would anyone want to have their https traffic 
inspected, and assume that noone in their right mind would ever want 
that for any reason, even if the alternative was no access at all.  I 
propose you wouldn't actually have to look very far to find people who 
would trust their company enough to proceed to facebook or google 
search trusting that it was being scanned for malware.

You can't avoid a requirement to trust something.  Trying to avoid it, 
or pretending the requirement isn't there is IMO what causes security 
and trust problems in the first place.

Adrien

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 14 Sep 2012 01:44:13 +0100

Hiya,

> "misbehaviour" in this context is a subjective opinion.

(mis)behaviour != misbehaviour. The parentheses were meant
to signal that we appear to have a somewhat rough consensus
about that. But I reckon we do have rough consensus to not
standardise a TLS MITM, and I suspect that is likely also true
for an HTTPS MITM. The process of developing and last-calling
a BCP with such a title is in any case the IETF way to figure
that out.

> If it's considered so harmful, why is pretty much every proxy vendor

One might also ask if any banks whatsoever are asking for proxies
to do this. Are any? If not, or if almost all are not asking for
this, then I think we ought all recognise that attempting such a
so-called "trusted proxy" thing is controversial.

And then there's the issue that I at least have not seen any
proposed solution that doesn't have more downsides than
upsides. Feel free to show me yours in the form of an I-D.

> browser hijacking sites which use HTTPS, for which we'd otherwise have

Are you saying that all desktop AV offerings are "no defence"? Seems
like an odd proposition.

> for them.  

Huh? Tone-down rhetoric time?

> We argue why would anyone want to have their https traffic
> would trust their company enough to proceed to facebook or google search
> trusting that it was being scanned for malware.
> 

Hmm. I  doubt that the lack of a MITM is significant *cause*
for "security and trust problems."

Overblown arguments on either side here IMO weaken the
overblown arguer's position.

S.

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Fri, 14 Sep 2012 01:15:32 +0000

------ Original Message ------
>(mis)behaviour != misbehaviour.
>

ok, I view (mis)behaviour as a superset of misbehaviour.

I still think it's opinion.

As long as we view MITM as fundamentally evil, we will fight it instead 
of accepting it.

As long as we fight it, it will be done poorly.

Because whether or not the IETF likes it, customers want it, and 
vendors will supply it.

IMO we can do it better if we accept the legitimate need and design for 
it, rather than fighting it.

>The parentheses were meant
I agree it's controversial, and has difficulties.

But just because it may be difficult to cover all scenarios, doesn't 
mean we should not attempt to cover any.

>Are you saying that all desktop AV offerings are "no defence"? Seems
no AV is perfect.

Customers like gateway malware scanning.

>Huh? Tone-down rhetoric time?

I was referring to your prior comment:

"Asking the user if they approve of a middlebox "seeing" their
traffic seems fairly broken to me really. Why would we expect
that'd make any sense to users?"

I took that as proposing there is no point asking people for a 
decision, and therefore we should make it for them.

>for "security and trust problems."

it's possible that lack of a properly thought out way to allow 
legitimate scanning of HTTPS has resulted in a worse situation than if 
it had been designed for, since now we have a bunch of MITMs, and no 
clients moan, and no servers know that the client is intercepted.

>overblown arguer's position.
agreed.

Adrien

---

From: Roberto Peon <[email-masked]>
Date: Thu, 13 Sep 2012 19:08:08 -0700

On Thu, Sep 13, 2012 at 6:47 AM, Phillip Hallam-Baker <[email-masked]>wrote:

> <snip>
100% agreement that we must pick one of these.

-=R