Subject: [saag] Pete Resnick's Discuss on draft-dukhovni-opportunistic-security-05: (with DISCUSS)

From: "Pete Resnick" <[email-masked]>
Date: Mon, 24 Nov 2014 17:36:34 -0800

Pete Resnick has entered the following ballot position for
draft-dukhovni-opportunistic-security-05: Discuss

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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Well, either Stephen or I get to hold the DISCUSS, so I guess it's going
to be me. As soon as this discussion is addressed, I'll switch to "Yes".

I disagree with the change to section 3 in the RFC Editor Note, as it
does not represent IETF consensus. The current text as stated in the
document is fine. I feel that any discussion of the "transition" from
broken algorithms to good ones (not to mention the transition from
cleartext to encrypted) is really orthogonal to this document: This
document is saying that, if clear text is permitted, the protocol will
work it's way up from clear text (if possible) to the best security it is
able to achieve. That includes encryption using broken algorithms, which
is still better than clear text to prevent a passive observer, who might
not be willing to invest in saving the data and decrypting it later, from
seeing the data. That we want to transition away from broken algorithms
is as true as the fact that we want to transition away from clear text,
but even the latter is not currently mentioned in the document, except by
implication in the last paragraph of section 3.

I think a reasonable compromise is to add some discussion of broken
algorithms to the last paragraph of section 3:

OLD
   Cleartext is supported for backwards compatibility with systems
   already deployed.  Even when cleartext needs to be supported,
   protocol designs based on Opportunistic Security prefer to encrypt,
   employing cleartext only with peers that do not appear to be
   encryption capable.
NEW
   The support of cleartext and the use of outdated algorithms, and
   especially broken algorithms, is for backwards compatibility with
   systems already deployed.  Protocol designs based on Opportunistic
   Security prefer to encrypt, and prefer to use the best available
   encryption algorithms available. OS protocols employ cleartext or
   broken encryption algorithms only with peers that do not appear to be
   capable of doing otherwise.

If Stephen or others insist that transition be mentioned, you could add a
sentence to that paragraph, and I am likely willing to hold my nose:

                                The eventual desire is to transition
   away from cleartext and broken algorithms, and particularly for
   broken algorithms, it is highly desirable to remove such
   functionality from implementations.

But I really don't believe that such a sentence belongs in this document;
if it does, it probably belongs in every Security Considerations section
ever written that mentions the use of cleartext or encryption algorithms.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 25 Nov 2014 01:44:43 +0000

Hi Pete,

I could live with your nose-holding text and have updated
the RFC editor note accordingly. Let me know if I got that
right or not.

Thanks,
S.

On 25/11/14 01:36, Pete Resnick wrote:
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>

---

From: Pete Resnick <[email-masked]>
Date: Mon, 24 Nov 2014 19:57:36 -0600

Clothespin firmly attached to proboscis, I have switched to a "Yes".

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478