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

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 1 Sep 2015 12:10:40 -0400

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 1 Sep 2015 16:55:26 +0000

On Tue, Sep 01, 2015 at 12:10:40PM -0400, Kathleen Moriarty wrote:

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

A step in the right direction, but I think we can do better.  The
document under discussion is a crypto agility document.  Agility
plays two roles in cryptographic protocols:

    * Makes it possible to introduce new stronger algorithms.
    * Makes it possible to phase out old deprecated algorithms.

>From an OS perspective, when no particular security level is
demanded, and we're merely trying to get the best possible protection
against passive attacks, the main benefit of agility is the first
one: over time, we end up using stronger crypto.

Rapid deprecation of weaker crypto is net loss for OS when the
result is loss of interoperability and/or fallback to cleartext.

So I think that the focus in the original and proposed text is not
optimal, we ought to first point out that OS benefits from agility
when better crypto is deployed side by side with legacy crypto
(deprecated or not) and is supported by the peers in a given
"conversation".

With that noted, we should observe (with reference to [7435]) that
with OS one should not rush into removal of legacy weak crypto that
is still required for inteoperability with enough systems, and
*does not* facilitate downgrade attacks.  Rather one introduces
better alternatives, encourages users to upgrade their systems,
and waits for the old to become largely unnecessary before removing
support.

That said, when new OS protocols or applications are developed,
that have no legacy interoperability requirements, they SHOULD NOT
grandfather support for algorithms that are already deprecated.

[ I know I did not put this together into a specific suggestion
  for a replacement, I hope this is useful nevertheless. ]

-- 
	Viktor.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 1 Sep 2015 19:02:01 +0200

Hi Victor,

> result is loss of interoperability and/or fallback to cleartext.

Of course, this holds true when there are no alternatives from which to
select.  And it ties back to the second advantage you cited:
> Makes it possible to phase out old deprecated algorithms.

But what is it one has to do?  Why is the answer simply to specify MTI
two actively used suites and then vary which two over some (hopefully
long) period over time?

Eliot

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 1 Sep 2015 17:16:52 +0000

> > Makes it possible to phase out old deprecated algorithms.

Eventually, when "essentially everyone" supports better options,
the old can be dropped even by OS clients and servers.  So the
second benefit is "delayed" for OS, we quickly lift the "ceiling"
and as time goes by and this becomes practical lift the "floor".

> two actively used suites and then vary which two over some (hopefully

Two might not in practice be enough for OS, if deployed software
lasts 10+ years without upgrades.  Sure, only two suites might be
MTI at a given time, but implementations will often need to continue
to support "past" MTI suites, if those are the best available for
a sufficient number of peers.

Thus a suite that used to be "MTI", but no longer is, becomes
de-facto required for OS.  Actually this applies not just OS, in
practice even mandatory security protocols need to worry about
interoperability.  

The difference is mostly in how quickly deprecated crypto is
abandoned, because cleartext is rarely better than weak crypto
(modulo facilitation of downgrades against even non-OS peers ala
logjam and EXPORT ciphers).

While browsers and webservers are moving quick to abandon RC4 in
2015, SMTP servers and clients are going to continue to support it
for at least another year or two.  Some SMTP serevrs already don't
tolerate RC4 and create pressure on the legacy systems to upgrade.
For most, it makes more sense to continue to receive mail than to
enforce crypto-correctness.  The overall process takes longer.

--
	Viktor.

---

From: Steve Crocker <[email-masked]>
Date: Tue, 1 Sep 2015 13:28:17 -0400

The challenge is knowing when old algorithms can be dropped safely.  There has to be widespread adoption of newer algorithms and there has to be evidence of that widespread adoption.  Removal from the OS is the last step.  Prior to that the usage of the old algorithm has to drop to near zero, and that will happen only when it's evident to the party that chooses which algorithm to use is confident the other party is capable of using the newer algorithm.

Each of these steps takes a long time.  The process moves along more quickly if there is some sort of measurement or reporting of which algorithms the responding party is capable of using.

See RFC 6975 for our attempt to deal with this for DNSSEC.

Thanks,

Steve

Sent from my iPhone

> On Sep 1, 2015, at 1:16 PM, Viktor Dukhovni <[email-masked]> wrote:
> 
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 1 Sep 2015 18:01:47 +0000

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

This is a great summation; I agree.

Now it's a simple matter of coding^W wordsmithing :)

--  
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Russ Housley <[email-masked]>
Date: Tue, 1 Sep 2015 16:58:31 -0400

I'm trying to pull together the things that I have heard on this thread over the last week regarding Section 2.9.  I think I have captured them.  Please let me know if I missed something?

   Despite the guidance in Section 2.4, opportunistic security [RFC7435]
   also deserves consideration, especially at the time a protocol
   implementation is deployed and configured.  Using algorithms that are
   weak against advanced attackers but sufficient against others is one
   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 as
   discussed in Section 3 of [RFC7435] as long as their use does not
   facilitate downgrade attacks.  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.

Russ

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 1 Sep 2015 21:19:06 +0000

On Tue, Sep 01, 2015 at 04:58:31PM -0400, Russ Housley wrote:

> I'm trying to pull together the things that I have heard on this thread
> over the last week regarding Section 2.9.  I think I have captured them.
> Please let me know if I missed something?
> 

I still think that the focus on just the weak(er) algorithms in OS
is unfortunate.  Rather agility and OS work hand-in-hand to improve
communications to the extent possible.  As new algorithms are
deployed, opportunistic peers will autmatically start to use stronger
cryptography.  

Once new algorithms have largely displaced legacy algorithms, one
can begin considering retirement of algorithms that used to be
required for interoperability.  This process is likely to take
longer for OS protocols/applications because interoperability
carries greater weight when security is not a hard requirement and
the alternative is cleartext.

So I'd like to see text that first emphasises the good news (over
time agility improves the security of OS protocols).  Then the bad
news (retirement of legacy crypto takes longer).  And finally notes
that OS is not carte-blanche for weak crypto, new OS applications
need to start with non-deprecated crypto, and legacy crypto needs
to still be retired once no longer needed.

-- 
	Viktor.

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 1 Sep 2015 17:24:08 -0400

>    the same constraints.  That said, the use of strong algorithms is

Your additional edits look good to me, thank you!
Kathleen

-- 

Best regards,
Kathleen

---

From: Russ Housley <[email-masked]>
Date: Tue, 1 Sep 2015 19:56:16 -0400

> to still be retired once no longer needed.

The whole point of the document is to make it easy to migrate from one algorithm suite to another more desirable one.  However, sometimes we want to keep an algorithm around that would otherwise have been discarded to achieve opportunistic security.  You seem to be trying to pull the points from the rest of the document into this paragraph.

Russ

---

From: Sam Hartman <[email-masked]>
Date: Tue, 01 Sep 2015 20:26:25 -0400

>>>>> "Russ" == Russ Housley <[email-masked]> writes:

    >> I still think that the focus on just the weak(er) algorithms in
    >> OS is unfortunate.  Rather agility and OS work hand-in-hand to
    >> improve communications to the extent possible.  As new algorithms
    >> are deployed, opportunistic peers will autmatically start to use
    >> stronger cryptography.
    >> 
    >> carries greater weight when security is not a hard requirement
    >> and the alternative is cleartext.
    >> 
    >> time agility improves the security of OS protocols).  Then the
    >> bad news (retirement of legacy crypto takes longer).  And finally
    >> notes that OS is not carte-blanche for weak crypto, new OS
    >> applications need to start with non-deprecated crypto, and legacy
    >> crypto needs to still be retired once no longer needed.

    Russ> The whole point of the document is to make it easy to migrate
    Russ> from one algorithm suite to another more desirable one.
    Russ> However, sometimes we want to keep an algorithm around that
    Russ> would otherwise have been discarded to achieve opportunistic
    Russ> security.  You seem to be trying to pull the points from the
    Russ> rest of the document into this paragraph.

Russ, like Viktor, when I read the proposed text for section 2.9 I hear
emphasis on supporting weak crypto for OS.  The text doesn't quite come
out and say any of the following, but I find myself trying to come up
with justifications for why I'd prefer weak crypto for OS.  Is it
faster?  Is it more exportable?  By the time I get to the sentence that
says stronger is still preferable, I'm so lost that it hardly registers.

I find the quoted paragraph sounds like it's trying to be more divergent
with the rest of the document rather than complimentary.
So, while perhaps literally doing what Viktor proposes and including all
those points in 2.9 would be redundant, perhaps we can strive for
something more consistent with his approach.

What the proposed text says is all consistent, it just reads wrong and
at least to me and apparently Viktor implies things that I don't think
we really mean.

I'm sorry I can't be more helpful.  I'm not trying to raise anything
blocking, just hoping to help you better understand the explanation.

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 1 Sep 2015 23:09:23 -0400

Sent from my iPhone

> at least to me and apparently Viktor implies things that I don't think

I think the proposed text is a lot better than what was there and I think there is consensus around it.  Once you get more specific, then you are moving away from what was agreed upon in the OS draft.  Doing that would require quite a bit more discussion.

The proposed text reads well to me and keeps us more consistent - use of weaker crypto for OS is limited to legacy deployments and is not okay for authenticated and encrypted sessions for OS, just unauthenticated.  If you have a proposal for text that keeps within the space where I think we have consensus, then I'm okay with change otherwise I'm not.  It might take reading through this draft and the OS RFC, once that has been done, this text makes sense... Reading big through the discussion on this over the past week or so may help as well.

Thanks,
Kathleen

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 2 Sep 2015 04:01:45 +0000

On Tue, Sep 01, 2015 at 11:09:23PM -0400, Kathleen Moriarty wrote:

> I think the proposed text is a lot better than what was there and I think
> there is consensus around it.  Once you get more specific, then you are
> moving away from what was agreed upon in the OS draft.  Doing that would
> require quite a bit more discussion.
> 
> The proposed text reads well to me and keeps us more consistent - use of
> weaker crypto for OS is limited to legacy deployments and is not okay for
> authenticated and encrypted sessions for OS, just unauthenticated.  If
> you have a proposal for text that keeps within the space where I think we
> have consensus, then I'm okay with change otherwise I'm not.  It might
> take reading through this draft and the OS RFC, once that has been done,
> this text makes sense... Reading big through the discussion on this over
> the past week or so may help as well.

I am not saying the proposed text is wrong on its substance, rather
I am a somewhat concerned about what seems to be misplaced emphasis.
I think Sam agrees along essentially the same lines.

I've not suggested a specific remedy, just throwing ideas out there
and hoping they might be useful.

In part I don't think I should be the only one doing all the
explaining of OS, it is best if others can make additional
contributions to the formulation of a refined consensus in this
area.

It would I think be better to note that OS (when unauthenticated
and provies only passive protection) is not fundamentally about
use of weaker crypto.  Rather it is about doing as much better than
cleartext as one can, and agility is helpful, but more quickly on
the uptake of new algos than deprecation of legacy algos, because
interop considerations and avoiding cleartext trump the urgency of
deprecating weak crypto.

That said, that's just how I see it, and I don't want force my
formulation on everyone else, so if there are other ways to improve
the text (change of emphasis) that's fine.

-- 
	Viktor.

---

From: Barry Leiba <[email-masked]>
Date: Wed, 2 Sep 2015 18:06:45 -0400

(Responding to the thread in general, not to VIktor's note in particular.)

I honestly don't see why this issue is relevant to agility at all, and
I would just strike the mention altogether, as I don't think it
affects the point that we need to have the ability to change
algorithms baked into the protocol and designed into the software.

The point of OS is to negotiate the best security we can, and be
willing to accept a certain minimal security level, where the
definition of what's minimally acceptable will change from one
situation to another.

Algorithm agility can help us achieve that, and that might be worth
saying.  But whether in a particular OS situation we care willing to
negotiate something that we'd otherwise consider deprecated is a
question unto itself, not one that guidance on algorithm agility needs
to discuss.

Barry

---

From: Russ Housley <[email-masked]>
Date: Wed, 2 Sep 2015 18:14:01 -0400

Barry:

I think the only point is that someone might want to use an algorithm for OS that would otherwise be deprecated.

Maybe the IESG can discuss this point on the call tomorrow and offer some advice.

Russ

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 2 Sep 2015 18:17:05 -0400

> question unto itself, not one that guidance on algorithm agility needs

In general, I would agree, but after doing much reading and following
this thread, I think this is important text.  There are specific
caveats to using deprecated crypto with OS and they are important to
understand so that we don't wind up with an overly general explanation
that says "it's okay to use deprecated crypto with OS".  It is, but
only in certain situations.  I don't think this has been clear enough,
so the updated text is helpful.

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 2 Sep 2015 23:24:12 +0100

> so the updated text is helpful.

FWIW, I agree with the above.

S.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 2 Sep 2015 22:34:18 +0000

On Wed, Sep 02, 2015 at 06:06:45PM -0400, Barry Leiba wrote:

> (Responding to the thread in general, not to Viktor's note in particular.)
> 

Barry's suggestion works for me.  Perhaps this document need not
be the one to clarify cipher deprecation for OS.

But if it does, some text to make it clear that OS is about using
the *strongest available* crypto, not weak crypto.  But crypto
weaker than would otherwise be acceptable, may be acceptable with
OS for some time to facilitate interoperability with legacy systems.

It can be a sentence or two, just enough to not give the impression
that weak crypto is preferred with OS.

-- 
	Viktor.

---

From: Russ Housley <[email-masked]>
Date: Thu, 3 Sep 2015 16:08:59 -0400

> that weak crypto is preferred with OS.

The words in my current edit buffer are:

Would it help to change "As a result" to "As a result, when communicating parties do not have strong algorithms in common"?

Russ

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 3 Sep 2015 20:34:22 +0000

On Thu, Sep 03, 2015 at 04:08:59PM -0400, Russ Housley wrote:

> Would it help to change "As a result" to "As a result, when communicating
> parties do not have strong algorithms in common"?

You're heading in the right direction, but I think this is a sentence
or so too late.  The sentence that starts with "Using algorithms
that are weak ..." is troublesome.  How about:

    Using the strongest available encryption (even if not strong
    enough for mandatory security) is one way ...

And then perhaps still make the additional change you're proposing.

-- 
	Viktor.

---

From: Russ Housley <[email-masked]>
Date: Thu, 3 Sep 2015 16:50:40 -0400

> And then perhaps still make the additional change you're proposing.

Trying to pull the idea into the earlier part of the paragraph...

Current Text:

   Using algorithms that are weak against advanced attackers but
   sufficient against others is one way to make pervasive
   surveillance significantly more difficult.

Possible Alternative:

   Opportunistic security, like other reasons for encrypting traffic,
   needs to make use of the strongest encryption algorithms that are
   implemented and allowed by policy.  When communicating parties do
   not have strong algorithms in common, using algorithms that are
   weak against advanced attackers but sufficient against others is
   one way to make pervasive surveillance significantly more difficult.

Russ

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 3 Sep 2015 20:58:08 +0000

>    one way to make pervasive surveillance significantly more difficult.

I can probably live with that.

-- 
	Viktor.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 03 Sep 2015 17:01:48 -0400

>>>>> "Russ" == Russ Housley <[email-masked]> writes:
    Russ> Would it help to change "As a result" to "As a result, when
    Russ> communicating parties do not have strong algorithms in
    Russ> common"?

Yes!
that sounds great.

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 3 Sep 2015 17:31:15 -0400

>     Russ> communicating parties do not have strong algorithms in

I'm fine with this change as well.

Thanks.

-- 

Best regards,
Kathleen