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

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 24 Aug 2015 16:31:16 -0400

After reading through this thread again, I don't think we have clear
consensus to match statements being made in this draft in section 2.9:

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.

Maybe I'm in the rough, but I read through many varying opinions in
this thread, with contributors each having their own caveat to the
general statement, yet we have general statements in the OS RFC and
this draft.

The first sentence in this section counters what Viktor is saying was
intended in the OS RFC (per this thread), that this provision should
only apply to legacy systems.  When protocols are designed,
appropriate crypto should be specified.  Then it is better to use
outdated rather than nothing later on in deployment cycles.  Others
added in additional caveats to the general statement, so I don't think
we really have consensus on this set of points.

I'm personally okay with the concept that using deprecated algorithms
is better than nothing, but I'd rather it be clear that this choice is
not in compliance with current recommendations otherwise we will never
be able to complete transitions.  As such, I'd rather it not be part
of how we discuss OS since it only appears as a couple sentences in
the overall RFC.  As with S/MIME, this would just be a hold out due to
upgrade complications with older implementations - it's ok, but not
okay as part of OS giving it an excuse to stick around longer.

If others think I'm in the rough, it would be good to know.

Thanks,
Kathleen

On Tue, Jul 28, 2015 at 1:30 AM, Viktor Dukhovni <[email-masked]> wrote:
> 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.
>
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

-- 

Best regards,
Kathleen

---

From: Martin Thomson <[email-masked]>
Date: Mon, 24 Aug 2015 13:47:19 -0700

> If others think I'm in the rough, it would be good to know.

I think that you have it right.  New protocol work has different
deployment constraints with respect to security.  New stuff can (and
should) be encrypted always.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 24 Aug 2015 21:29:07 +0000

> we really have consensus on this set of points.

Yes.  OS is supposed to enable a transparent "upgrade" from cleartext
to encryption (possibly with peer authentication).

With *legacy* protocols, when negotiating unauthenticated opportunistic
encryption, it is important to not exclude recently obsoleted
algorithms that are still needed for interoperability lest failing
to offer them cause communications failure or needless use of
cleartext.

When designing new protocols, it makes sense to set a realistic
floor that excludes already deprecated crypto, and then not supporting
the obsolete algorithms does not risk failure to communicate or
needless use of cleartext.

-- 
	Viktor.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 24 Aug 2015 21:32:38 +0000

> encryption, it is important to not exclude recently obsoleted algorithms that
> are still needed for interoperability lest failing to offer them cause
> communications failure or needless use of cleartext.

And here, I think, is the rub.

SMTP is a legacy protocol.  Is opportunistically-encrypted SMTP a legacy protocol?  How long has it been in common use?  How old is the crypto that these deployed systems have access to?

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 24 Aug 2015 17:38:46 -0400

Sent from my iPhone

> SMTP is a legacy protocol.  Is opportunistically-encrypted SMTP a legacy protocol?  How long has it been in common use?  How old is the crypto that these deployed systems have access to?
I agree this is the problem/poster child for this discussion.  I'd rather phrase it that in some cases, deprecated crypto will be used when libraries/software can't be updated rather than saying it's okay because it falls into OS.  But this may just be me.

Thanks,
Kathleen

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 24 Aug 2015 21:40:22 +0000

> I agree this is the problem/poster child for this discussion.  I'd rather phrase it
> that in some cases, deprecated crypto will be used when libraries/software
> can't be updated rather than saying it's okay because it falls into OS.  But this
> may just be me.

It's not just you. :)

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 24 Aug 2015 22:45:41 +0100

>> can't be updated rather than saying it's okay because it falls into OS.  But this

And me too. However, there was strong push back to that from apps folks
when we debated this before. So even though I think all 3 of us are
correct, I think we're in the rough. But no harm validating that again.

S.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 24 Aug 2015 21:50:37 +0000

On Mon, Aug 24, 2015 at 09:32:38PM +0000, Salz, Rich wrote:

> SMTP is a legacy protocol.  Is opportunistically-encrypted SMTP a legacy
> protocol?

Yes.

    http://tools.ietf.org/html/rfc2487  (January 1999)

TLS support for Postfix (patch-set from Lutz Jaenicke):

    https://github.com/vdukhovni/postfix/blob/master/postfix/TLS_CHANGES (initial version 1999/03/29)

> How long has it been in common use?

Somewhere between 12 and 15 years.  I call that "legacy".

Opportunistic TLS was added to Microsoft Exchange 2003, and further
extended in 2007.

Wietse adopted the unofficial patch-set into mainstream Postfix in
2005.  It had been merged into Postfix by various Linux distributions
prior to that.

> How old is the crypto that these deployed systems have access to?

The Windows 2003-based systems, which are still in use, only do
TLS 1.0 with RC4-{SHA,MD5}.  

Many older Linux systems still only have OpenSSL 0.9.8 and also
support only TLS 1.0, SSL 2.0 and SSL 3.0.  With no ECDHE.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 24 Aug 2015 21:56:28 +0000

> > can't be updated rather than saying it's okay because it falls into OS.  But this

Actually, both OS and legacy are necessary conditions.

If it is not OS, and is supposed to deliver strong rather than
best-effort security, then legacy or not, deprecated algorithms
need to be phased out rapidly.

If it is OS, and not legacy, then again no deprecated algorithms.
However OS + legacy (which implies impracticality of fast Internet-wide
upgrade) then obsolete algorithms linger-on for a while, but
eventually disappear from OS too, once hardware refresh cycles take
care of the laggards.

We've eliminated EXPORT crypto, DES, SSL 2.0 and SSL 3.0 for OS
for SMTP.  We've not yet eliminated RC4-SHA, but will I think in
a couple of years.

-- 
	Viktor.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 24 Aug 2015 22:01:51 +0000

> Somewhere between 12 and 15 years.  I call that "legacy".

I'd put the dates at 12 (Windows 2003) and 10 (Wietse's adoption in 2005), but that's still legacy.  Thanks for the timeline!

I think 10 years is long enough -- too long, actually -- but that's a separate discussion that I believe I've already lost.

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

---

From: David Misell <[email-masked]>
Date: Mon, 24 Aug 2015 23:17:06 +0100

It's only been 40 years since whit diffie and Martin Hellman wrote new directions in cryptography!

Best Regards,

Dave

[email-masked]
07710380044
misell.dave on skype

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 25 Aug 2015 07:26:53 +0000

Viktor Dukhovni <[email-masked]> writes:

>Opportunistic TLS was added to Microsoft Exchange 2003, and further extended
>in 2007.

It's not true opportunistic TLS (unless they've fixed it recently), it's "pay
a commercial CA to be allowed to do TLS", unlike pretty much every other MTA
I'm aware of which allows you to just set up and go without having to buy a
cert for each server.

(I'm not saying this as part of some anti-CA crusade, but to point out that
Exchange puts a considerable hurdle in the way of universal opportunstic TLS
for email.  To do opportunistic TLS with Postfix or most (all?) other MTAs,
you need just the MTA.  To do it with Exchange, you need the MTA plus
permission from a commercial CA to use TLS.  In the interests of getting hard
data for this, I wrote to Aaron Zauner, who did the TLS-with-SMTP survey, a
few days ago to ask if he has distinct stats for Exchange vs. everything else).

Peter.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 25 Aug 2015 13:43:33 +0000

> I'm aware of which allows you to just set up and go without having to buy a

Server side STARTTLS support, which is agnostic as to whether the
client is opportunistic or not, is available with Exchange 2003
and later.

Opportunistic TLS is supported in at least Exchange 2007 and later.
I don't recall what Exchange 2003 did outbound, I only recall
helping  Microsoft to design fixes for various issues prior to the
release of Exchange 2007.  Some flaws remain, but it is largely
workable without a CA tax.

> few days ago to ask if he has distinct stats for Exchange vs. everything else).

Inbound, Exchange does not and cannot know whether the client is
authenticating the server certificate or ignoring it.  Outbound,
there are still a few known defects, that I've communicated to
Microsoft, and will I hope be fixed at some point.

The most significant known issues are TLS handshake failure and
fallback to cleartext when:

    * The peer's certificate is expired.  Even though authentication
      is not required and it would be accepted from an untrusted
      issuer.

    * The peer's certificate chain has certificates signed with
      MD5.  Even if the only use of MD5 is in the self-signature
      of a root CA, and even for client cerficates which are
      solicited though the server does not use them.

    * The server's certificate uses SHA2-256, but the peer only supports
      TLS 1.0, or in any case fails to include SHA2-256 in the supported
      signature algorithms extension.

The last of these is a result of implementing RFC 5246 (TLS 1.2),
rather than what makes sense.  It looks like TLS 1.3 is on track
to be sensible in this regard (server-side handling of certificate
signature algorithms).

The majority of clients and servers don't run into the above
problems, but they do thwart STARTTLS for a non-negligible minority
of systems.

-- 
	Viktor.

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 25 Aug 2015 14:56:52 +0000

Viktor Dukhovni <[email-masked]> writes:

>authenticating the server certificate or ignoring it.

Argh, yeah, sorry, messed that one up, the issue was more with Outlook (i.e.
client-side) than Exchange (server-side), specifically the amount of pain
involved in configuring things to trust non-commercial-CA-issued certs.
Here's the 25-step process (which each step comprising several sub-steps, it's
pages and pages and pages of instructions) for Exchange 2010:

http://social.technet.microsoft.com/wiki/contents/articles/13916.how-to-use-a-self-signed-certificate-in-exchange-2010.aspx

Compare this to a cut&paste of:

openssl req -x509 -newkey rsa:2048 -nodes -keyout /etc/ssl/private/key.pem -out /etc/ssl/certs/cert.pem -days 3650 -subj '/CN=mail.example.com' 

(E&OE :-) for non-Exchange mail servers.

(I've long been an advocate of software auto-generating a key on install and
allowing the user to override it if they want further customisation, which
would probably make about, oh, 99% of things like this:

https://code.google.com/p/littleblackbox/

go away).

Peter.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 25 Aug 2015 15:16:32 +0000

> openssl req -x509 -newkey rsa:2048 -nodes -keyout /etc/ssl/private/key.pem -out /etc/ssl/certs/cert.pem -days 3650 -subj '/CN=mail.example.com' 

For Postfix,

    http://www.postfix.org/TLS_README.html#quick-start

it takes a one more 'postconf' command to actually turn on TLS
after the key and cert are generated:

    # dir="$(postconf -h config_directory)"
    # fqdn=$(postconf -h myhostname)
    # case $fqdn in /*) fqdn=$(cat "$fqdn");; esac
    # ymd=$(date +%Y-%m-%d)
    # key="${dir}/key-${ymd}.pem"; rm -f "${key}"
    # cert="${dir}/cert-${ymd}.pem"; rm -f "${cert}"
    # (umask 077; openssl genrsa -out "${key}" 2048) &&
      openssl req -new -key "${key}" \
	-x509 -subj "/CN=${fqdn}" -days 3650 -out "${cert}" &&
      postconf -e \
	"smtpd_tls_cert_file = ${cert}" \
	"smtpd_tls_key_file = ${key}" \
	'smtpd_tls_security_level = may' \
	'smtpd_tls_received_header = yes' \
	'smtpd_tls_loglevel = 1' \
	'smtp_tls_security_level = may' \
	'smtp_tls_loglevel = 1' \
	'smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache' \
	'tls_random_source = dev:/dev/urandom'

And the key/cert generation is done with a bit more finesse to set
a sensible umask, avoid clobbering previous key/cert files that
might be in live use, deal with Debian's "myhostname" in a file, etc.

> allowing the user to override it if they want further customisation.

I concur, but am a bit worried about low entropy at system build
time.

-- 
	Viktor.

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 25 Aug 2015 15:26:35 +0000

Viktor Dukhovni <[email-masked]> writes:

>I concur, but am a bit worried about low entropy at system build time.

Better to have at least low-entropy keys than no-entropy keys, which is the
alternative when users don't (or can't) generate keys themselves post-
install...

(The low-entropy issue is also largely a hypothetical one, in that people
worry about it without doing much measuring.  When I evaluated it, admittedly
many years ago, I found there was actually more entropy available after
something like a system restart because of all the nondeterminism introduced
by the boot process.  Same with provisioning embedded devices, if you generate
the keys externally on a high-entropy system when you're loading the firmware
onto a limited device you're getting better entropy than if you generated them
on-device.  In any case though, anything is better than fixed private keys,
which far too many systems use).

Peter.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 25 Aug 2015 15:44:12 +0000

> I don't recall what Exchange 2003 did outbound, I only recall helping
> Microsoft to design fixes for various issues prior to the release of Exchange
> 2007.  Some flaws remain, but it is largely workable without a CA tax.

This is important.  It means that for SMTP, OS really started in 2005 with Postfix and 2007 for Exchange?   If so, then there is really no need to support RC4.  STARTTLS, as Peter was saying, can imply more than just OS, as MS really wants a CA to be involved.  Since a principle tenet of OS is *unauthenticated* privacy, it appears that the discussion has conflated the two.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 25 Aug 2015 16:06:28 +0000

On Tue, Aug 25, 2015 at 03:44:12PM +0000, Salz, Rich wrote:

> This is important.  It means that for SMTP, OS really started in 2005 with
> Postfix and 2007 for Exchange?   If so, then there is really no need to
> support RC4.  STARTTLS, as Peter was saying, can imply more than just OS,
> as MS really wants a CA to be involved.  Since a principal tenet of OS is
> *unauthenticated* privacy, it appears that the discussion has conflated
> the two.

You're reading too much into the tea leaves.  Exchange as a server
supported inbound STARTTLS since 2003 and a non-trivial number of
deployed systems are of that vintage.  There was STARTTLS support
in Postfix as shipped in some Linux distributions, well before the
feature was officially adopted and improved by Wietse for Postfix
2.2 in 2005.

Yes, Exchange support for STARTTLS was improved (for outbound TLS)
in 2007.  However, exchange was not and is not a dominant edge MTA.
It is used inside networks a lot more than at the edge.

There is longstanding STARTTLS support in Sendmail, Qmail, Exim,
Ironport appliances, Kerio appliances, ...

STARTTLS for SMTP has a large deployed base, with many of the
systems running less-capable "vintage" software.  How long ago they
got there is not especially relevant.  Your conclusions about RC4
with SMTP are I'm afraid wishful thinking.

Users are having real issues delivering email to RC4-only systems.
Downgrading those to cleartext (and sometimes failing delivery
entirely) is not a win.  I'll deprecate RC4 in Postfix as soon as
possible, but not sooner.

In any case, whether it is RC4 now, or some other deprecated
ciphersuite in the futre, with opportunistic security one needs to
pay more attention to what interoperates than what is unequivocally
strong.  The goal is as much security as can be realistically had,
not "all or nothing".  I like to make an analogy with vaccination,
we're protecting the infrastructure as a whole, rather guaranteed
security for a particular flow.

-- 
	Viktor.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 25 Aug 2015 17:21:46 +0100

Viktor,

(Here we are back at this argument again:-)

> security for a particular flow.

Do you agree though that there are at least two points in time
involved when considering weakened or suspect ciphers?

There is the time you're discussing of when the bad algorithm
can be turned off without damaging interop of ciphertext form
packets.

But there is also the time after which one considers that all
such ciphertext will in a short while be almost the same as
plaintext for a capable attacker.

And the latter can happen before the former.

My argument (for which I still think I'm in the rough) is that
when we get to that 2nd point in time, one ought no longer use
a cipher even in OS mode.

Yes, that's a trade off, as are all OS arguments. For me the
continued use of a cipher that is that weakened is worse overall,
as that cipher is liable to be used in more environments that just
one. And yes, that does mean that some packets will be sent in
clear that would otherwise not be, but it also means that some
software will be updated sooner and hence other packets will be
sent as better ciphertext.

(And btw: In the specific case of RC4 the IETF does have consensus
to deprecate that already [1], even if the mail community let that
go by while pretending it wasn't happening:-)

Cheers,
S.

[1] https://tools.ietf.org/html/rfc7465

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 25 Aug 2015 16:24:28 +0000

> My argument (for which I still think I'm in the rough) is that when we get to
> that 2nd point in time, one ought no longer use a cipher even in OS mode.

I am not sure that you are in the rough.  I don't recall much support for the opposite viewpoint, other than my charming, voluble, and persistent OpenSSL colleague :)

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 25 Aug 2015 12:26:27 -0400

> security for a particular flow.

I'm not sure we have consensus and would like to see more opinions as
to what we collectively think the statements on OS should include.  I
don't think anyone is saying that bad crypto isn't better than no
crypto, but how we define OS and continue to use the definition may
matter for algorithm and cipher suite deprecation efforts.  It's long
been a practice for legacy systems to continue to use deprecated
protocols, algorithms and cipher suites, but we've said they are not
in compliance with RFCXXXX.  Do we really want to start down a path of
saying it's okay because it falls under OS?  I'd rather not.  We would
get to about the same result, but perhaps we could have more success
with deprecation transitions if these older options are not 'blessed'.

If others would like to offer their thoughts, it would be appreciated.
I know the specific argument around this was for RC4 and SMTP, but
let's think about the generalized statement and what we want that to
be going forward.

Thank you,
Kathleen

-- 

Best regards,
Kathleen

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 25 Aug 2015 16:55:40 +0000

Yes.

> plaintext for a capable attacker.

That could happen.

> And the latter can happen before the former.

Possibly.  More realistically I see multiple milestones (in some
order):

    1. Cipher becomes known weak.
    2. Cipher known not much stronger than cleartext.
    3. Cipher no longer required for interop.
    4. Cipher is not MTI and is rarely used.

With OS in Postfix, I'm willing to deprecate some ciphers once we
have 3 and 4, in some cases even before 1 and 2.  For example, I'm
considering by default not enabling DSS, fixed DH and fixed ECDH.
And have already posted a best-practice guide to the users list
advising users to do that.

> a cipher even in OS mode.

Introducing negotiation failures in OS, and requirement to support
cleartext fallback in is problematic.  Even if some ciphersuite is
effective a NULL cipher, it is better to negotiate that without
introducing a fallback dance.

> And yes, that does mean that some packets will be sent in

The nasty part is that cleartext fallback is not always desirable
or available.  Sendmail IIRC does not fall back after STARTTLS
handshake failure.

> go by while pretending it wasn't happening:-)

We're aware of the RC4 deprecation, and use of RC4 is declining,
we're just going to take a couple of years longer to get there.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 25 Aug 2015 13:39:39 -0400

> On Aug 25, 2015, at 12:26 PM, Kathleen Moriarty <[email-masked]> wrote:
> 
> to what we collectively think the statements on OS should include.

I thought we reached "rough" consensus on this point during the rather
intensive/extensive last-call discussions of the OS draft.  Specifically,
that even weaker ciphers are better than cleartext, and may need to
continue to be used if that's what it takes.

> I don't think anyone is saying that bad crypto isn't better than no

How to position deprecation is more of a marketing than a technical
question.  I agree that we don't want to dilute the message that
deprecated ciphers should be phased out as quickly as possible.
OS is not a license to indefinitely ignore deprecation.

The key issue is what "as quickly as possible" means.  For OS, it is likely
to mean that the process takes longer, because the relative priorities of
interoperability and security are different than with non-OS designs.

So by all means, publish unequivocal deprecation of RC4, ... but expect
that OS applications will take some time to act on such publications and
rightly so.

-- 
	Viktor.

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 25 Aug 2015 13:55:27 -0400

Sent from my iPhone

> On Aug 25, 2015, at 1:39 PM, Viktor Dukhovni <[email-masked]> wrote:
> 
> 

I don't this point was as clearly discussed in those threads, so I'd like to hear thoughts from the community.  Thank you for sharing your opinion.

If you think it was and have a pointer to the appropriate thread with adequate input to show support, please post it.  Otherwise, allowing others to chime in will be helpful.  I may be in the rough, but I'm not convinced of that with this thread so far.

Thanks,
Kathleen

---

From: Martin Thomson <[email-masked]>
Date: Tue, 25 Aug 2015 11:13:44 -0700

> If you think it was and have a pointer to the appropriate thread with adequate input to show support, please post it.  Otherwise, allowing others to chime in will be helpful.  I may be in the rough…

Since Kathleen asks so nicely, I'd like to register my disagreement
with Victor on this point.

There are compatibility reasons *today* that exist as a result of
having to interoperate with old software that was built or deployed
without due regard to security updates or continuous maintenance.

However, if we expect software to be updated in order to get
opportunistic security, then I don't think it unreasonable to also
expect it to be maintained on an ongoing basis.  A sudden once-off
isn't going to cut it if we want to prepare for the eventuality where
one of the current ciphers turns out to be irredeemably busted.

If you accept that software that is updated once can be continuously
maintained thereafter, then it's not a stretch to conclude that
deploying good ciphers is equally feasible.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 25 Aug 2015 19:07:03 +0000

On Tue, Aug 25, 2015 at 11:13:44AM -0700, Martin Thomson wrote:

> expect it to be maintained on an ongoing basis.

And SMTP servers are updated from time to time, but the refresh
cycles are fairly long and the incentives to care about encryption
are not great.

If we want people to encrypt for the common good, despite lack of
apparent benefit to them, we must not erect barriers to adoption
in the form of interoperability problems.  Obsoleting mainstream
ciphers has a major interoperability impact and takes time,
(especially RC4 which was rumoured better than CBC after CRIME and
BEAST, was the best cipher in Windows 2003, and outperformed the
alternatives in the absense of hardware support).

What RFC 7435 says is that OS systems can be more tolerant of
deprecated algorithms when interoperability considerations trump
the security analysis.  Such tolerance is not forever.

> deploying good ciphers is equally feasible.

Deployment of good ciphers is taking place, slowly.  In the mean-time,
there's email to be delivered, and users who rightly expect OS to
not get in the way.  Encryption is a nice-to-have.

    * Deliver the email
    * Encrypt if possible (RFC 3207, 7435)
    * Authenticate when requested by the peer
      (RFC 7435, SMTP DANE draft).

In practice, OS is working quite well, Google's outbound mail (which
is much less dominated by bulk mail ads than their inbound mail)
is now ~81+% encrypted, up from ~77% a year ago:

    https://www.google.com/transparencyreport/saferemail/

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 25 Aug 2015 21:44:11 +0000

> that OS applications will take some time to act on such publications and

I should note, that premature deprecation of algorithms and/or
protocol features by library maintainers who are not attuned to
the needs of OS applications is already having detrimental effects.

For example, LibreSSL 2.2.2 has not only removed support for SSL
2.0 and SSL 3.0, but has also removed TLS server support for
SSL-2.0-compatible HELLO.

This means that servers linked with LibresSSL are unable to complete
a TLS handshake with clients that have not yet disabled SSL 2.0
and are still sending SSLv2-compatible HELLO.

Such clients are not uncommon.  The Postfix user who ran into this
problem reverted to linking Postfix with OpenSSL.  In the OpenSSL
"master" branch (future 1.1.0), SSL 2.0 and SSL 3.0 are disabled
just like in LibreSSL 2.2.2, but support for SSLv2-compatible HELLO
is retained (on servers, but the client code will never send such
a HELLO).

It takes care and sound judgement to preserve interoperability,
and not all applications have the same needs.  So while the
"marketing" message needs to be clear and unequivocal (stop using
obsolete crypto), in libraries the underlying technical changes to
support that need to be constructed more carefully, and final
removal may be the last step of a process that happens across
multiple releases that gradually reduce support. 
    
    * Remove from use by default.
    * Reduce relative preference.
    * Require non-default compile-time options to enable.
    * Remove the code.

Applications can move more aggressively, and use appropriate APIs
to disable obsolete crypto faster because they are better positioned
to know where to draw the line between security and interoperability
with legacy systems.

-- 
	Viktor.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 26 Aug 2015 01:04:32 +0300

> On Aug 25, 2015, at 7:21 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Viktor,
> 

It depends on what that capable attacker is trying to do. If this adversary is attacking *your* communications, you’re right. If the adversary is attempting pervasive monitoring, this stage almost never comes. If every TCP connection today was encrypted with DES a capable attacker could decrypt any connection but not every connection. They couldn’t even decrypt 1% of all connections. So against an adversary engaging in pervasive monitoring, even single DES is significantly better than cleartext.

Yoav

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 25 Aug 2015 23:17:04 +0100

On 25/08/15 23:04, Yoav Nir wrote:
> It depends on what that capable attacker is trying to do. If this
> adversary is attacking *your* communications, you’re right. If the
> adversary is attempting pervasive monitoring, this stage almost never
> comes. If every TCP connection today was encrypted with DES a capable
> attacker could decrypt any connection but not every connection. They
> couldn’t even decrypt 1% of all connections. So against an adversary
> engaging in pervasive monitoring, even single DES is significantly
> better than cleartext.

Mostly fair point, though one might speculate as to whether RC4
may end up easier than single DES. (Actually, do we have any good
information about that? I guess there aren't many publications on
the relative weaknesses of weak ciphers.)

But it's also the case that OS aims to protect against passive
attacks and to force the adversary to be active. That property
of OS should still apply even if we're only talking about 1% or
0.0001% of all traffic and is lost if we have a somewhat patient
adversary who has enough meta-data to decide how to spider
through a large trove of weak ciphertext, which seems likely to
me.

So yes, very weak ciphers are still better than plaintext when
we consider easily searching the entire cache of recorded data,
but that is not the only property we want when applying the
OS design pattern. Being secure against a passive targeted
attack for as long as the application traffic remains sensitive
is also a goal of OS, I think. (Note: I'm not saying we can
be sure of that, but it is a goal.)

S.

PS: Even if we don't reach a snappy new statement of how OS
and weaker crypto play together, I think this discussion is
useful, for me at least.

---

From: "Paterson, Kenny" <[email-masked]>
Date: Tue, 25 Aug 2015 22:53:54 +0000

Hi

>the relative weaknesses of weak ciphers.)

This is something I can say a bit about.

Let's take TLS with DES and RC4.

To break a DES-protected connection aqap, you'd use an exhaustive key
search, needing a couple of known plaintext/ciphertext blocks (not a
problem for most application protocols running over TLS). Cost: a few
thousand dollars for the FPGAs; time: depends on budget of course, but
embarrassingly parallelisable. You've then got the key and can decrypt the
whole TLS connection.

To break RC4 in TLS, with the current public state of the art [1,2], you'd
somehow need to gather 2^26 - 2^30 encryptions of the same plaintext. That
can be done in some circumstances, e.g. malicious javascript running the
browser, with the target being HTTP cookie, but it's a bit of a stretch.
What you get back is that (short) plaintext, rather than the key.

So with the *current* state of the art, the attack requirements and attack
results are quite different. Despite the strict incomparability, I think
it's reasonable to say that DES is currently *much* less secure than RC4
in the TLS context.

What we don't know is how the attacks will evolve in future.

My guess is that the DES attack will not get any better in an interesting
way (that is, save for falling costs of hardware). DES is a good block
cipher with too small a key (and too small a block).

And it feels to me that, for RC4, the currently known public techniques
are starting to run out of steam. Maybe someone will come up with some
fresh ideas. Meanwhile, we don't really know the capabilities of
government agencies against RC4.

Cheers,

Kenny  

[1] http://www.isg.rhul.ac.uk/tls/RC4mustdie.html
[2] https://www.rc4nomore.com/

---

From: Nico Williams <[email-masked]>
Date: Wed, 26 Aug 2015 00:52:41 -0500

> And the latter can happen before the former.

We've been pwned, so we want that to stop, and the way we're choosing to
make it stop is to shoot ourselves in the feet.

Less rhetorically:

We know RC4 is weak and we want to use something else that's better
instead.  Clearly, we can ban RC4, but that isn't a magic wand that
makes everyone start using AES or what have you.  Still, we plow on
because hey, some TLS implementors will understand the SMTP OS situation
and won't break that application.  But! if we merrily write text telling
TLS implementors to remove RC4, many of them will, and in the process
they will make security/interop for SMTP demonstrably worse (as Viktor
has shown).

It seems we can't be moderate in how we approach cipher obsolescence,
perhaps because... we're embarrassed to have obsolete ciphers around so
long after they became obsolete?  That's not a good excuse for throwing
a big switch.  A good excuse for throwing the switch is any case where
merely offering weak crypto introduces a downgrade attack, but that's
not the case here.

"Look ma'!, we banned the bad thing" is clever marketing.  For a short
while.  "Look ma'!, we're getting off the old thing and onto the new,
and we're giving people time so we don't make things worst in the
short-term" is a mouthful and ma' will have to think about it before
deciding that we're doing the right thing, but it is the right thing.

We totally can live with an outright ban on RC4.  That not all TLS
implementors will adhere to.  Or accept the loss of security/interop for
SMTP.  If implementors willfully diverge from the spec, then the spec is
probably wrong.  If implementors faithfully implement a spec, and as a
result applications break, the spec is probably wrong.  The only hope
for an outright ban is that breakage causes people to go fix it.  But
with SMTP OS it's not always clear to users that there's breakage, and
when it is clear (mail won't flow) it isn't always easy to go fix it.

Nico
--

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 26 Aug 2015 10:42:10 +0100

Hi Nico,

> when it is clear (mail won't flow) it isn't always easy to go fix it.

I'm sorry but you're entirely ignoring the use of RC4 in the web
which was a very important part of this. While there may be a rump
of smtp servers that are broken and that won't upgrade soon, there
was a very large proportion of the web using RC4 before we deprecated
it, and now there is far less, with no breakage. (See Richard's
presentation at saag in Prague.) That change wasn't caused by us, but
we did the right thing to help it along with RFC7465.

Another of the lessons of OS (or rather, of more seriously considering
deployment realities) is that we sometimes need to think outside our
own silos. That goes for mail folks and web folks and others too.
(I'm not saying you're one or other of those, but your mail was very
silo-specific.)

S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 26 Aug 2015 10:54:46 +0100

On 25/08/15 23:53, Paterson, Kenny wrote:
> are starting to run out of steam. 

Thanks. I wasn't aware of that.

The only thing I'd add to your mail is that when you say that we don't
know how attacks will evolve, that's not quite true. We do know that
the attacks always get better, but we don't know by how much or when.

S.

---

From: "Paterson, Kenny" <[email-masked]>
Date: Wed, 26 Aug 2015 10:27:51 +0000

Hi

>Thanks. I wasn't aware of that.

To be clear: it's just my personal opinion, based on working on this
specific area for a while. We shouldn't ignore the possibility of smarter
people being attracted to the problem now and making progress with new
ideas.

>the attacks always get better, but we don't know by how much or when.

Agreed, and I'm now surprised I didn't write that myself ;-)

Cheers

Kenny

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 26 Aug 2015 10:48:07 +0000

>    * Require non-default compile-time options to enable.

That's more or less what I use, specifially, "make the option least-
preferred", then "require a custom compile", then "remove the code", with an
occasional "reinsert the &*)(($)@ code because some widely-used app is still
living 15 years in the past".

The problem with trying to handle backwards-compatibility is that the long
tail never actually reaches zero but instead tends toward some (non-zero)
constant of users who will never upgrade if they're not forced to.  This is
why you can't maintain backwards-compatibility for ever, some users have to be
forced to upgrade.  What I typically do is make something a compile-time
option that's not enabled in any standard build, so they have the option to
enable the deprecated behaviour at the expense of building and distributing
custom binaries to do so.  Suddenly the absolutely-impossible-can-never-be-
done upgrade magically becomes possible, because the cost of not upgrading has
become nonzero.  The trick is figuring out how nonzero to make it, and on
which time schedule.

Peter.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 26 Aug 2015 13:49:56 +0200

Hi,

> or available.  Sendmail IIRC does not fall back after STARTTLS

Yes that's right.  Instead you get a 403 4.7.0 TLS handshake failed. 
This is now happening all over the place, as it turns out, due to the
recent changes to the OpenSSL library involving dh processing.

Eliot

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 26 Aug 2015 13:50:43 +0000

> recent changes to the OpenSSL library involving dh processing.

With Logjam we don't have much choice but to break compatibility
with 512-bit DH, because we're mitigating a downgrade attack.

Are there many servers out there with 512-bit DH keys not only for
export ciphers but across the board?

Sendmail uses a single set of DH parameters, rather than one set
for export and another for non-export ciphers, and perhaps it was
not entirely uncommon to configure it to use 512-bit DH parameters
across the board.

The Sendmail DH code has incorrect assumptions and corresponding
internal documentation.  It assumes wrongly that TLS clients need
to configure DH parameters.  (Sendmail could avoid loading or
generating DH parameters when running as a client).  Sendmail should
have been using the OpenSSL DH parameter callback API, rather than
setting fixed parameters for both export and non-export ciphers.

Needless to say the TLS functionality in Sendmail does not appear
to be very actively maintained. :-(

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Wed, 26 Aug 2015 14:17:39 -0500

> I'm sorry but you're entirely ignoring the use of RC4 in the web

Not at all.  I'm arguing that rather than outright ban RC4 at the TLS layer
for all apps we should make it a SHOULD NOT use with guidance for various
applications.

> (I'm not saying you're one or other of those, but your mail was very

Exactly.

---

From: Derek Atkins <[email-masked]>
Date: Thu, 27 Aug 2015 09:35:04 -0400

> deploying good ciphers is equally feasible.

I disagree.  Most IT players I know set something up and basically don't
touch it unless something breaks.  They don't regularly update stuff
unless they have to (and I'll hand-wave at what indicates they "have to"
-- some people are definitely more proactive and a CVE might be enough
to trigger the update).  The fact that we're still seeing 12-year-old
software in deployment (Exchange 2003) seems to back up my point that
once stuff is deployed and "worked" it tends to be left alone.

My personal feeling that "some" crypto is better than "no"
crypto.... MOST of the time.  I think all of us would argue that "rot13"
is probably *not* better than no crypto.  So where do we draw the line
as to what's a step forward and what's a false sense of security?  Do we
draw the line at rot13?  RC4-40?  RC4-128?  DES?  3DES?

And once we agree that we need to have that line, does that line need to
move over time?  And how do we move that line?

Is there some way we can pop errors up the stack in a way that the end
users can be notified that something is wrong?  Just returning a "45x
Cipher Too Weak" SMTP error code isn't going to help, because I know of
nobody that actively monitors those logs sufficiently to even NOTICE
that they get that message.  Often you'll only start to check the logs
once you notice mail isn't flowing at all, and even then you'll only
really know for outbound email, not inbound email!

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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 27 Aug 2015 11:53:01 -0700

On 27 August 2015 at 06:35, Derek Atkins <[email-masked]> wrote:
> Most IT players I know set something up and basically don't
> touch it unless something breaks.

That is what needs to change.  I'm seeing evidence that it is changing.

---

From: Watson Ladd <[email-masked]>
Date: Thu, 27 Aug 2015 16:37:18 -0400

> we did the right thing to help it along with RFC7465.

Did we actually disable RC4 across the web? A closer investigation
reveals all the attacks will still work after the latest round of
browser changes: one just needs to forge a single packet to break the
first connection, until the browser incorrectly learns RC4
intolerance. Claims that only a small fraction of connections are
using RC4 miss the mark: the question is how many connections can be
fooled into using RC4.

At what point can we remove the code from OpenSSL? That's the endpoint
we should be aiming for.

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 27 Aug 2015 20:49:59 +0000

> At what point can we remove the code from OpenSSL? That's the endpoint

Code removal is I think at more than 2 years away.  Removal from
the DEFAULT cipherlist is already staged in the "master" branch
(upcoming 1.1.0 release in 2016).

Between that and removal of the code, is making it a non-default
compile-time option (along with single-DES).

-- 
	Viktor.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 27 Aug 2015 13:50:48 -0700

> At what point can we remove the code from OpenSSL? That's the endpoint

I expect this to progress roughly as follows (for Firefox, and in general):
1. announcement
2. disable, maybe with a way to manually override
3. disable with no override
4. disable this on the last of the servers
5. remove from the library

You are asking about step 5, which is important, but some of the
intermediate steps have a non-trivial benefit too.

The reason for step 4 is a little ugly.  We run openssl on our
download servers.  We want to offer Firefox downloads to users who
have old and busted browsers.  That means we need to be a little more
promiscuous on those servers than we might otherwise want to be.  That
means that we also don't do anything much of importance on those same
servers.

We want security updates too, so we want new versions of openssl that
will support us.  That means that openssl will likely support old and
crufty stuff for longer than you might think.

We still haven't disabled SSLv2 in NSS, but that's laziness.  The
reason will still have SSLv3 in NSS is in part due to step 4.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 27 Aug 2015 21:01:51 +0000

> The reason for step 4 is a little ugly.  We run openssl on our download
> servers.  We want to offer Firefox downloads to users who have old and
> busted browsers.

We have a similar issue at www.openssl.org.  I recently locked things down to get an A+ from SSLLabs.  This meant some folks had a harder time getting updates.  I pointed them to the FTP server.  And old, LTS python, doesn't do TLS very well.  I don't recall what they're going to do.