Subject: [saag] AD review of draft-iab-crypto-alg-agility-06

From: Stephen Farrell <[email-masked]>
Date: Fri, 17 Jul 2015 18:18:41 +0100

Hiya,

Russ has asked me to start IETF last call for this draft and I
plan to do that shortly. For WG drafts I usually post an AD
review before doing so, and that's below. I don't think any of
my comments need to be processed before starting LC so these
should be considered along with other last call comments
received.

Cheers,
S.

[1] https://tools.ietf.org/html/draft-iab-crypto-alg-agility-06

Don't be put off by the filename, this is being proposed for the
IETF stream as a BCP.

intro, 3rd para: are we saying that agility is achieved when a
protocol (specification) can easliy migrate from one suite to a
better one, or when a deployment can easily migrate? The current
text implies the former, but I'm not sure if we'd be better off
aiming more for the latter.

2.1: "Algorithm identifiers, on the other hand, impose a burden on
implementations by forcing a determination at run-time regarding
which algorithm combinations are acceptable." Here you mean IPsec
style or chinese menu style alg ids. Do we need to make sure that
alg id and suite id are used consistently throughout as one or the
other but not both, and do we need a new term that means either? (I
find this clear enough, but I'm not sure if it might confuse some
readers.)

2.3: "a mechanism is needed to determine whether the new algorithm
has been deployed" I think that's overstated, maybe
s/needed/desirable/ would be better?  (maybe with a bit more
wordsmithing)

2.4: The SHOULD for integrity only applies when the negotiation is
done over the network, but some "selection" methods might not need
protocol integrity mechanisms. Maybe drop "selection" there?

2.4: Maybe join paras 2 and 3, para 2 alone reads a little oddly

2.9: I'm not really a fan of blessing weaker algs for OS, but I lost
that argument before. I wonder if we would get consensus if this
said that weak algs are better than no encryption but still MUST be
deprecated as soon as feasible?

3.1, 1st para: I think this could do with some more editing.

3.2: "some people say" is a bit too weasel-wordy

3.2: the second para here is repetition, I think you could delete
all or almost all of that

4: "eliminate the cruft" - yes, I like that:-)

general: there are some typos throughout, another pass to fix those
would be good but I didn't have time to note them all sorry

---

From: "Paul Hoffman" <[email-masked]>
Date: Fri, 17 Jul 2015 13:51:03 -0700

> aiming more for the latter.

+1

> find this clear enough, but I'm not sure if it might confuse some

This is not necessarily about "pick one from each column". For example, 
an S/MIME implementation has to decide whether to accept a particular 
algorithm for authentication if it has a policy "always strong crypto".

> s/needed/desirable/ would be better?  (maybe with a bit more

+1. "mechanism" is overstated (although "policy" is usually a mess...).

> 3.2: "some people say" is a bit too weasel-wordy

Disagree. We don't have solid statements from enough believable parties 
here.

> would be good but I didn't have time to note them all sorry

--Paul Hoffman

---

From: "Black, David" <[email-masked]>
Date: Sat, 18 Jul 2015 08:18:45 +0000

> > aiming more for the latter.

IoT slippery slope warning, e.g., I have no idea how to update my
refrigerator's firmware, and "Patch Tuesday" is not a great answer due
to risks of spoiled food ;-). (https://en.wikipedia.org/wiki/Patch_Tuesday)

I'd concur that deployment upgradeability is a worthy goal, but would
suggest leaving exploration of details of how to pull that off to other
drafts/forums.

Thanks,
--David

> -----Original Message-----
> From: saag [mailto:[email-masked]] On Behalf Of Paul Hoffman
> Sent: Friday, July 17, 2015 4:51 PM
> To: Stephen Farrell
> Cc: [email-masked]
> Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06
> 
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Kathleen Moriarty <[email-masked]>
Date: Sat, 18 Jul 2015 10:30:19 +0200

Hi,

Sent from my iPhone

> On Jul 17, 2015, at 7:18 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 

I don't think we've really debated this enough to get consensus.  I don't think weaker algs fit into our agreed definitions for OS.  I just recall your debate with Pete on another draft, but think a wider debate is needed to see what the consensus is.  I don't think weaker algorithms should fit into the definition.

Best regards,
Kathleen

---

From: Eliot Lear <[email-masked]>
Date: Sat, 18 Jul 2015 14:04:41 +0200

Hi David,

> suggest leaving exploration of details of how to pull that off to other

Right.  In constrained environments it may be easier to disable
functionality rather than enable functionality on constrained
platforms.  This is already recognized in the introduction, and is
largely covered also in Section 3.2.  My suggestion is simply to add a
sentence in the last paragraph of that section prior to "The idea is to
have..." along the following lines:

Implementation of more than one MTI requires that each associated code
path be not just implemented but USED, so that any change from a mature
yet broken code path does not lead to a rash of problems with an
up-til-that-point unused code path.

Also that paragraph ends with what is indeed a challenge:

>    Also, the manner by
>    which system administrators are advised to switch algorithms or
>    suites is at best ad hoc, and at worst entirely absent.

One approach is to simply take this out of the hands of system
administrators and leave it in the hands of implementers, who can update
their code.  This can help chop the tail off of the laggard side of the
curve, but it's not always appropriate.  But it might make for a good
default behavior.

Eliot

---

From: Derek Atkins <[email-masked]>
Date: Sun, 19 Jul 2015 19:24:00 -0400

Kathleen Moriarty <[email-masked]> writes:

> I don't think we've really debated this enough to get consensus.  I
> don't think weaker algs fit into our agreed definitions for OS.  I
> just recall your debate with Pete on another draft, but think a wider
> debate is needed to see what the consensus is.  I don't think weaker
> algorithms should fit into the definition.

What seems like a good algorithm today may become a weaker algorithm
tomorrow.  Similarly, a new, better algorithm may appear next week.  So
while I think we can all agree that no, we shouldn't use 1DES today, we
don't know if next week someone will find an attack against AES-128 or
ECC-P256.  What I'm saying that that qualifying "strong" and "weak" is,
unfortunately, a more subjective (vs objective) process.

> Kathleen

-derek
-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Watson Ladd <[email-masked]>
Date: Sun, 19 Jul 2015 20:41:13 -0700

> unfortunately, a more subjective (vs objective) process.

If this was possible, it would happen. But it really hasn't: if a
symmetric cipher is not analyzed within a year or two of coming out,
it never will be. The real problem is that people don't bother to
properly look up these analyses and see that RC4 is weak, or that DES
has insufficient size, or that Dobbertin has found free start
collisions in MD5. And when questions arise about the safety of these
primitives, we don't have a push to disable them, leaving it to
administrator action starting at the last minute. Every single attack
found recently against TLS depends on long-standing concerns that got
pushed to the side in the WG process.

Of course, the people deciding that algorithm XYZ sounds "better" than
VWQ don't actually know the relevant field, and the more we push that
decision towards end users and away from people who do know, the worse
this situation gets.

Sincerely,
Watson Ladd

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 20 Jul 2015 04:48:49 +0000

> [1] https://tools.ietf.org/html/draft-iab-crypto-alg-agility-06

Quick comments (mostly nits):

Intro paragraph 2:

       Advances in computing power available to the attacker will eventually
       make any algorithm obsolete.

    I think this overstates the plausible advances in computing power.
    Many of the symmetric algorithms in use today are far outside the
    realm of any physically realizable brute force attack, unless also
    weakened through analytic techniques.

Section 2.1 second para top of page 4:

       Regardless of the approach used, protocols historically negotiate the
       symmetric cipher and cipher mode together to ensure that they are
       completely compatible.

   I would drop the word "completely".  And ditto in the next paragraph.

Section 2.2 first para:

       For this reason, the protocol MUST specify one or more strong
       mandatory-to-implement algorithm or suite.

   One or more is I believe more typically plural, so that would
   be "algorithms or suites".

Section 2.2.1:

       This approach allows other protocols can make use of CMS
       and make different mandatory-to-implement algorithm choices.

   s/can/to/

Section 2.4:

       Without integrity protection of algorithm or suite selection,
       the attempt to transition to a new algorithm or suite may
       introduce new opportunities for downgrade attack.

   Perhaps "for a downgrade attack" or "for downgrade attacks".

I find section 2.5 too vague, not sure what point it is really
trying to make.

Section 2.6:

       The impacts of legacy software an long support tails on security
       can be reduced by making it easy to rollover from old algorithms
       and suites to new ones.

    s/impacts/impact/
    s/an long/and long/
    s/rollover/transition/

       Without clear mechanisms for algorithm and suite rollover,
       preserving interoperability becomes a difficult social
       problem.  For example, consider web browsers.  Dropping
       support for an algorithm suite can break connectivity to
       some web sites, and the browser vendor will lose users by
       doing so.  This situation creates incentives to support
       algorithm suites that would otherwise be deprecated, but
       preserving interoperability.

    s/rollover/transitions/
    s/but preserving/in order to preserve/

	The digital signature on a trust anchor certificate [RFC5280]
	is often expected to last decades, which hinders the
	transition away from a weak signature algorithm or short
	key length.

    This example is somewhat flawed, browsers and CAs are well
    along the process of deprecating SHA-1, while ignoring its
    presence in trust-anchor certificates, because their self-signatures
    are typically not checked (check not needed).

	   Institutions, being large or dominate users within a large
	   user base, can assist by coordinating the demise of an
	   algorithm suite, making the rollover easier for their own
	   users as well as others.

    Somehow the meaning of the above eludes me.  It needs a rewrite.

Section 2,7:

       When selecting or negotiating a suite of cryptographic algorithms,
       the strength of each algorithm SHOULD be considered.  The algorithms
       in a suite SHOULD be roughly equal;

    s/roughly equal/comparably strong/ or (to really spell it out):
                   /have comparable best known attack work-factors/

    However if a particular element of a suite is believed stronger
    than the rest, we don't need to get too pedantic about that.
    Slightly lop-sided choices are OK if the stronger outlier is
    adequately fast, and weaker variants are not widely used.

       For example, cipher suites include Diffie-Hellman or RSA without
       specifying a particular public key length.  If the algorithm
       identifier or suite identifier named a particular public key
       length, migration to longer ones would be more difficult.  On
       the other hand, inclusion of a public key length would make it
       easier to migrate away from short ones when computational
       resources available to attacker dictate the need to do so.
       Therefore, flexibility on asymmetric key length is both desirable
       and undesirable at the same time.

       s/cipher suites include/TLS cipher suites include/

   Overall I think this text is wrong to weasel out.  Failure to
   negotiate the DH parameter size has proved rather problematic
   in TLS, with servers needing to guess at universally inteoperable
   prime bit length.  This is being addressed, with the DH groups
   extension now supporting standard prime groups as well as standard
   EC curves.  Underspecified algorithms MUST NOT be used.  Either
   fix the parameters, or negotiate them.

Section 2.8:

       Protocol designers MUST be prepared for the supported cryptographic
       algorithm set to change over time.  There is a spectrum of ways
       to enable the transition, and Section 3 discusses dome of the
       related issues.

    s/is a spectrum/are a number/
    "spectrum" implies some sort of continuum, which does not apply here.

Section 2.9:

    Opportunistic security is no excuse for designing in weaker
    algorithms into new protocols.  The text in RFC7435 relating
    to tolerating weaker algorithms in the name of interoperability
    is intended only for legacy systems.  When we're grafting crypto
    onto existing systems that run over cleartext, even weak crypto
    is better than none, but only if is already in use and required
    for interop.  For de-novo designs, the crypto should be just as
    strong.  Let's not lose from the get-go.

    Opportunistic security emphases adapting to peer capabilities,
    and incrementatl deployment, and should be considered where it
    would lead to greater use of security than all-or-nothing
    approaches.  The agility angle here, is that when deprecating
    algorithms that are still in wide use, opportunistic protocols
    might take longer to phase them out, because interoperability
    is a higher priority than in protocols with mandatory security.
    
[ Have to stop here for now, have not read the rest yet. ]

-- 
	Viktor.

---

From: ianG <[email-masked]>
Date: Fri, 24 Jul 2015 20:31:48 +0100

> suggest leaving exploration of details of how to pull that off to other

The inability to deploy is one of the major criticisms of agility;  if 
there is zero deployment, then there is no point to agility, and it is 
likely doing harm (complexity plus consumption of resources).  Then, if 
there is some deployment, there is some benefit, but does it achieve 
profit?  The arguments begin...

The IETF's business is more about protocol drafts not deployments, so I 
would say that the agility refers to the ability of the protocol to be 
agile, and not towards deployment.  Therefore agility is achieved when 
the protocol has it, not when deployment is shown.  So I'd leave the 
text as it is.

However, because of this criticism, we can't get away without putting a 
warning in there that agility is strictly limited by its ability to 
deploy.  That seems to find itself in section 4. Security 
Considerations, especially last para.

So I think in essence the point is covered.

iang

---

From: "Black, David" <[email-masked]>
Date: Sat, 25 Jul 2015 12:01:23 +0000

Thanks,
--David

> From: saag [mailto:[email-masked]] On Behalf Of ianG
> Sent: Friday, July 24, 2015 3:32 PM
> To: [email-masked]

---

From: "Black, David" <[email-masked]>
Date: Sat, 25 Jul 2015 12:03:33 +0000

Sorry for the initial blank response that got away ...

> Considerations, especially last para.

I agree with Eliot's point that two MTI algorithms plus configuration to
exercise both results in agility in non-upgradeable deployments, and think
his text suggestions make sense.

Thanks,
--David

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 26 Jul 2015 21:26:20 +0000

On Sat, Jul 18, 2015 at 10:30:19AM +0200, Kathleen Moriarty wrote:

> I don't think we've really debated this enough to get consensus.  I don't
> think weaker algs fit into our agreed definitions for OS.  I just recall
> your debate with Pete on another draft, but think a wider debate is needed
> to see what the consensus is.  I don't think weaker algorithms should fit
> into the definition.

What fits into OS is due consideration of interoperability constraints.
When clear text is sufficient, encryption is "desirable" and
authentication is "icing on the cake", it is a shame to resort to
cleartext, (or hard fail and ultimately lead the user to abandon
OS as too much pain for too little gain) just because encryption
might involve the use of tarnished algorithms.

What that all boils down to, is that with existing application
protocols, that are already doing OS (be it by another name), one
should be willing to tolerate tarnished algorithms that are "the
best" that some non-trivial fraction of peers can support at any
given time.

No tarnished algorithm needed for interop should be kept on
life-support in perpetuity.  The expectation is that over time
(somewhat lagging similar changes in mandatory security protocols)
tarnished algorithms also disappear from opportunistic protocols.

For example, opportunistic TLS in Postfix (by default) no longer 
includes support for "export" ciphers, SSLv2, SSLv3 or 1DES.

If and when OS is introduced in new applications or protocols, with
no legacy installed base setting interoperability constraints, no
tarnished algorithms should be accepted.  New protocols should,
if possible, start with a clean slate.  That is, from inception
start by satisfying as many as possible of:

	TLS 1.2 or higher (of course no SSLv2/SSLv3)
	No "export" ciphers
	No 1DES, RC4, IDEA, RC2, ...
	No MD5 or SHA1,
	...

Then as the protocol ages, and more things are deprecated,
interoperability constraints may at a later date mean that
newly tarnished crypto is kept around longer with OS than
otherwise, but only long enough to allow for an orderly
phasing out of the algorithm to the point where negligibly
few peers require continued support.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 26 Jul 2015 23:39:35 +0000

On Mon, Jul 20, 2015 at 04:48:49AM +0000, Viktor Dukhovni wrote:

>     [...]

Continuing with material that follows after 2.9:

Section 3.1 first paragraph:

    The sentence:

       It seems like the ability to use an algorithm of one's own
       choosing is very desirable; however, the selection is often
       better left to experts.

    is rather imprecise.  I would suggest something more concrete:

	Explicit selection of concrete cryptographic algorithms
	should generally not be left to end-users.  Rather, end-users
	might select between configuration profiles defined by
	experts.

    The next sentence is too confusing to suggest improvements:

	  Further, any and all cryptographic algorithm choices
	  ought not be available in every implementation.

    The rest of the first paragraph:

	s/that it has/that has/
	s/has alway had/has always had/

    The last sentence of the same paragraph:

	In addition, inclusion of too many alternatives may add
	complexity to algorithm selection or negotiation.

    might be better as:

	Finally, standardization of too many alternatives will
	likely hamper security and interoperability.  When
	standardizing new algorithms it is prudent to consider what
	existing algorithms need to deprecated to make room for
	the new.

    [ For example, I'd like to see deprecation of many legacy DNSSEC
      algorithm code points, once new code points appear based on
      CRFG's new curves. (Of the existing algorithms, I'd keep only
      RSASHA256(8) and ECDSAP256SHA256(13)). ]

Last paragraph of 3.1:

	s/Sometime/Sometimes/
	s/depending of/depending on/

Last paragraph of 3.4:
	
	s/roll out/roll-out/  (the first is the verb, the second the noun).

Section 3.4:

    Amen for disabled by default "national" algorithms.  It would
    be nice to explicitly see this recommendation for GOST in DNSSEC,
    SEED in TLS, ...

Section 4:

       Sometimes application layer protocols can make use of transport layer
       security protocols, such as TLS [RFC5246] or DTLS [RFC6347].  This
       insulates the application layer protocol from the details of
       cryptography, but it is likely to still be necessary to handle the
       transition from unprotected traffic to protected traffic in the
       application layer protocol.  In addition, the application layer
       protocol may need to handle the downgrade from encrypted
       communication to plaintext communication.

    What's the relevance of a possible transition from cleartext
    to encryption (and perhaps back again???).

Overall:

    I found the document to be too "hand-wavy".  I think that it
    could be shorter by leaving out more text where no specific
    recommendations are or can be made.

    The wording could use a lot more polish, my list of nits is
    far from comprehensive.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Mon, 27 Jul 2015 14:40:21 -0500

> algorithms should fit into the definition.

If OS means "upgrade from cleartext when you can" (it does), then
failing to use weak crypto -> fallback on cleartext.

Even using 1DES is better than cleartext: because if everyone were using
1DES then the cost of massive eavesdropping (gather ciphertexts,
cryptanalyze) goes up significantly.

The key thing is that weak crypto must not lead to real-time exploitable
downgrade attacks.

Now, perhaps OS should mean "upgrade from cleartext when you can, but
fail if weak crypto is selected" (i.e., no fallback on cleartext).  But
then we have to have two OS definitions, one for SMTP, and one for other
protocols: because after all we do want [some, e.g., to postmaster]
e-mail to flow no matter what.  And even so, remember that the user
would gladly use no crypto if none is offered, so I don't think this
makes sense.

Think of OS as a migration strategy.  If we make the jump from cleartext
to encrypted too difficult/expensive, then we'll fail to complete the
migration.  Spurious failures resulting from attempting to upgrade could
mean failure to migrate: because users will simply turn off OS.  Yes, OS
could be required-to-be-enabled, thus preventing this social failure
mode, but we're still far from that.

Permitting weak crypto (with the above downgrade caveat) with OS is
rather necessary then.  We can only forbid weak crypto in OS
applications when the market share of such crypto is negligible.

Nico
--

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 27 Jul 2015 20:54:50 +0100

Hiya,

<hats-off>

> The key thing is that weak crypto must not lead to real-time exploitable

I think this nicely captures a point where we can have a real
disagreement about OS.

I would prefer if we could agree that:

   OS use of weaker crypto must not allow feasible off-line
   deciphering of ciphertext, no matter the adversary within
   the likely duration for which the average plaintext is
   sensitive.

According to the above, 1DES and export ciphers would be completely
out of the question. And rc4 is getting really really close.

And that's completely different to your quoted text above.

<hat-back-on>

I'm not sure we'll reach rough consensus on either side of this
argument though so we may be reduced to silence on the hard part of
the question.

Cheers,
S.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 27 Jul 2015 20:17:31 +0000

On Mon, Jul 27, 2015 at 02:40:21PM -0500, Nico Williams wrote:

> We can only forbid weak crypto in OS applications when the market share
> of such crypto is negligible.

For the particular application in question.  Thus already for email
we can safely forbid "export" ciphers, SSLv2 and 1DES.  

It also looks like we can also forbid SSLv3.  The most recent report
of SSSv3-only domains on postfix-users (some banks in Western Europe)
was in Sep 2013:

    http://postfix.1071664.n5.nabble.com/Anyone-use-this-email-server-configuration-td61045.html#a61373

With all the publicity about SSLv3 since, I am optimistic that if
they've not upgraded yet, they will soon.  Thus Postfix official
releases no longer support SSLv3 in OS connections by default
(impact of doing so is finally negligible).

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Mon, 27 Jul 2015 15:29:27 -0500

>    the likely duration for which the average plaintext is

Not quite right.  How about:

   OS use of weaker crypto must not make downgrade attacks feasible on
   non-OS implementations.  In particular the Logjam attack (or variants
   of it) must be infeasible.

   [Insert suitable reference to / description of the Logjam attack.]

Because even for OS applications, really, really weak crypto is still
better than cleartext (the identity function being the weakest crypto).

The key is that offering really weak crypto at all must not compromise
non-OS users of the same protocol.

> out of the question. And rc4 is getting really really close.

In my construction the only crypto that's off-limits is that which
permits the Logjam attack.

> argument though so we may be reduced to silence on the hard part of

Well, look, I made a specific argument as to OS being a migration
attempt that will be harmed by spurious failures.  That needs to be
addressed.  With that addressed, if we end up on the rough side then so
be it, but that argument must be acknowledged and addressed -- it would
not be right to just ignore it.

I'd go further: even if we decide to reject this argument, it should be
acknowledged in the I-D and the rationale for rejecting it should be
included, because implementors and future researchers/engineers may
benefit from having that argument and counter-arguments easily
available.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 27 Jul 2015 15:30:15 -0500

> of SSSv3-only domains on postfix-users (some banks in Western Europe)

Right, because the negative impact of forbidding those is negligible.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 27 Jul 2015 20:31:36 +0000

> out of the question. And rc4 is getting really really close.

The good news is that we don't need to agree on why they should no
longer be supported.  They are weak, and it is not supporting them
has no practical downside.  So they can go regardless of the
rationale.

I expect that by the time an algorithm supports practical
general-purpose offline plaintext recovery (which is a stronger
attack than the RC4 recovery of fixed plaintexts at fixed message
offsets sent millions of times) it will generally no longer be in
wide use, or will be in the process of rapid retirement.

So one way to put your argument is that if an algorithm goes from
safe to broken unexpectedly quickly and is not already in the
process of being phased out, it should be rapidly supplanted by a
better algorithm, allowing the broken algorithm to be rapidly phased
out, and as it is no longer needed for interop, it can be dropped
by OS clients.

So while we may disagree about what to do with RC4 in OS email
today, I agree that we'd let "export" and SSLv2 stick around longer
than necessary, and so in Postfix we've dropped these and 1-DES
and SSLv3, because we can and therefore should do so in a reasonably
timely manner.

-- 
	Viktor.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 27 Jul 2015 21:48:08 +0100

I'm not trying to argue against you or Nico but just to be
clear...

> wide use, or will be in the process of rapid retirement.

IMO, rc4 should already be consider unacceptable as I reckon
the probability of a full break whilst many ciphertexts are
still sensitive is too high. I still think that even given the
situation with email.

One difference between our positions is that I'm considering
the duration for which many plaintexts are likely still sensitive
and not only immediate decryption today (which is how I read you
and Nico's text).

Put another way, if we all agreed that rc4 can likely be routinely
deciphered in N years and if we further agreed that there are a lot
of plaintexts that will still be sensitive in N years, then there is
no great difference today between sending cleartext and rc4
ciphertext, when we consider highly capable adversaries who record
ciphertext, and we know those exist even if we do not know quite
how much ciphertext they record, for how long.

But I do recognise that there's enough scope in all of the above
for genuine differences of opinion and there is no certainty in
any of it, so we may have to live without consensus at that level
of detail.

S.

---

From: Nico Williams <[email-masked]>
Date: Mon, 27 Jul 2015 16:06:17 -0500

> how much ciphertext they record, for how long.

There is no great difference for _one_ connection.  There is a great
difference for _many_ connections.  I.e., even weak crypto makes
pervasive eavesdropping significantly more expensive.

That's not nothing.

I don't mind dropping weak crypto that [Viktor says] is insignificant
for SMTP _now_.  But the principle as stated earlier matters as a
principle.  Losing track of that principle may hurt us the next time
we want to deprecate a then-weak algorithm.

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 27 Jul 2015 21:14:42 +0000

> how much ciphertext they record, for how long.

There are two differences.  

    1. It seems unlikely that recovery of every captured RC4 stream
    will become practical, even if recovery of targetted streams
    becomes practical.

    2. After STARTTLS, failing to negotiate RC4 when the peer only
    supports RC4 requires "fallback", not just staying with cleartext
    (which happens when STARTTLS is not offered).  Not all peers
    support "fallback", and we want to avoid that anyway.  So if
    dropping (say) RC4 from OS leads to enough undeliverable email
    to make OS unattractive to users, we win the battle, but lose
    the war.

Fallbacks are bad, complicate code, and lead to various new downgrade
attacks.  It is better, to have an interoperable TLS stack, than
one that sets the bar too high, and then tries to recover by moving
it lower (often much lower than necessary and sometimes under
spuriously).

Avoiding "fallback" to cleartext (as opposed to not trying to do
encryption in the first place) is I think a greater priority than
avoiding weak algorithms when one happens to be encrypting.

-- 
	Viktor.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 27 Jul 2015 22:16:09 +0100

> pervasive eavesdropping significantly more expensive.

Well, I think there's still room for validly reaching different
conclusions about something like rc4 when we consider the various
parameters. (None of which we can really measure.)

Of course I fully agree with the OS approach, but I think we ought
recognise this wrinkle - there are going to be cases where it's
quite hard to do the evaluation of how to apply the OS design
pattern. 1DES is easy everywhere now, but rc4 for email is not
yet easy.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 27 Jul 2015 22:19:52 +0100

Hiya,

> avoiding weak algorithms when one happens to be encrypting.

Yep. I think you and I know one another's arguments:-)

I do agree your argument is tractable, but just don't agree with your
conclusion wrt rc4. I was in the rough last time we debated that and
probably still am.

S.

---

From: Nico Williams <[email-masked]>
Date: Mon, 27 Jul 2015 16:29:06 -0500

> parameters. (None of which we can really measure.)

Really?  The workfactor to cryptanalyze one RC4 session is so close to
2^0 that it wouldn't make a difference even to a pervasive monitor?

> pattern. 1DES is easy everywhere now, but rc4 for email is not

The principle is simple and stated earlier.  Again: don't enable a
Logjam attack, and otherwise allow any weak crypto that doesn't cause a
real-time downgrade attack on clients that could do better.  I.e., it's
all about the handkshake's security, not the application record security
(again, because the application would happily use cleartext).

(One counter-argument might be that it's difficult to analyze what
configurations lead to Logjam attacks, therefore better be safe than
sorry.)

Nico
--

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 27 Jul 2015 22:41:11 +0100

> 2^0 that it wouldn't make a difference even to a pervasive monitor?

My concern is that workfactor will be small enough in a few
years that mail traffic encrypted today will be essentially
treatable as cleartext by the most capable adversaries. While
the rc4 encryption will add some cost, I'm concerned that'll
be too small (again, in a few years).

> configurations lead to Logjam attacks, therefore better be safe than

I don't disagree with you that OS ought not enable logjam.

Cheers,
S.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 27 Jul 2015 21:48:26 +0000

> My concern is that workfactor will be small enough in a few years that mail
> traffic encrypted today will be essentially treatable as cleartext by the most
> capable adversaries. While the rc4 encryption will add some cost, I'm
> concerned that'll be too small (again, in a few years).

My timetable is shorter (two, not a few) but I agree.

The national-scale adversaries are already scooping up all traffic.

I used to be highly skeptical of post-quantum crypto, but now I want something like whyte's PQ mixin stuff today.

---

From: Nico Williams <[email-masked]>
Date: Mon, 27 Jul 2015 17:09:30 -0500

> The national-scale adversaries are already scooping up all traffic.

This is true, but remember that cryptanalyzing the identity function is
even easier...  The context here is OS -- don't lose that context.

Eventually between OS and DANE we should get to where we can just
require TLS for SMTP and eventually even authentication of servers.
Then indeed using stronger ciphers will matter more than in then context
of OS right now.

> I used to be highly skeptical of post-quantum crypto, but now I want
> something like whyte's PQ mixin stuff today.

Yes, sure, but one thing at a time.

Nico
--

---

From: ianG <[email-masked]>
Date: Tue, 28 Jul 2015 01:57:16 +0100

> failing to use weak crypto -> fallback on cleartext.

Right.  Dumb.  In popular parlance, cutting off your nose to spite your 
face.

> The key thing is that weak crypto must not lead to real-time exploitable

(I don't see that how that is possible?  Only weak protocols - with 
complexity or config or confused sysadms - can lead to a downgrade attack.)

> would gladly use no crypto if none is offered, so I don't think this

Right.  Much as we might be offended at weak crypto like DES1, it is 
better than plaintext.  And it makes no sense to ban DES1 in an OS 
system when the alternates are a binary of {nothing,full}.

If an OS system can be attacked with an MITM because it is, at the end 
of the day, OS, then trying to force unbreakable crypto is missing the 
point.

> mode, but we're still far from that.

It is much easier to upgrade weak crypto to strong crypto than to 
upgrade plaintext to any crypto.  It is much easier to first upgrade to 
OS, and then as a second step upgrade to stronger protocols such as 
non-OS with non-weak crypto.

> applications when the market share of such crypto is negligible.

Even then, the only reason to ban an algorithm is to reduce support 
costs.  It's not like say full scale TLS where we are making a claim 
that the stuff is strong, and properly implemented, there are ZERO 
WEAKNESSES.

If OS is always a half-way house, we don't care that much about which 
wall falls down - the crypto or the auth.  Let market forces push the 
upgrade to newer versions.

iang

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 28 Jul 2015 01:30:20 +0000

On Tue, Jul 28, 2015 at 01:57:16AM +0100, ianG wrote:

> Right.  Much as we might be offended at weak crypto like DES1, it is better
> than plaintext.  And it makes no sense to ban DES1 in an OS system when the
> alternates are a binary of {nothing,full}.

I agree on the theory, but the practice is a bit more nuanced post
Logjam.

I think it is fair to say that Logjam falls into the class of
protocol weaknesses.  in this case lack of a means in TLS to
negotiate FFDH parameters, and clients not having the code or UI
to check for unreasonably server-chosen DH groups).

Since it is difficult to predict exactly how protocol issues interact
with weak cipher suites, it makes sense to adjust the practice to
reduce the attack surface to just what's needed in practice.

So these days, OS software developers should strive to give their
users sensible defaults that omit needless options (whose absence
no longer requires cleartext fallback to interoperate with a
non-negligible set of peers).  Administrators of systems running
less than up-to-date software, may need to make appropriate
configuration adjustments to disable algorithms that are past their
use-by date in more recent software releases.

> If an OS system can be attacked with an MITM because it is, at the end of
> the day, OS, then trying to force unbreakable crypto is missing the point.

But leaving useless crud enabled, that does not enhance interoperability
is also unwise.  So the middle ground is to find the right balance.
And without difficult to perform full internet scans (for IPv4
still somewhat viable) it becomes a matter of judgement as to when
algorithm seems sufficiently disused to warrant dropping support
in an OS context.

I am doing the best I know how to give Postfix users sensible
default configurations.  Many other MTAs just punt all such decisions
to users.

So the essential take-aways from this sub-thread of relevance
to draft under discussion are I think:

    * OS for new applications should be legacy-free at inception.
      If there's no legacy installed base, specify the use of
      only the latest-greatest protocol versions, ciphers, ...

    * For widely deployed applications, support legacy algorithms
      and protocols while they are needed for interop, but not much
      longer.

    * Application developers (not just crypto toolkit providers)
      need to play a role in defining sensible default configurations
      that are appropriate for OS.  The crypto toolkit does not know
      about the requirements of the installed base for particular
      applications.

    * Administrators or downstream release engineering teams
      delivering the application to end-users, need some knobs to
      be able to adjust the algorithm and protocol selection at
      some point after the developer's default settings are chosen.
      Such knobs should be as simple as possible (difficult to mess
      up) since likely the the administrators or release engineers
      are neither application experts nor crypto experts.  They'll
      just follow some best-practice guide (with luck not a misguided
      one) that tells them what adjustments to make.

-- 
	Viktor.

---

From: Christian Huitema <[email-masked]>
Date: Tue, 28 Jul 2015 04:54:58 +0000

> to check for unreasonably server-chosen DH groups).

OS is by definition prone to MITM attacks, including downgrade attacks. Just negotiating any which algorithm key that comes out of the channel is too dangerous for my taste. If we do OS we should also enable a form of MITM detection, maybe channel binding. It will not be used in all OS connections, but using it in some connections in an unpredictable should be enough to detect and deter mass deployment of MITM.

-- Christian Huitema

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 28 Jul 2015 05:30:35 +0000

On Tue, Jul 28, 2015 at 04:54:58AM +0000, Christian Huitema wrote:

> OS is by definition prone to MITM attacks, including downgrade attacks.

[ Yes, when not authenticated.  There's also downgrade-resistant OS, via
  e.g. DANE, but not widely deployed at present. ]

> Just negotiating any which algorithm key that comes out of the channel is
> too dangerous for my taste. If we do OS we should also enable a form of
> MITM detection, maybe channel binding. It will not be used in all OS
> connections, but using it in some connections in an unpredictable should
> be enough to detect and deter mass deployment of MITM.

I agree this is desirable, but it is rather difficult to make MiTM
detection practical in many cases, e.g. email.  Sure one could log
channel-unique tags on both sides, but who's going to ever compare
them?

One might propagate the tags along the forward-path in new trace
headers, but those would need to be signed by the previous-hop MTA,
at which point, we're no longer talking about unauthenticated
opportunistic TLS.

The trick is finding a way to make it possible and worthwhile for
a sufficient fraction of participants to add the requsiite checks.
This can work for interactive protocols (humans on phone verbally
verify matching channel-ids), but is rather difficult for
store-and-forward.

For SMTP transport at least, DANE looks like a more promising
counter-measure to active attacks.

-- 
	VIktor.