Re: IETF mail server and SSLv3

[John C Klensin <[e-mail]>]

--On Friday, February 05, 2016 09:30 -0800
[e-mail] wrote:

>> The point of eating the dogfood is process improvement. Not
>> to get used to the taste. And the point is lost if we then
>> create our own special dogfood.
> 
> I completely disagree, but that's beside the point.

I don't know if my reason for disagreeing is the same as Ned's,
but I've always thought the point of eating the dogfood is to
improve the technical quality of our standards and protocols by
promoting a better understanding of how they do (or do not) work
in actual operational practice.  Process improvement seems to me
to be only slightly more relevant than teaching one's favorite
cat, goldfish, or elephant to enjoy the dogfood or consider it
nutritious.

I wouldn't think that was worth taking the time to say except
that each of these proposed changes has potential costs, costs
of the discussions we need to have before making them, costs to
either make changes or live without them, costs to people who
are thereby denied convenient (for them) access to things we
claim are public and generally accessible.  I think that, as
long as the IETF claims to be about engineering a production and
very large-scale network rather than engaging in utopian
thinking of various sorts, those costs have to be justified (or
not) by serious discussions of what we expect to accomplish (and
why we expect that) and by presentation of threat models and how
the changes will mitigate against those threats.  

This conversation seems to be about how newer methods are better
than SSLv3 and therefore we should get rid of the latter.
Well, as long as clear text fallback is available and works
efficiently (and I think Ned's suggested maximum two-minute
delay is, indeed, a maximum) I guess I don't care.   But, for
those who think this is about privacy and its promotion, that
then makes the question one of whether SSLv3 is worse than plain
text, not only whether it is worse than an appropriate version
of TLS.   It could be worse in either practically or symbolic
terms, but that goes back to goals and threat models.

> The issue at hand is whether or not to disable the use of old
> ciphersuites in the IETF's use of STARTTLS in SMTP.
> Irrespective of the reasons we have for doing that, John's
> point was and is that it can adverse effect on our ability to
> reach everyone who wants to participate. 

And adverse effects on our claims of complete openness.

> This effect can be mitigated to some extent by your choice of
> SMTP client software and how you configure it. To that end
> it's important to understand what options are available and
> what the consequences are of their use.

Yes, although (to exaggerate quite a bit) if the effect is to
tell people that, if they are to participate effectively in
IETF, they better be running SuperDuperMailClient version 99 or
later, that would be, IMO, a net loss too.   As Ned has implied
(even if not said explicitly), many IETF participants have no
control over the the client (or server) software they use.   If
they are also part of corporate environments in which people are
wondering about the value of IETF participation for other
reasons, a demand that the organization either switch software
or allow an exception could easily be one less (or one company
less) active participant in the IETF.  I don't see that as a
desirable outcome, no matter how much dogfood is happily
ingested by those who are left.

> It's also important to reach some measure of consensus on how
> much inconvenience is too much. It's clear that Viktor and I
> disagree on this - I think supporting people who for whatever
> reason have to contend with crappy email software is far more
> important than any sort of dogfood eating exercise.

Yes.  See above.

> And after spending several years pretty much begging the
> security area to take some small notice of this particular set
> of issues, you can understand why I have very little patience
> left for having the much more detailed conversation you
> apparently want to have.

As the two of you and probably some others know, I made an
explicit personal decision to avoid active participation in
computer security issues in the mid-1970s, before the IETF and
indeed before the Internet.  One reason was that there seemed to
be a number of people in the field who were a lot smarter about
the issues than I was and I thought I could more productively
spend my time in other ways.   But another important one was
that I saw a little bit too much of reasoning that started from
"we have this solution, let's see where it can be applied",
rather than "this is a problem we need to solve because, let's
find a solution that addresses it without unnecessary
undesirable side effects" and I have trouble working that way.
It appears that nothing much have changed in 50 years except the
latter problem seems to have gotten worse.

Just as Ned wishes that some of the fundamental application and
deployment questions would be addressed in a serious way (and I
do too), I wish every security-related protocol document would
contain a mandatory section describing the threat model the
protocol or technique is intended to address and how it will
address it.

     john