Subject: [saag] Stephen Farrell's Yes on draft-dukhovni-opportunistic-security-05: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Sun, 16 Nov 2014 11:54:04 -0800

Stephen Farrell has entered the following ballot position for
draft-dukhovni-opportunistic-security-05: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

In reviewing this just before the end of IETF LC, there's one place
where I'd prefer a slightly different emphasis. I've run this by 
Viktor and he however disagrees with the change so I'll leave it
for folks to comment and see what other IESG members think..
To be clear, I don't myself think the document needs to be 
blocked to get this fixed, but I'd like it to be considered. And
I figure there are good arguments for both OLD and NEW 
paragraphs below so I'm not saying that the NEW one below
is "right" and the OLD is "wrong" but I do think the NEW is
more consistent with what we want to see happen in future.
Others, (Viktor for example:-) can reasonably disagree. 

OLD:

   With unauthenticated, encrypted communication, OS protocols may
   employ more liberal settings than would be best-practice when
   security is mandated by policy.  Some legacy systems support
   encryption, but implement only outdated algorithms or protocol
   versions.  Compatibility with these systems avoids the need to resort
   to cleartext fallback.

NEW:

   With unauthenticated, encrypted communication, OS protocols may
   employ more liberal settings than would be best-practice when
   security is mandated by policy.  Some legacy systems support
   encryption, but implement only outdated algorithms or protocol
   versions.  Compatibility with these systems avoids the need to resort
   to cleartext fallback. However, the use of "broken" algorithms,
   especially ones for which a ciphertext-only attack may be
   feasible in the near term, is not consistent with the OS
   approach. In such cases, avoiding the "broken" cipher, and
   falling back to cleartext is in fact the correct outcome, as
   recorded ciphertext for an algorithm with a feasible
   ciphertext-only attack is really the same as cleartext. That
   said, there may be cases where an implementation does negotiate
   use of such an algorithm for some (hopefully) short period
   with (hopefully) very few peers, while software and/or
   configurations are in the process of being updated, but this
   should be considered a failure (to update) and not as an
   acceptable outcome that is consistent with the OS approach.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 17 Nov 2014 01:02:40 +0000

On Sun, Nov 16, 2014 at 11:54:04AM -0800, Stephen Farrell wrote:

For my counter-offer, as a middle-ground between OLD and NEW, see
below.  The idea is to note that support for weak crypto is an
interim measure, without taking sides on the weak crypto is worse
than no crypto debate.  I am very relunctant to endorse cleartext
fallback as a better alternative than leaving deprecated crypto
enabled.  My preference is to see opportunistic security applications
drop support for weak crypto as soon as it is in practice "never"
needed, but not much sooner.

>    acceptable outcome that is consistent with the OS approach.

IN GOOD CONDITION:

     Some legacy systems support encryption, but implement only
     outdated algorithms or protocol versions.  With unauthenticated,
     encrypted communication, OS protocols may tolerate the use of
     outdated algorithms that would generally be excluded when
     security is mandated by policy.  Compatibility with legacy
     systems avoids the need to resort to cleartext fallback.
     However, the use of outdated algorithms needs to be a temporary
     transition strategy, used only to in support of an orderly
     phase-out of such algorithms.  Outdated algorithms, especially
     those that are already broken in some use-cases, or are expected
     to soon be broken, should not be supported indefinitely.

For a recent example, my SMTP server preempts the SMTP client's
TLS cipherlist order, and lists RC4 only as a last resort.  And
yet:

    Nov 12 03:52:32 amnesiac postfix/smtpd[1144]:
	Anonymous TLS connection established
	from nk11p03mm-asmtpout002.mac.com[17.158.232.237]:
	TLSv1 with cipher RC4-MD5 (128/128 bits)

So this system, sending mail from a "me.com" user is capable nothing
better than RC4-MD5.  I expect such silliness to end soon, but for
the immediate future, I am leaving RC4 enabled.

-- 
	Viktor.

---

From: "Black, David" <[email-masked]>
Date: Mon, 17 Nov 2014 13:51:51 +0000

+1 on Viktor's middle-ground.

"broken" algorithms come in various forms and degrees of "broken".  Even
increasing the effort required of a pervasive passive attacker to obtain
cleartext from a "broken" algorithm is useful, and we should be encouraging
deployment of "non-broken" technology.

Thanks,
--David

> -----Original Message-----
> From: saag [mailto:[email-masked]] On Behalf Of Viktor Dukhovni
> Sent: Sunday, November 16, 2014 8:03 PM
> To: The IESG
> Cc: [email-masked]
> Subject: Re: [saag] Stephen Farrell's Yes on draft-dukhovni-opportunistic-
> security-05: (with COMMENT)
> 
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 17 Nov 2014 15:34:18 +0000

> deployment of "non-broken" technology.

True, otoh md5 shows how long it still takes to get rid of stuff
even after a bad break.

But Viktor's latest below is better than -05 I agree.

I might suggest a tweak which is to change the last clause
from "should not be supported indefinitely." to "ought not
be used." giving (with one typo fix):

YETANOTHERNEW:

      transition strategy, used only in support of an orderly
      to soon be broken, ought not be used.

---

From: Nico Williams <[email-masked]>
Date: Mon, 17 Nov 2014 09:57:25 -0600

>> +1 on Viktor's middle-ground.

I'm +1 on the original.  I'd settle for Viktor's counter to Stephen's
text (either variant).

Needless to say, the identity function is the weakest, most obsolete
cryptographic security algorithm available to us.  We should ban it
before RC4, MD5, ... -- that's the principle that I'm basing my reply
on.

We have a mostly political trade-off here:

 - outright prohibitions of broken algorithms provide a strong
incentive for making progress on deploying new algorithms

 - but outright prohibitions on cleartext of the same strength as
prohibitions of broken algorithms have not really been tested.

Of course, one side effect of more deployment of OS will be to make
prohibition of cleartext transmission easier.  But if we start by
making deployment of any crypto harder...

Pushing for a stronger ban of broken algorithms than of cleartext is a
recipe for ending up with more cleartext and less OS.  But if we allow
OS to take root first then we'll be able to improve security across
the board, and we'll arrive more quickly at a situation where it's
easy to forbid the use of cleartext and weak algorithms.

Nico
--

---

From: Michael Richardson <[email-masked]>
Date: Mon, 17 Nov 2014 23:34:13 -0500

> before RC4, MD5, ... -- that's the principle that I'm basing my reply

+10.
If we can get code and infrastructure deployed to do RC4, then upgrading it
to be AES is much simpler than starting from scratch.   Remember that if it's
opportunistic, we might choose the identity encryption algorithm instead.

    > easy to forbid the use of cleartext and weak algorithms.

Bait and switch doesn't work if you tell people about it :-)

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-