On Oct 15, 2013, at 1:26 PM, Stephen Farrell <[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.
>
> 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.
>
> With the 20-20 hindsight afforded, if IMAP were a new
> protocol, would we be correct to only have TLS as MTI as
> we currently do [2] or would the Internet be better
> if we *only* had port 993 and had TLS as MTU perhaps
> with anon DH or something (*) like that?
But with anon-DH you're not making those large populations less subject to
pervasive monitoring. You've only made it a bit more difficult, and not in a
way that is significant to the adversaries we're talking about.
You would get them better security if they were doing TLS with mutual
authentication, but that requires a lot of infrastructure, and you would
hesitate to mandate that even if IMAP was a new protocol. You added "perhaps
with anon DH" because you know what response you would get if you had said
instead "with mutual authentication and PFS".
Yoav
_______________________________________________
perpass mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/perpass
