Subject: Re: [saag] AD sponsoring Effect of Ubiquitous Encryption

From: Julien ÉLIE <[email-masked]>
Date: Wed, 1 Feb 2017 21:33:42 +0100

Hi all,

> I plan to do my AD review of this shortly and then
> start an IETF last call. If you have comments in
> the meantime please do send them here.

I have a suggestion for Section 1 where I read:

    In addition to encrypted web site access (HTTP over TLS), other
    application level transport encryption efforts are underway.  This
    includes a push to encrypt session transport for mail (SMTP - gateway
    to gateway) and other protocols such as instant messaging (XMPP over
    TLS).

Shouldn't the document separate protocols that use explicit TLS 
(STARTTLS) and implicit TLS?
* XMPP over TLS is for instance only explicit:  STARTTLS is used on port 
5222 (Section 5 of RFC6120).
* HTTP over TLS is only implicit (on port 443).
* SMTP over TLS can be explicit (on port 25 or 587) or implicit (on port 
465).  Same thing for POP3 (explicit on port 110, implicit on port 995) 
and NNTP (explicit on ports 119 or 433, implicit on port 563) amongst 
other protocols.

The above quoted paragraph seems to mix all these uses.

Also note that implicit TLS is recommended per Section 3.2 of RFC 7525:

    o  In cases where an application protocol allows implementations or
       deployments a choice between strict TLS configuration and dynamic
       upgrade from unencrypted to TLS-protected traffic (such as
       STARTTLS), clients and servers SHOULD prefer strict TLS
       configuration.

-- 
Julien ÉLIE

« Ce n'est pas en tournant le dos aux choses qu'on leur fait face. »
   (Pierre Dac)

---

From: Eliot Lear <[email-masked]>
Date: Wed, 1 Feb 2017 23:55:44 +0100

Hi,

Just on this one point:

On 1/25/17 11:00 PM, Stephen Farrell wrote:

>>>
>>> - 2: I'm not at all sure encryption "prevents" load
>>> balancing, in fact I'm pretty sure it does not prevent that
>>
>> This was on the content.  Would you prefer to see it reworded/expanded?
> Yeah, I think saying prevents is just wrong. Encrypting does
> prevent some methods of load-balancing from working but not
> all methods. Ditto for other features that get changed. I do
> think it's important to not overstate the effects, just as
> it is to not understate them.
>
>
Being specific probably helps here.  For instance, encryption above L3
prevents "stickiness" based on the usual 5-tuple (a common form of load
balancing) the port information is not available.  The same is the case
with load balancing based on TCP sequence #s.  And the same is generally
true above L4 (e.g, based on application data) when the load balancer
resides in between the encryption endpoints (I say 'generally' because
the endpoints may provide some information as part of the TLS hello that
might prove useful).  It's probably worth taking a few minutes to survey
what methods are commonly deployed.

Eliot

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 2 Feb 2017 16:29:14 -0500

Hi Julien,

Thanks for your review.  Comments inline

On Wed, Feb 1, 2017 at 3:33 PM, Julien ÉLIE <[email-masked]> wrote:
> Shouldn't the document separate protocols that use explicit TLS (STARTTLS)
> and implicit TLS?
> 465).  Same thing for POP3 (explicit on port 110, implicit on port 995) and
> NNTP (explicit on ports 119 or 433, implicit on port 563) amongst other
> protocols.
>

I just read through the paragraph again and could make this change, as
the usage is not stated.  This draft doesn't specify best practices,
but acks current practices (which can be either explicit or implicit).
I just changed the sentences a little to make it clear that SMTP and
XMPP are both gateway-to-gatway (keeping this in as laymen's terms as
possible) and kept HTTP in the first sentence.  I know this doesn't
mention implicit or explicit, but is a little better per your
recommendation.  If you have alternate text options you'd prefer, let
us know.

NEW:
      In addition to encrypted web site access (HTTP over TLS), other
      application level transport encryption efforts are underway. This
      includes a push to encrypt session gateway-to-gateway transport for
      mail (SMTP over TLS) and other protocols such as instant messaging
      (XMPP over TLS).

>       STARTTLS), clients and servers SHOULD prefer strict TLS

Sure, and we (security directorate, Stephen & I) make sure that
reference shows up in drafts where use of TLS is specified.  This
draft doesn't define a protocol, so I'm not sure a reference here is
actually helpful.  Did you see a place where you thought it was a good
fit that I am missing?

Thank you,
Kathleen

> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 2 Feb 2017 16:38:24 -0500

Hi Eliot,

Thanks for your review and suggetsion.  Inline.

> what methods are commonly deployed.

I just took a look back at this section and the best way to do that
might be in a subsection under middle boxes.  Now, to survey,
operators are likely to be the best to assist with this question to
fully understand current deployment patterns.

Do you know who might be able to assist here with text or at least the
deployment patterns?  Maybe Joel or Rich copied have some ideas to get
this right?

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 2 Feb 2017 16:59:55 -0500

> On Feb 2, 2017, at 4:29 PM, Kathleen Moriarty <[email-masked]> wrote:
> 
> NEW:

FWIW, one might note that it appears that the SMTP effort is substantially
farther along than HTTP:

	https://www.google.com/transparencyreport/saferemail/
	https://nakedsecurity.sophos.com/2016/10/18/halfway-there-firefox-users-now-visit-over-50-of-pages-via-https/

and that perhaps another formulation could have been:

     In addition to encrypted MTA-to-MTA email transmission (SMTP over TLS),
     other application level transport encryption efforts are underway.
     This includes a push to encrypt web site access (HTTP over TLS) and
     gateway-to-gateway transport for protocols such as instant messaging
     (XMPP over TLS).

Of course the order is by no means critical, and application "prominence"
is no less valid a sorting criterion than adoption progress.  I just hope
that readers don't walk away with the impression that adoption in the
non-HTTP space trails adoptions in HTTP.

> actually helpful.  Did you see a place where you thought it was a good

There are also some advantages in doing STARTTLS.  For example, Postfix
is often able to detect split TLS session caches behind L4 load-balancers
by observing differences in the server identity reported in the EHLO reply.
This makes for much more effective TLS session caching.

The case for "implicit" TLS for MTA-to-MTA SMTP is not very compelling.

-- 
	Viktor.

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 3 Feb 2017 13:17:18 -0500

Hello,

Thanks for the additional comments, inline.

>      gateway-to-gateway transport for protocols such as instant messaging

I think the first sentence saying 'underway' is probably causing your
reaction, I suspect, and that's fair.

> non-HTTP space trails adoptions in HTTP.

Sure, fair point.  What about the following that considers your point.

    In addition to encrypted web site access (HTTP over TLS), other
    well-deployed application level transport encryption efforts. This
    includes mail transfer agent (MTA)-to-MTA session encryption
    transport for email (SMTP over TLS) and gateway-to-gateway for
    instant messaging (XMPP over TLS).
> The case for "implicit" TLS for MTA-to-MTA SMTP is not very compelling.

Sure, but I don't see a reason to add text on implicit TLS into this
section, do you?

If you have info on load balancers and could help with text per
Eliot's question in this thread, that would be much appreciated.

Thank you,
Kathleen

-- 

Best regards,
Kathleen

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 3 Feb 2017 18:33:15 +0000

> > balancing) the port information is not available.  The same is the
> > case with load balancing based on TCP sequence #s.  And the same is
> > generally true above L4 (e.g, based on application data) when the load
> > balancer resides in between the encryption endpoints (I say
> > 'generally' because the endpoints may provide some information as part
> > of the TLS hello that might prove useful).  It's probably worth taking
> > a few minutes to survey what methods are commonly deployed.
> 
> I just took a look back at this section and the best way to do that might be in a
> subsection under middle boxes.  Now, to survey, operators are likely to be
> the best to assist with this question to fully understand current deployment
> patterns.
> 
> deployment patterns?  Maybe Joel or Rich copied have some ideas to get this
> right?

Sorry for the delay in responding.

For better or worse, the SNI value in TLS hello is plaintext and I know some boxes use that for LB stickiness.

Beyond that, I don't have much to offer.  I think we should get folks from some of the HW companies to offer some text?

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 3 Feb 2017 14:08:13 -0500

> On Feb 3, 2017, at 1:17 PM, Kathleen Moriarty <[email-masked]> wrote:
> 
>> ... perhaps another formulation could have been:
>> 

Some words must not have made it from thought to keyboard in the above.
Would you care to amend the second clause of the first sentence?

> Sure, but I don't see a reason to add text on implicit TLS into this

Not especially, all I am saying is that we should not be overly
disparaging STARTTLS, it has some merit.

> Eliot's question in this thread, that would be much appreciated.

Sadly, I don't have anything profound to say about load-balancers.
I've just had to work around the limitations of a small number of
variants.

The observation about split TLS session caches is that in a naïve
implementation each actual server behind a load-balancer will have
its own rTLS session cache and/or its own session ticket decryption
keys.  This rather breaks session resumption, especially for clients
that cache sessions for more than just a quick burst of connections
(short-term "sticky" LB may work for those).

The gmail MX hosts are load-balanced, but they have shared session
ticket keys, and a fixed EHLO response server id:

	S: 250-mx.google.com at your service, [<client IP>]

this is one example of a working unified server TLS cache, despite
the presence of load-balancers.

With outlook.com, for example, on making two connections I get:

    1. S: 250-SNT004-MC10F16.hotmail.com (3.21.0.266) Hello [<client IP>]

    2. S: 250-SNT004-MC8F2.hotmail.com (3.21.0.266) Hello [<client IP>]

For better or worse, Postfix will assume a split cache, and only reuse
TLS sessions when hitting the same server.  After 5 more connections I
again see:

    ...

    7. S: 250-SNT004-MC10F16.hotmail.com (3.21.0.266) Hello [<client IP>]

So, under load, session re-use may kick in after a client accumulates session
tickets from sufficiently many outlook.com (aka hotmail.com) peers.

-- 
	Viktor.

---

From: Julien ÉLIE <[email-masked]>
Date: Fri, 3 Feb 2017 22:12:23 +0100

Hi Kathleen,

> actually helpful.  Did you see a place where you thought it was a good

Maybe in Section 2:

    The EFF reported [EFF2014] several network service providers taking
    steps to prevent the use of SMTP over TLS by breaking StartTLS,
    preventing the negotiation process resulting in fallback to the use
    of clear text.

A reference to Section 3.2 of RFC 7525 could be added (about SSL Stripping).
Incidentally, shouldn't "StartTLS" be written "STARTTLS"?

Also, Section 7 mentions a similar attack:

    There has already been documented cases of service providers
    preventing STARTTLS [NoEncrypt] to prevent session encryption
    negotiation on some session to inject a super cookie.

-- 
Julien ÉLIE

« Quand tu auras lu ces lignes, le papyrus s'autodétruira. »
   (Astérix)

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 3 Feb 2017 16:18:49 -0500

Thanks, Julien.

inline

> Incidentally, shouldn't "StartTLS" be written "STARTTLS"?

Done and thanks for the suggestion.  I thought you were looking for
more, but this works well.
>    negotiation on some session to inject a super cookie.

OK, since the reference is earlier, I didn't insert it here.

Thank you,
Kahtleen

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 3 Feb 2017 16:20:14 -0500

Hi Rich and others with load balancer experience.

> Beyond that, I don't have much to offer.  I think we should get folks from some of the HW companies to offer some text?

OK, thank you.  If you know of someone to ask, please let me know
(direct is fine) and I'll reach out.

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 3 Feb 2017 16:28:48 -0500

Hi Viktor,

Thanks again, response inline.

> Would you care to amend the second clause of the first sentence?

Oh, you are right, thanks.  How about:

    In addition to encrypted web site access (HTTP over TLS), other
    well-deployed application level transport encryption efforts such as
    mail transfer agent (MTA)-to-MTA session encryption
    transport for email (SMTP over TLS) and gateway-to-gateway for
    instant messaging (XMPP over TLS).

It makes for a longer sentence than I'd like, but covers the points.

> disparaging STARTTLS, it has some merit.

Oh sure, I agree.

> I've just had to work around the limitations of a small number of

OK, I'll try a bit harder to round up experts to chime in with text.

> tickets from sufficiently many outlook.com (aka hotmail.com) peers.

I can glean some from here, but not enough for a section, so I'll look
to see if I can find an expert or two specific to load balancers.

Thank you,
Kathleen

-- 

Best regards,
Kathleen

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 3 Feb 2017 16:39:29 -0500

> On Feb 3, 2017, at 4:12 PM, Julien ÉLIE <[email-masked]> wrote:
> 
> Maybe in Section 2:
> 

Note that STARTTLS is both a mechanism for engaging the use of TLS
and a means to provide both TLS and cleartext service at a single
transport endpoint.  When STARTTLS is used opportunistically, it is
of course subject to a "STARTTLS stripping" downgrade attack.

However, downgrade attacks are not limited to STARTTLS.  For services
such as POP and IMAP there are often separate non-TLS ports, and
suitable application (auto?)configuration may still fallback to
cleartext (on an alternate port) in the apparent absence of TLS service.

So the question of whether TLS is "strict" or "opportunistic", is
logically separate from whether it is "implicit" (TLS, then application
protocol) or "explicit" (application protocol, then STARTTLS).

Opportunistic TLS is of course subject to downgrades, absent downgrade-
resistant out-of-band capability signalling (e.g. DANE TLSA RRs).

Given downgrade-resistant signalling, there are no downgrade issues
with "STARTTLS" that are absent in "implicit TLS".

We should not confuse correlation (some opportunistic services use
STARTTLS) with causation (STARTTLS is not secure against active attack).
What falls to active attack is opportunistic use of TLS in the absence
of downgrade-resistant capability signalling.  STARTTLS is just a way of
providing both the cleartext and encrypted service on a single port.
Applications can and do employ downgrade-resistant STARTTLS via local
policy, DANE, (STS, ...).

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 3 Feb 2017 16:47:04 -0500

> On Feb 3, 2017, at 4:28 PM, Kathleen Moriarty <[email-masked]> wrote:
> 

There's a missing verb or other words in the second clause.  So it
remains unclear what you're saying, the shorter version was otherwise
fine by me.

-- 
	Viktor.

---

From: [email-masked]
Date: Fri, 3 Feb 2017 21:18:48 -0500

Please excuse typos, sent from handheld device 

> On Feb 3, 2017, at 4:47 PM, Viktor Dukhovni <[email-masked]> wrote:
> 
> 

Yes, I did see that, thanks.  I preferred the combined sentences over any verb I came up with at the time.  I may tweak it again.

Thank you,
Kathleen

---

From: Margaret Cullen <[email-masked]>
Date: Sat, 4 Feb 2017 12:57:55 -0500

> It makes for a longer sentence than I'd like, but covers the points.

Do you mean “In addition to encrypted web site access (HTTP over TLS), _there are_ other well-deployed application level transport encryption efforts?

Margaret

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 13 Feb 2017 10:45:59 -0500

> Do you mean “In addition to encrypted web site access (HTTP over TLS), _there are_ other well-deployed application level transport encryption efforts?

Yes, thank you, Margaret!

-- 

Best regards,
Kathleen