[saag] Section 2.9: was Re: AD review of draft-iab-crypto-alg-agility-06

[Kathleen Moriarty <[e-mail]>]

In going through the mail on this and the Perpass list, then also
re-reading RFC7435, I think I see more of where the discrepancies are,
but do need to make sure there is agreement.  I don't think there is
consensus for what is stated in section 2.9 of this draft after
reading through the threads, but will propose something after
explaining why.

While the detailed discussions were helpful, let's keep this to a
high-level as the text in draft-iab-crypto-alg-agility is high-level
and that will help us get to something workable (assuming there is
agreement that a change would better reflect consensus).

Current text:

2.9.  Opportunistic Security

   Despite the guidance in Section 2.4, opportunistic security [RFC7435]
   SHOULD also be considered, especially at the time a protocol
   implementation is deployed and configured.  Using algorithms that are
   weak against advanced attackers but sufficient against others is a
   way to make pervasive surveillance significantly more difficult.  As
   a result, algorithms that would not be acceptable in many negotiated
   situations are acceptable for opportunistic security.  Similarly,
   weaker algorithms and shorter key sizes are also acceptable for
   opportunistic security.  That said, the use of strong algorithms is
   always preferable.

If you go back to the OS RFC, RFC7435, the discussions of OS with
general definitions are kept to clear text, unauthenticated session
encryption, and authenticated encryption.  The use of weaker or
deprecated crypto is discussed, but that starts in section 3,
Opportunistic Security Design Principles.  Section 3 has carefully
worded constraints on this use, so when I read it originally, I didn't
think of this as part of the definition for OS, but rather that it
would be okay with legacy systems.

Here is the text:

RFC7435, Section 3:

   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.

   For greater assurance of channel security, an OS protocol may enforce
   more stringent cryptographic parameters when the session is
   authenticated.  For example, the set of enabled Transport Layer
   Security (TLS) [RFC5246] cipher suites might exclude deprecated
   algorithms that would be tolerated with unauthenticated, encrypted
   communication.

   OS protocols should produce authenticated, encrypted communication
   when authentication of the peer is "expected".  Here, "expected"
   means a determination via a downgrade-resistant method that
   authentication of that peer is expected to work.  Downgrade-resistant
   methods include: validated DANE DNS records, existing TOFU identity
   information, and manual configuration.  Such use of authentication is
   "opportunistic", in that it is performed when possible, on a per-
   session basis.

   When communicating with a peer that supports encryption but not
   authentication, any authentication checks enabled by default must be
   disabled or configured to soft-fail in order to avoid unnecessary
   communications failure or needless downgrade to cleartext.

   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.  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.

Considering that the use of less than ideal crypto is somewhat
restricted to the unauthenticated session encryption and is acceptable
only with legacy systems (and the messages on this thread about
reaching consensus), I propose the following text changes to 2.9 of
the crypto agility draft:

2.9.  Opportunistic Security

   Despite the guidance in Section 2.4, opportunistic security [RFC7435]
   SHOULD also be considered, especially at the time a protocol
   implementation is deployed and configured.  Using algorithms that are
   weak against advanced attackers but sufficient against others is a
   way to make pervasive surveillance significantly more difficult.  As
   a result, algorithms that would not be acceptable in many negotiated
   situations are acceptable for opportunistic security when legacy
systems are in use for unauthenticated encrypted sessions [RFC7435]
Section 3.  Similarly,
   weaker algorithms and shorter key sizes are also acceptable for
   opportunistic security with the same constraints.  That said, the
use of strong algorithms is
   always preferable.


I think it is important to include the design constraints in this
paragraph, but am okay with wording changes that make the constraints
clear so that we don't wind up generalizing the OS design principles
and have them mean more than what was intended.  I'd like to see this
constrained to legacy systems as it's not always possible to have them
upgraded.   I also don't want to see OS become a way to bless the use
of deprecated crypto, but would rather see it as in use for legacy
systems understanding that it has been deprecated.  Without that, I am
afraid it will become increasingly more difficult to phase out
deprecated crypto.  I'd like to see that we are at least consistent in
drafts/RFCs going forward so we don't inadvertently demonstrate
consensus for more than what was agreed (IMO).

Does the proposed text sound good (or something with the same intent)?

Thanks very much for the useful discussions on this topic!

-- 

Best regards,
Kathleen