Some bits snipped out...
On 10/17/2013 03:51 PM, [email protected] wrote:
>
>> Hiya,
>
>> Many snippets below...
>
>> On 10/15/2013 07:13 PM, [email protected] wrote:
>>>> Following up on my own point - not stylish but I think
>>>> in this case justified:-)
>>>
>>>> On 10/15/2013 12:41 AM, Stephen Farrell wrote:
>>>>> I don't
>>>>> see why we shouldn't be equally comfortable in saying "don't
>>>>> send cleartext" - *if* that's an IETF consensus position - as
>>>>> we have seen sending cleartext is also just broken when one
>>>>> consideres pervasive monitoring.
>>>
>>>> I guess this Washington Post story [1] that I saw this
>>>> morning would appear to provide a relevant example.
>>>> In that case, I would argue that the fact that cleartext
>>>> IMAP provides interop and is successful does imply that
>>>> some services somewhere will use that for large populations
>>>> that will inevitably (as we now know) be subject to
>>>> pervasive monitoring.
>>>
>>> What is this "cleartext IMAP" of which you speak?
>
>> I guess that's a fair comment - we don't know that they're
>> able gather to inbox data via IMAP due to it being sent in
>> clear, however that seems like a reasonable guess based
>> on the newspaper story which says that collection is done
>> by telcos that are "overseas" and assuming that TLS is not
>> busted for these services.
>
> Actually, it's exactly the opposite: Details from the article make it very
> unlikely that tapping into IMAP sessions is a significant source of data here.
> In particular, both the article and the source material make it very clear
> that
> this is primarily about address book information and only secondarily about
> actual message content. As I noted previously IMAP does not carry address book
> information.
So you're interpreting "inbox" to mean address book. To be
honest, I'm not convinced by that.
That's not how I read it - I do interpret inbox to mean
inbox, primarily mail accessed via imap or webmail.
> Additionally, there's the peculiar use of the term "inbox" rather than to
> email
> messages in general. IMAP provides access to all folders, whereas protocols
> like ActiveSync are used specifically to notify users of the presence of new
> messages in their inbox.
>
> And as I noted previously, the peculiarly isolated IMAP slide at the end is
> not evidence of anything because we lack context. For all we know it was
> included as an example of a case where collection is particularly difficult.
I agree it stands out from the others and is hard to interpret.
I don't think inbox is hard to intepret at all though.
>> Is there publicly available information about the deployment of IMAP
>> in terms of how many servers/services allow or disallow cleartext,
>> STARTTLS or 993? (To expose my ignorance, yes, I did assume that many
>> services still allow IMAP over 143 without STARTTLS in addition to
>> 993.)
>
> I doubt it, but even if such information were available it would be irrelevant
> to the matter at hand. Once more you're failing to take into account how email
> is actually deployed these days. For better or worse, email has seen a huge
> degree of centralization: The overwhelming majority of email now resides on a
> fairly small number of server farms. If your concern in protecting the
> accesses
> done by the majority of email users, those are the servers that count, not the
> one I have at home or the one operated by my (tiny) ISP.
Protecting the majority of email users is not the same issue. Its
also a fine thing but slightly different, see the end.
> The state of play for those servers is actually pretty easy to quantify, and
> I'll do that in a followup message.
>
>>>> When the numbers involved ("500,000 buddylists and
>>>> inboxes" collected on a "representative day" for just
>>>> one agency) are at that scale, then it seems to me that
>>>> one can fairly describe that as a failure in protocol
>>>> design and not solely as a bad deployment choice.
>>>
>>> And again I have to ask: What is the "protocol design failure" of which you
>>> speak?
>
>> Basically, having three flavours of IMAP (clear, STARTTLS and 993)
>> where one that just mandated use of TLS could arguably be simpler
>> and more secure.
>
> More on this later.
>
>> And note - I'm not saying this should've been
>> done years ago, I'm asking if in a similar situation today we
>> ought go for the one-with-security or the 3-flavoured approach.
>
> First of all, IMAP is a less than ideal example because if we were doing it
> today it would almost certainly be cast as a web service, and in that case it
> would simply be another thing in the https/http space.
>
> But if you ignore that little detail, I don't think you're going to like my
> conclusions of the lessons learned from IMAP in particular and email in
> general.
I don't dislike 'em actually. Most seem reasonable.
> My conclusionare that that most of the time the right things to do
> are:
>
> (1) Define the service on two ports, one with SSL/TLS covering the entire
> session and the other with no SSL/TLS option at all. (This makes the
> secure
> variant easy to deploying on connection-terminating load balancers,
> which I believe is one of the driving factors behind the use of port 993.)
That's the bit I'm questioning. I figure that if we could do
just the secure one, then we'd be done and that'd be a better
approach than having two. I also think that if we muck up and
do a pretend job on security then we end up with 3: plain,
pretend-secure and eventually-fixed-secure. That's happened
with more than IMAP.
I don't know if only doing the secure one in an IETF context
is at all likely though. History would seem to show that its
not. OTOH, it is true that doing the secure versions is much
better understood now and much more practical than it was a
decade ago, so I think its worth exploring.
>
> There are going to be a few cases, like protocols that inherently deal
> with nothing but highly sensitive data, where specifying the insecure port
> variant should not be done. But not many.
Yep. And some cases like DHCP where its just hard to do
meaningful (crypto) security.
>
> In contrast, there are *no* cases where the secure port should be omitted.
> I don't care if the protocol as designed only transfers public
> information.
> Protocols have a way of being used in ways their designers did not intend.
>
> (2) Use the DNS in some way to announce which port a specific server expects
> connections to be on.
>
> (3) Specify client latching semantics as a means to detect downgrade attacks.
>
> (4) Think very hard and carefully about how certificate naming issues should
> be handled, and make sure your specification of them is both clear and
> complete.
>
> (5) Think very hard and carefully about allowed/required ciphersuites and
> specify that very clearly and completely as well. (It is unclear to me
> whether this can be done for various classes of protocols versus on a
> case by case basis.)
>
> (6) Do not design your protocol so that compliant operation depends on the
> use of SSL/TLS extensions or ciphersuites that aren't readily available
> in the various widely used crypto frameworks. And if this means there's
> some ugly wart in the protocol, so be it. (Note that this doesn't mean
> you call for implementation of the hoopy perfect forward secrecy scheme
> du jour, only that you can't depend on it.)
>
> That said, I think an exception needs to be made in the case of
> ciphersuites that employ rc4. I think rc4 is sufficiently problematic
> that its use needs to be discouraged even though that may make
> compliance difficult or even impossible in some cases.
>
> (7) Since there are going to be choices to make when deploying, document
> those choices and their consequences clearly.
>
> (8) The current fixed security considerations sections we currently employ
> are inadequate given how rapidly this stuff evolves. The IETF needs to
> develop a means of formally amending security considerations with
> additional information without having to open the entire document up
> for revision.
>
> (9) Keep the use of normative references for purposes of specifying
> security to a minimum. And if this means some repetition of material,
> so be it.
I think I'd agree with almost all of (2)-(9).
> Conspicuous by its abence on this list is any mention of anything being
> mandatory to use, and as few things as possible that would translate into
> something being mandatory to implement. This is because I think history shows
> that these sorts of IETF pronouncements - in the email world at least - have
> been about as useful as pissing into a strong wind.
I agree about pronouncements. But I also think we might be able
to do better than we're doing now without 'em.
> More generally, persuasion beats being doctrinaire hands down. Not to toot my
> own horn or anything, but since Internet email a la RFC 821/RFC 822 deployed
> we've managed to make exactly one really substantive change stick on a more or
> less global basis. That was MIME, and we did it without a single mandate that
> it be used. Instead we made it as compeling as we possibly could and we also
> bent over backwards to make it as easy to deploy as possible.
>
>> (Ignoring the rest of the message and just dealing with that
>> would be fine from my pov if that helps.)
>
>>> I'm especially interested in the one the IETF has made that exposes
>>> buddy lists and address books.
>
>> Address books? When did I mention those? I don't believe I did and
>> if I did then that was in error. The buddylists things in the slides
>> are also presumably not IMAP related.
>
> That would be where you said:
>
> When the numbers involved ("500,000 buddylists and
> inboxes" collected on a "representative day" for just
> one agency) are at that scale, then it seems to me that
> one can fairly describe that as a failure in protocol
> design and not solely as a bad deployment choice.
>
> And as I noted above, you can't divorce them from inbox data collection nearly
> as easily as you seem to think.
As per above. I don't find that convincing.
>
>> Lemme try another way: if IMAP were a brand new protocol
>> today and given today's kit and network and what we've
>> learned, would we argue to define both an insecure and
>> a secure (but maybe not much used) variant or would we
>> be better off only defining one version that builds in
>> whatever we think is the right set of securiy features
>> and ensures that those are used (by not having the
>> option to not use 'em)?
>
> See above. Again ignoring the fact that IMAP wouldn't be done in remotely
> the same way if we were doing it today, the anwer is no, we'd almost
> certainly still want to have an insecure variant.
Why? Serious question.
>
>>>> (*) Yes, there's a bit of arm-waving there since one
>>>> can validly argue that the TLS ciphersuite that's MTI
>>>> for 3501 is still just a bit too hard to deploy as
>>>> one is supposed to get a server cert that the UA can
>>>> verify, which implies some management overhead. So
>>>> something slightly more easily deployed (and hence
>>>> not quite 3501) might really be needed. But *how* to
>>>> do MTU stuff could be a protocol-specific debate to
>>>> have after we concluded we had consensus for
>>>> more-than-MTI in some form. (Which we don't, today.)
>>>> But of course, a new IMAP security BCP doesn't have
>>>> to wait either (hint, hint:-)
>>>
>>> ... And that's a strawman. I've not heard and provider of any size make
>>> such an
>>> argument in many, many, many years. The fact of the matter is that secure
>>> IMAP
>>> *is* widely and successfully deployed, albeit in a way that the IETF did not
>>> intend and in spite of the fact that the IETF did bugger-all to make it
>>> easy to
>>> do.
>
>> Yes - I think that supports my argument - the existence of a
>> "pretend" security variant at day zero is damaging so we should
>> ask whether we ought just make the security mandatory to use
>> and end up with one version.
>
> On the contrary, what's damaging on day zero is having a specification for
> which compliance isn't practical for a significant fraction of implementors,
> deployers, or both. This is what happened in the case of IMAP, and the result
> was vendors ignored what the specifications called for and secured the
> protocol
> in their own way. (And security isn't the only example of this in IMAP.)
I agree that that happened and was damaging. I don't thinks its
at all contrary to what I said.
>
>>> And since only yesterday I was listening to a presentation that among other
>>> things covered the specifics of how a provider with 10s of millions of users
>>> handles this particular problem, I can state with some authority that the
>>> costs
>>> aren't that big a deal.
>
>> I don't get what you mean there.
>
> You claimed that there are valid arguments that the TLS ciphersuites that are
> MTI are too hard to deploy. AFAICT that claim is false.
I do think that the PKI parts are too hard to deploy. Not for
the larger MSPs, but it could be a good bit easier. Or maybe
you're the one person in the universe who thinks that deploying
PKI is a doddle:-)
>>> So I'm once again going to ask, "What's the goal here?". If the goal is to
>>> make
>>> the email of select group of cognescenti more secure that's one thing. It's
>>> quite another to talk seriously about improving email security for everyone
>>> else.
>>>
>>> If we're going to do the latter, I'm afraid that needs to start with a
>>> better
>>> understanding of what present-day email service actually looks like and
>>> where
>>> market trends are pushing it.
>
>> Better understanding is always good and the main goal here (at least
>> mine) is to make pervasive monitoring more expensive to the extent
>> technically feasible. Personally, I think there are things about IMAP
>> that could be impoved but I'm very skeptical that we can "solve" the
>> problem for mail in general. (Some others on this list are more
>> optimistic.)
>
> You're still not answering the question, at least directly, and I really want
> a
> direct answer. More expensive for whom?
Ah sorry. I think the goal here is to make pervasive monitoring
more expensive for anyone (govt or other) who wants to do that,
in cases where we think we can create a maybe significant enough
disencentive, but without making things harder for people who're
using protocols as designed. There will be some tradeoffs there
for sure, but in some cases if we get consensus for changes then
we might actually improve things for the normal users too.
The first part of that is new to the extent that we're dealing
with a new threat model. If we can do something for that, then
my hope is that we can improve general security and usabiliy as
well, since we've learned a good bit about that (or should have)
in the last decade.
> The vast majority of current and likely
> future email users, who seem perfectly happy to use the service
offerings of
> large ISPs and MSPs? If so, then any proposal you come up with needs
to done in
> a way that persuades those providers that making changes to their service
> offerings is the right thing for them to do.
That's fair.
S.
>
> Ned
> _______________________________________________
> perpass mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/perpass
>
_______________________________________________
perpass mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/perpass
