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

From: "Ted Lemon" <[email-masked]>
Date: Mon, 24 Nov 2014 20:41:33 -0800

Ted Lemon has entered the following ballot position for
draft-dukhovni-opportunistic-security-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/

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

I'm generally in favor of this document, but there is something I feel
needs to be discussed.

Section 4 describes the use of OE with SMTP, using STARTTLS.   However,
it turns out that recently it's been discovered that this convention is
under attack by some ISPs:
https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks

It's pretty clear that this downgrade attack is inexpensive to do, and it
does exactly what a passive attacker would want: it defeats OE.   If OE
is that easily subverted, what good is it?   I don't see the current
document touching on this issue: instead, it simply accepts that this is
true, but ignores it as an issue, asserting that MITM attacks are
expensive, so OE helps.   I think the facts on the ground show that this
is not so.

---

From: Pete Resnick <[email-masked]>
Date: Mon, 24 Nov 2014 22:53:58 -0600

> expensive, so OE helps.   I think the facts on the ground show that this

How cheap is it for an ISP to make you its customer? MiTM attacks are 
way more expensive than passive attacks.

It is no doubt true that on-path attacks can pretty straightforwardly 
defeat the encryption part of OS, but as section 3 says, the main 
benefit of encryption in OS is to prevent passive attacks, and that you 
need authentication to prevent the active (e.g. MiTM) attacks. The 
document directly addresses this point, so I'm not clear what's missing.

pr

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 25 Nov 2014 00:00:53 -0500

On Nov 24, 2014, at 11:53 PM, Pete Resnick <[email-masked]> wrote:
> How cheap is it for an ISP to make you its customer? MiTM attacks are way more expensive than passive attacks.

Actually no, MITM attacks that just prevent attempts to encrypt are not way more expensive than passive attacks.   Passive attacks are actually pretty expensive because of the need to store the data.   It is a very safe bet that if OE becomes widespread, we will see attacks of this type.

> It is no doubt true that on-path attacks can pretty straightforwardly defeat the encryption part of OS, but as section 3 says, the main benefit of encryption in OS is to prevent passive attacks, and that you need authentication to prevent the active (e.g. MiTM) attacks. The document directly addresses this point, so I'm not clear what's missing.

No, the document does not address this point.   It says that we can't prevent MITM without authentication, but it also says that OE is worth doing because MITM is expensive.   MITM on an OE link _is_ expensive for TLS, because you have to decrypt and re-encrypt the data.   However, it is _not_ expensive if you can just prevent encryption from happening at all.   The document doesn't really talk about this.  That's what I'm asking for.   I am _not_ saying the document is wrong or shouldn't be published, but it's going to be a real lame duck if it doesn't talk about this, given that the EFF is crying to the four winds about the STARTTLS issue (IMHO rightly so).

---

From: Pete Resnick <[email-masked]>
Date: Mon, 24 Nov 2014 23:42:13 -0600

On 11/24/14 11:00 PM, Ted Lemon wrote:
> On Nov 24, 2014, at 11:53 PM, Pete Resnick<[email-masked]>  wrote:
>    
> Actually no, MITM attacks that just prevent attempts to encrypt are not way more expensive than passive attacks.

But in order to do the kind of attack EFF is talking about, you have to 
be on-path. Getting on-path is more expensive than listening from off-path.

> Passive attacks are actually pretty expensive because of the need to store the data.

No need to store all the clear text, depending on your target. You can 
just scan for what you're looking for.

> It is a very safe bet that if OE becomes widespread, we will see attacks of this type.
>    

Of course. But the document already warns of the attack.

> No, the document does not address this point.   It says that we can't prevent MITM without authentication, but it also says that OE is worth doing because MITM is expensive.

No it doesn't. The document doesn't say anywhere that MiTM is expensive. 
It says in the intro that clear text makes passive monitoring easier 
because it makes it "cost-effective, or at least not cost-prohibitive", 
but it says nothing about the relative cost of MiTM. So I'm not sure 
what you're arguing against.

> MITM on an OE link _is_ expensive for TLS, because you have to decrypt and re-encrypt the data.   However, it is _not_ expensive if you can just prevent encryption from happening at all.   The document doesn't really talk about this.

You are correct that it does not talk about MiTM not being (very) 
expensive, But it does say:

    When encryption capability is
    advertised over an insecure channel, MiTM downgrade attacks to
    cleartext may be possible.  Since encryption without authentication
    only mitigates passive attacks, this risk is consistent with the
    expected level of protection.

> That's what I'm asking for.   I am _not_ saying the document is wrong or shouldn't be published, but it's going to be a real lame duck if it doesn't talk about this, given that the EFF is crying to the four winds about the STARTTLS issue (IMHO rightly so).
>    

I think you're going to have to point me toward where in the doc you 
might want text and what you think it might say to convince me that 
something's missing. The document acknowledges that MiTM downgrade 
(really lack-of-upgrade) attacks are possible, and that this is to be 
expected. The fact that it doesn't talk about relative expense for any 
of these attacks says to me that there's no need to add text saying that 
this particular attack happens to be cheaper than some others.

pr

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 25 Nov 2014 05:59:29 +0000

This "attack" has been discussed at length on various lists.  Indeed
opportunistic STARTTLS is easily defeated by active attacks.  It
addresses ONLY passive monitoring.  This is why I've invested a
year and a half of my life into building DANE TLS for SMTP.

However, not all is lost even without DANE:

  * Active attacks on everyone all the time are bound to be noticed.
    Attackers engaged in large scale passive monitoring might no
    longer be able to just collect everything, they'll have to be more
    selective.

  * In particular, substantial deviations from the norm are
    noticeable!  Look, for example the 90-day (default display is
    30 days, click on 90 for a longer-term view) outbound stats
    from gmail.  What happened around Oct 15th?

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

    Though Google are not saying what happened, and it may well
    not have been a downgrade attack, this sort of thing does not
    escape attention.

  * Some applications will employ various pinning strategies, and
    some sessions will be authenticated, and it is not always
    possible for the attacker to know which is which.

> expensive, so OE helps.   I think the facts on the ground show that this

Specific techniques for detection and mitigation of active attacks
in the absence of authentication are I think out of scope for this
document.  Individual application protocols may define additional
measures to make systematic downgrades less likely and once we have
more experience in this space future revisions may be able to make
generally applicable observations and recommendations.

The document encourages opportunistic protection against active
attacks too, and does not call itself OE in good part for that
reason.  If it were only OE, I would not have objected to Steve
Kent's draft as much, and we'd likely be polishing that (a lot
less work for me).

In a departure from a pure OE to thwart PM agenda, the draft
recommends negotiation of authentication (over already established
channels, via pinning, DANE, whatever), precisely because we should
do better than just unauthenticated, encrypted communication if at
all possible.

My personal view is that DANE is the way forward in that space,
but it is not yet mature enough to assert a strong claim along
those lines.  We have many years of operational obstacles to
overcome first (DNSSEC last-mile, nameserver bugs, registrar
interfaces, ...).

SMTP with DANE has seen some real deployment this year in Germany,
and if all goes well, deployment will grow beyond Germany's borders
in 2015.

-- 
	Viktor.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 25 Nov 2014 08:31:04 +0100

Hi Viktor and everyone,

Sorry to post during the IESG debate, but I have one observation and
perhaps a suggestion to move things forward.

>     not have been a downgrade attack, this sort of thing does not

First, my observation is that looking at quantity of messages only tells
one part of the story when it comes to encryption.  Rather the
percentage of sites is probably more important.  To put it another way:
if Netflix turned on IPv6, perhaps the majority of traffic in America
would shift to IPv6, but that wouldn't mean that the majority of hosts
or connections were.  In short, the method in the draft is somewhat
overstating the case.

> Kent's draft as much, and we'd likely be polishing that (a lot

My suggestion is simply that at some point in the draft, perhaps in
Section 4, you use as an example a reference to current STARTTLS
downgrade attack to reinforce the point that OS does not thwart active
attacks.  You could even mention, if you so chose, that a sneaky active
attacker might intercept SMTP transactions, and then encrypt them
upstream without authentication.  In fact, anyone doing this could
masquerade as the original endpoint because they are in path.  This
reinforces a point, that we really do need to get DANE out the door,
even if you don't actually say that.

Eliot

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 25 Nov 2014 09:42:51 +0000

Hi Ted,

On 25/11/14 05:42, Pete Resnick wrote:
> something's missing.

I think Pete's right there - suggested text here is going to be
much easier to deal with than trying to do this in the abstract.

As others have noted, messing about with STARTTLS gets noticed.
That is already a huge improvement over cleartext so that benefit
of OS even in the face of this attack is, I think, crystal clear
and the concern in your discuss is just unfounded.

I also think your extrapolation from that one issue with
STARTTLS and SMTP to questioning OS entirely ("what good is
it") ignores quite a lot and doesn't logically follow at all.
Even if OS had a problem with SMTP/STARTLTS, that cannot
by itself imply OS is just no "good."

But if you'd like to suggest text, perhaps there is something
we've missed that's needed. Or if you cannot, I think maybe
the right thing to do is to just clear, but we can talk about
it on the call later.

Thanks,
S.

PS: When suggesting text, if necessary please try use OS and
not OE :-)

---

From: Ted Lemon <[email-masked]>
Date: Tue, 25 Nov 2014 08:35:56 -0500

> generally applicable observations and recommendations.

The above two paragraphs, suitably tweaked and added to the security considerations section, would completely address the DISCUSS.  (And thanks for the longer exposition on the topic!)

---

From: Ted Lemon <[email-masked]>
Date: Tue, 25 Nov 2014 08:37:34 -0500

> PS: When suggesting text, if necessary please try use OS and

I'm still not over that.   I just don't see what Operating Systems have to do with opportunistic security.  :)

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 25 Nov 2014 09:08:51 -0500

Sorry to chime in late, but shouldn't this concern be covered already in the TLS Attack draft (I believe it is) from UTA?  I think this is better to have in that document with the security considerations of this draft pointing to that one.  Hopefully the reader will understand the attacks that apply to authenticated vs unauthenticated TLS.

Thanks,
Kathleen

Sent from my iPhone

> On Nov 25, 2014, at 8:35 AM, Ted Lemon <[email-masked]> wrote:
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 25 Nov 2014 14:19:22 +0000

Hiya,

On 25/11/14 13:35, Ted Lemon wrote:
>> Attackers engaged in large scale passive monitoring might no longer
>> be able to just collect everything, they'll have to be more 
>> selective.
> 
>> measures to make systematic downgrades less likely and once we
>> have more experience in this space future revisions may be able to
>> make generally applicable observations and recommendations.
> 
> The above two paragraphs, suitably tweaked and added to the security
> considerations section, would completely address the DISCUSS.  (And
> thanks for the longer exposition on the topic!)

Fair 'nuff - I've added a version to the RFC editor note.
We can chat about it on the call or feel free to suggest
changes.

Cheers,
S.

PS: I agree with Kathleen that the above points are maybe
redundant (perhaps mostly being in 7258) but I'm ok with
having 'em here too - it's no harm.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 25 Nov 2014 10:24:18 -0500

> Sorry to chime in late, but shouldn't this concern be covered already in the TLS Attack draft (I believe it is) from UTA?  I think this is better to have in that document with the security consider…

The reason I want this mentioned in this draft is so that people don't read it and think "huh, they didn't address the STARTTLS hack, and they use STARTTLS as an example: do they have a clue?"   By explicitly discussing the attack and explaining why OS (!) is still worth doing, we eliminate the likelihood that someone might read the document that way.