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?
The latter approach is certainly now far more likely to
be tractable than it was in 2003 (when RFC3501 was done).
Maybe its time we do that.
Cheers,
S.
(*) 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:-)
[1]
http://www.washingtonpost.com/world/national-security/nsa-collects-millions-of-e-mail-address-books-globally/2013/10/14/8e58b5be-34f9-11e3-80c6-7e6dd8d22d8f_story.html
[2] https://tools.ietf.org/html/rfc3501#section-11
_______________________________________________
perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass
