mailing list archives

STARTTLS is a non-authenticated command (3501 [6.2.1]).

Am I correct in my reading that this means that you lose any ability  
to protect message data via TLS if PREAUTH is used?  In other words:  
was STARTTLS solely designed to protect authentication credentials  
(security) and not message data (privacy)?

I guess the workaround for a situation where you *could*  
preauthenticate based on connection factors/details, but still need  
message privacy, is to require some sort of dummy authentication  
(after initializing TLS layer).  Feels pretty hackish though.

michael

On Tuesday, 18 March 2014 21:13:05 CEST, Michael M Slusarz wrote:
> Am I correct in my reading that this means that you lose any 
> ability to protect message data via TLS if PREAUTH is used?  In 
> other words: was STARTTLS solely designed to protect 
> authentication credentials (security) and not message data 
> (privacy)?

Not at all. Once issued, STARTTLS protects everything, i.e. both your 
credentials and transfers of all messages.

> I guess the workaround for a situation where you *could* 
> preauthenticate based on connection factors/details, but still 
> need message privacy, is to require some sort of dummy 
> authentication (after initializing TLS layer).  Feels pretty 
> hackish though.

That's what you could get with AUTH EXTERNAL. Also, nothing prevents a 
server from going directly to PREAUTH if the whole connection is using 
SSL/TLS ("port 993") with client certificates.

I'm a bit confused by your message. How do you want to authenticate your 
user? Specifically, what's the use case where you can safely verify the 
user's identity, but cannot guarantee confidentiality of the connection 
stream?

Cheers,
Jan

-- 
Trojit?, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

Quoting Jan Kundr?t <jkt@flaska.net>:

> On Tuesday, 18 March 2014 21:13:05 CEST, Michael M Slusarz wrote:
>> In other words: was STARTTLS solely designed to protect  
>> authentication credentials (security) and not message data (privacy)?
>
> Not at all. Once issued, STARTTLS protects everything, i.e. both  
> your credentials and transfers of all messages.

Except as defined in base spec, STARTTLS is defined as "you are  
allowed to protect privacy ONLY if you protect authentication".  In  
the absence of a need to protect authentication, you can't protect  
privacy.

>> I guess the workaround for a situation where you *could*  
>> preauthenticate based on connection factors/details, but still need  
>> message privacy, is to require some sort of dummy authentication  
>> (after initializing TLS layer).  Feels pretty hackish though.
>
> That's what you could get with AUTH EXTERNAL.

Not a part of the base IMAP spec, which is what I was talking about.

> Also, nothing prevents a server from going directly to PREAUTH if  
> the whole connection is using SSL/TLS ("port 993") with client  
> certificates.

STARTTLS deprecated the use of port 993, which isn't an official IMAP  
port FWIW.  It hasn't really happened, but still is good to avoid and  
end users appreciate it when they don't have to have any knowledge of  
port number.

I wish this did work with the STARTTLS command (i.e. PREAUTH response  
after STARTTLS in the above situation).  Unfortunately that isn't part  
of the spec either.

> I'm a bit confused by your message. How do you want to authenticate  
> your user? Specifically, what's the use case where you can safely  
> verify the user's identity, but cannot guarantee confidentiality of  
> the connection stream?

Simple real-world example would be a machine on an internal network  
that is guaranteed to belong to a certain user.

I don't really care one way or another - mainly wanted to verify to  
myself that I wasn't missing a valid use-case.

michael

On Tuesday, March 18, 2014 9:46:29 PM CEST, Jan Kundr?t wrote:
> I'm a bit confused by your message. How do you want to 
> authenticate your user? Specifically, what's the use case where 
> you can safely verify the user's identity, but cannot guarantee 
> confidentiality of the connection stream?

Think about it this way. As a client author, how do you handle the case 
where the server sends you PREAUTH and you want to use TLS?

Arnt

On Tuesday, 18 March 2014 22:25:49 CEST, Michael M Slusarz wrote:
> Except as defined in base spec, STARTTLS is defined as "you are 
> allowed to protect privacy ONLY if you protect authentication".  
> In the absence of a need to protect authentication, you can't 
> protect privacy.

That's right. To my understanding, providing just these two options:

a) don't protect anything,
b) protect everything,

is much simpler than doing this in a more fine-grained manner, and the cost 
of forcing STARTTLS to happen earlier is negligible. But perhaps I'm 
missing something?

>> That's what you could get with AUTH EXTERNAL.
>
> Not a part of the base IMAP spec, which is what I was talking about.

The way I see it, IMAP delegates all means of authentication and 
authorization except the basic LOGIN (which is probably specified mainly 
for backward compatibility) to SASL, doesn't it? But you're of course right 
that it is not a mandatory part of the spec.

Besides, there's a reference to the EXTERNAL and an example of how to use 
it with STARTTLS right in the official IMAP RFC [1].

> Simple real-world example would be a machine on an internal 
> network that is guaranteed to belong to a certain user.

While I can imagine a scenario where an attacker can listen, but cannot 
spoof, I think that would be quite an artificial setup to be honest.

With kind regards,
Jan

[1] http://tools.ietf.org/html/rfc3501#section-6.2.1

-- 
Trojit?, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

On Wed, Mar 19, 2014, at 08:25 AM, Michael M Slusarz wrote:
> Quoting Jan Kundr?t <jkt@flaska.net>:
> > Also, nothing prevents a server from going directly to PREAUTH if  
> > the whole connection is using SSL/TLS ("port 993") with client  
> > certificates.
> 
> STARTTLS deprecated the use of port 993, which isn't an official IMAP  
> port FWIW.  It hasn't really happened, but still is good to avoid and  
> end users appreciate it when they don't have to have any knowledge of  
> port number.
> 
> I wish this did work with the STARTTLS command (i.e. PREAUTH response  
> after STARTTLS in the above situation).  Unfortunately that isn't part  
> of the spec either.

I can't understand how STARTTLS ever got floated as an idea.  It's totally insane.

Your hypothetical MITM just strips the "LOGINDISABLED" capability response, and anything saying that the server supports TLS, and the client goes ahead and sends the credentials in cleartext.  At that point the MITM does the TLS negotiation with the server and it can read everything without the server knowing.

The only way that STARTTLS has any value is if every client refuses to send credentials until TLS or equivalent protection is established - in which case STARTTLS is pointless, you might as well just go straight to encryption and avoid the round trip.

Bron.


-- 
  Bron Gondwana
  brong@fastmail.fm

On Tuesday, 18 March 2014 23:01:12 CEST, Arnt Gulbrandsen wrote:
> Think about it this way. As a client author, how do you handle 
> the case where the server sends you PREAUTH and you want to use 
> TLS?

Oops. Thanks for an excellent suggestion, Arnt. It turns out that Trojita 
silenty fails to establish encryption when the remote server greets us with 
an initial PREAUTH. That might lead to information leak (APPEND of 
messages, confirmation of mailbox names), but never to credentials being 
transmitted in plaintext (Trojita understands what PREAUTH is, and won't 
attempt to LOGIN or AUTHENTICATE in that case).

/me checks how to file a CVE...

With kind regards,
Jan

-- 
Trojit?, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

On Mar 18, 2014, at 5:04 PM, Bron Gondwana <brong@fastmail.fm> wrote:

> I can't understand how STARTTLS ever got floated as an idea.  It's totally insane.

Damn you and your 20/20 hindsight!  Care to lend us your waybac machine?  :-)

Anyway, if you think STARTTLS is horrific, you really don't want to know about the adventures surrounding the early implementations of AUTH ...

The bottom line is that breaking every existing IMAP client and server wasn't a practical way to move forward.  And the various authentication bits in IMAP rolled out just at the end of the 'naive' age of the 'we are all friends' internet.  They were (are) incremental improvements to the situation as it existed.  Breaking existing clients/servers was not an option.  The best you can hope for is to offer better alternatives, encourage adoption, and hope attrition eventually solves the problem.

Which it never will, but almost two decades after the fact, anyone using, or inflicting upon someone, an IMAP client that blindly issues LOGIN is perhaps deserving of their fate.  C'est la vie.

--lyndon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 817 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20140318/e96a3f06/attachment.sig>

On 3/18/2014 7:04 PM, Bron Gondwana wrote:
> On Wed, Mar 19, 2014, at 08:25 AM, Michael M Slusarz wrote:
>> Quoting Jan Kundr?t <jkt@flaska.net>:
>>> Also, nothing prevents a server from going directly to PREAUTH if
>>> the whole connection is using SSL/TLS ("port 993") with client
>>> certificates.
>> STARTTLS deprecated the use of port 993, which isn't an official IMAP
>> port FWIW.  It hasn't really happened, but still is good to avoid and
>> end users appreciate it when they don't have to have any knowledge of
>> port number.
>>
>> I wish this did work with the STARTTLS command (i.e. PREAUTH response
>> after STARTTLS in the above situation).  Unfortunately that isn't part
>> of the spec either.
> I can't understand how STARTTLS ever got floated as an idea.  It's totally insane.
>
> Your hypothetical MITM just strips the "LOGINDISABLED" capability response, and anything saying that the server supports TLS, and the client goes ahead and sends the credentials in cleartext.  At that point the MITM does the TLS negotiation with the server and it can read everything without the server knowing.

Except for clients that refuse to support LOGIN and non-STARTTLS. 
Thunderbird (IIRC, I haven't poked at this code in years) refuses to 
downgrade authentication from what is specified (so if the setting 
requires CRAM-MD5, it will refuse to use AUTH PLAIN or LOGIN to specify 
credentials), and also screams mightily if you said you're going to do 
STARTTLS but don't. We also have a nasty warning if you refuse to do 
both SSL and STARTTLS when configuring the account, although we will 
allow it. This does open the possibility of being able to MITM the 
connection startup, but I'll also point out that ssh has the same 
intrinsic weakness to permanent MITM as it is used in practice and this 
isn't generally seen as evidence that it's MITM-able.

Some authentication protocols also can't be MITM'd: client certificate, 
NTLM, and Kerberos (via GSSAPI) don't involve the username and password 
so the MITM server can't tell the server to move to the authenticated 
state and the client won't move. Granted, these authentication 
mechanisms are probably much less widspread than CRAM-MD5 or PLAIN or 
the ilk.
> The only way that STARTTLS has any value is if every client refuses to send credentials until TLS or equivalent protection is established - in which case STARTTLS is pointless, you might as well just go straight to encryption and avoid the round trip.
It's not entirely pointless. It means you don't have to specify if the 
connection is encrypted or unencrypted via magic out-of-band information 
(i.e., port number).

-- 
Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth

Bron Gondwana <brong@fastmail.fm> wrote:
> On Wed, Mar 19, 2014, at 08:25 AM, Michael M Slusarz wrote:
> >
> > STARTTLS deprecated the use of port 993, which isn't an official IMAP
> > port FWIW.

What do you mean by "official"? Have you seen RFC 6186?

> > It hasn't really happened, but still is good to avoid and end users
> > appreciate it when they don't have to have any knowledge of port
> > number.
>
> I can't understand how STARTTLS ever got floated as an idea.  It's
> totally insane.

Well RFC 2595 gives some reasons...

I get the impression that the UTA working group is likely to prefer
TLS-on-connect over STARTTLS.

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
Wight, Portland: Southwest backing south 4 or 5, occasionally 6. Slight or
moderate. Fair. Moderate or good.

>>>>> "BG" == Bron Gondwana <brong@fastmail.fm> writes:

BG> Your hypothetical MITM just strips the "LOGINDISABLED" capability
BG> response, and anything saying that the server supports TLS, and the
BG> client goes ahead and sends the credentials in cleartext.

The ietf consensus was that having every protocol which wants to use tls
require a second port number was impractical; that some mechanism was
required to support unencrypted and encrypted connections on a single port.

Clients can have OOB knowledge that tls must be used; many UIs have a
checkbox, config-file setting or the like to specify whether tls is
desired or required for a given server.  Clients configured to expect
starttls will abort if it does not work.

Servers also can require tls, even when using startls to initiate it,
for access to some or all resources.  TLS-level client authentication
probably is required to prevent a MITM unless the clients are all
configured to demand tls for said server.

Some servers (ipp servers are known to do this) also support recognizing
tls vs plaintext at the start of a session and doing the right thing.

In the specific case of imap, I'd prefer to configure servers to demand
starttls before permitting any authentication, and to inform the users
to configure their clients always to demand startls.

Perhaps with rfc 5054 support, where possible.

-JimC
--
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

On Wednesday, March 19, 2014 12:56:08 PM CEST, Jan Kundr?t wrote:
> Oops. Thanks for an excellent suggestion, Arnt. It turns out 
> that Trojita silenty fails to establish encryption when the 
> remote server greets us with an initial PREAUTH.

PREAUTH is a trouble magnet, IMNSHO. The protocol would have been better 
off without it.

Arnt

On Wed, Mar 19, 2014, at 12:39 PM, Lyndon Nerenberg wrote:
> On Mar 18, 2014, at 5:04 PM, Bron Gondwana <brong@fastmail.fm> wrote:
> 
> > I can't understand how STARTTLS ever got floated as an idea.  It's totally insane.
> 
> Damn you and your 20/20 hindsight!  Care to lend us your waybac machine?  :-)

So why is 993 deprecated rather than STARTTLS deprecated now?  STARTTLS is _still_ a bad idea.

We don't need a wayback machine to fix the future.

> Anyway, if you think STARTTLS is horrific, you really don't want to know about the adventures surrounding the early implementations of AUTH ...
> 
> The bottom line is that breaking every existing IMAP client and server wasn't a practical way to move forward.  And the various authentication bits in IMAP rolled out just at the end of the 'naive' age of the 'we are all friends' internet.  They were (are) incremental improvements to the situation as it existed.  Breaking existing clients/servers was not an option.  The best you can hope for is to offer better alternatives, encourage adoption, and hope attrition eventually solves the problem.
> 
> Which it never will, but almost two decades after the fact, anyone using, or inflicting upon someone, an IMAP client that blindly issues LOGIN is perhaps deserving of their fate.  C'est la vie.

Sadly, they're still out there - which is why FastMail doesn't allow port 143 at all.  Port 993 appears to be working in the real world[tm].

I'd be interested in seeing the actual stats for which clients can be convinced by a MITM to give up their credentials in plaintext in their default configuration.  Don't give me a checkbox which requires the user to actively increase the security level, because that won't work.  In fact, don't even give the user a dialog which allows them to send the password insecurely, because they will.

Not responding to a SYN on port 143 with an ACK...

Bron.

-- 
  Bron Gondwana
  brong@fastmail.fm

On Wed, Mar 19, 2014, at 02:24 PM, Joshua Cranmer wrote:
> On 3/18/2014 7:04 PM, Bron Gondwana wrote:
> > On Wed, Mar 19, 2014, at 08:25 AM, Michael M Slusarz wrote:
> >> Quoting Jan Kundr?t <jkt@flaska.net>:
> >>> Also, nothing prevents a server from going directly to PREAUTH if
> >>> the whole connection is using SSL/TLS ("port 993") with client
> >>> certificates.
> >> STARTTLS deprecated the use of port 993, which isn't an official IMAP
> >> port FWIW.  It hasn't really happened, but still is good to avoid and
> >> end users appreciate it when they don't have to have any knowledge of
> >> port number.
> >>
> >> I wish this did work with the STARTTLS command (i.e. PREAUTH response
> >> after STARTTLS in the above situation).  Unfortunately that isn't part
> >> of the spec either.
> > I can't understand how STARTTLS ever got floated as an idea.  It's totally insane.
> >
> > Your hypothetical MITM just strips the "LOGINDISABLED" capability response, and anything saying that the server supports TLS, and the client goes ahead and sends the credentials in cleartext.  At that point the MITM does the TLS negotiation with the server and it can read everything without the server knowing.
> 
> Except for clients that refuse to support LOGIN and non-STARTTLS. 
> Thunderbird (IIRC, I haven't poked at this code in years) refuses to 
> downgrade authentication from what is specified (so if the setting 
> requires CRAM-MD5, it will refuse to use AUTH PLAIN or LOGIN to specify 
> credentials), and also screams mightily if you said you're going to do 
> STARTTLS but don't. We also have a nasty warning if you refuse to do 
> both SSL and STARTTLS when configuring the account, although we will 
> allow it. This does open the possibility of being able to MITM the 
> connection startup, but I'll also point out that ssh has the same 
> intrinsic weakness to permanent MITM as it is used in practice and this 
> isn't generally seen as evidence that it's MITM-able.

I was almost impressed until I saw this:

GET /mail/config-v1.1.xml?emailaddress=brong%40fastmail.fm HTTP/1.1
Host: autoconfig.fastmail.fm
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 Lightning/2.6.4
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive

HTTP/1.1 200 OK
Server: nginx/1.4.4
Date: Wed, 19 Mar 2014 03:37:11 GMT
Content-Type: text/xml
Transfer-Encoding: chunked
Connection: keep-alive
X-UA-Compatible: IE=Edge
X-Frontend: frontend2

57b
<?xml version="1.0" encoding="UTF-8"?>

<clientConfig version="1.1">
  <emailProvider id="MessagingEngine">
    <domain>fastmail.fm</domain>
    <displayName>FastMail</displayName>
    <displayShortName>FastMail</displayShortName>
    <incomingServer type="imap">
      <hostname>mail.messagingengine.com</hostname>
      <port>993</port>
      <socketType>SSL</socketType>
      <authentication>password-cleartext</authentication>
      <username>%EMAILADDRESS%</username>
    </incomingServer>
    <incomingServer type="pop3">
      <hostname>mail.messagingengine.com</hostname>
      <port>995</port>
      <socketType>SSL</socketType>
      <authentication>password-cleartext</authentication>
      <username>%EMAILADDRESS%</username>
    </incomingServer>
    <outgoingServer type="smtp">
      <hostname>mail.messagingengine.com</hostname>
      <port>465</port>
      <socketType>SSL</socketType>
      <authentication>password-cleartext</authentication>
      <username>%EMAILADDRESS%</username>
    </outgoingServer>
    <instruction url="http://www.fastmail.fm/help/remote_email_access_server_names_and_ports.html">
      <descr lang="en">Server Names and Ports</descr>
    </instruction>
    <instruction url="http://www.fastmail.fm/docs/imap/thunderbird3.htm">
      <descr lang="en">Using FastMail with Mozilla Thunderbird 3.x</descr>
    </instruction>

  </emailProvider>
</clientConfig>

It made a secure connection to broker.thunderbird.net, but then fell back to an insecure connection to pick up the configuration.

As you can see, we're using a domain at FastMail which isn't 'fastmail.fm' for our IMAP endpoint (we host thousands of domains, we don't want to have thousands of IPs and SSL certs)

It would be trivial to respond to this query with the details of an SSL MITM host and then all bets are off.

GET /mail/config-v1.1.xml?emailaddress=brongondwana%40gmail.com HTTP/1.1
Host: autoconfig.gmail.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 Lightning/2.6.4
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive

HTTP/1.0 303 See Other
Location: http://guidetest.a.id.opendns.com/?url=autoconfig%2Egmail%2Ecom%2Fmail%2Fconfig%2Dv1%2E1%2Exml%3Femailaddress%3Dbrongondwana%2540gmail%2Ecom
Content-Length: 0
Date: Wed, 19 Mar 2014 03:44:04 GMT
Server: OpenDNS Guide

And then it fell back to the Mozilla ISP database, but there's no reason I couldn't have MITMed that and stolen the gmail creds too.  Thunderbird is pretty trivially fooled at setup time.

Bron.

-- 
  Bron Gondwana
  brong@fastmail.fm

Quoting Tony Finch <dot@dotat.at>:

> Bron Gondwana <brong@fastmail.fm> wrote:
>> On Wed, Mar 19, 2014, at 08:25 AM, Michael M Slusarz wrote:
>> >
>> > STARTTLS deprecated the use of port 993, which isn't an official IMAP
>> > port FWIW.
>
> What do you mean by "official"? Have you seen RFC 6186?

Nothing in there registering 993 to IMAP.  RFC 6335 registry agrees  
that it hasn't been "officially" reserved:

http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=imaps

But this is just arguing semantics.  Real-world: 993 (& 995) have  
universal knowledge as to their current use.

michael
A

Quoting Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>:

> On Wednesday, March 19, 2014 12:56:08 PM CEST, Jan Kundr?t wrote:
>> Oops. Thanks for an excellent suggestion, Arnt. It turns out that  
>> Trojita silenty fails to establish encryption when the remote  
>> server greets us with an initial PREAUTH.
>
> PREAUTH is a trouble magnet, IMNSHO. The protocol would have been  
> better off without it.

Agreed.  And (unlikely scenario, but...) what can you do if you want  
to auth as another user?  You will never get the chance.  Also the  
fact you don't even know what user you are preauth'd as.

Wondering if it makes sense for our library to reject PREAUTH by  
default due to some of these issues.

michael

On 2014-03-18 19:23, Bron Gondwana wrote:
> Sadly, they're still out there - which is why FastMail doesn't allow port 143 at all.  Port 993 appears to be working in the real world[tm].
>
> I'd be interested in seeing the actual stats for which clients can be convinced by a MITM to give up their credentials in plaintext in their default configuration.  Don't give me a checkbox which requires the user to actively increase the security level, because that won't work.  In fact, don't even give the user a dialog which allows them to send the password insecurely, because they will.
>
> Not responding to a SYN on port 143 with an ACK...


If you put together a list, be sure to exclude clients that either 
ignore certificate errors, or have users that ignore certificate errors. 
SSL solves nothing when users are already trained to just ignore errors 
and proceed anyway.

-- 
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren

On Mar 18, 2014, at 7:23 PM, Bron Gondwana <brong@fastmail.fm> wrote:

> So why is 993 deprecated rather than STARTTLS deprecated now?  STARTTLS is _still_ a bad idea.

That seemed to be a political argument within disparate IETF WGs.  Begrudgingly I would nominate Chris to talk about that history, as I recall he was involved (or argued) during the period.  But I also know many people want to forget about it.  I just ignored the whole thing due to the in-fighting.

Okay, not completely.  I was discouraging against SSL on 993 for one main reason:

If SSL is proven broken, where do we go?  Another port for another encryption layer?  How does that scale?

And I think that was the crux of the overall IETF argument against allocating dedicated ports to dedicated SSL versions of the existing protocols.  SRV was supposed to mitigate against that, but SRV hasn't taken over the protocol developer community.

> We don't need a wayback machine to fix the future.

But we need it to fix the past, and that's what you are complaining about.

> Sadly, they're still out there - which is why FastMail doesn't allow port 143 at all.  Port 993 appears to be working in the real world[tm].

No doubt.  Almost every IMAP client I stumble across today supports it.  But what happens when TLS is broken in a way that requires divorcing from any of the previous instantiations?  It will happen.  Do we roll off to yet another port number for the new version?  We have much fewer than 65535 cracks at that cat.  And what about all the existing clients that still expect to speak to port 993 TLS <=1.2?

> I'd be interested in seeing the actual stats for which clients can be convinced by a MITM to give up their credentials in plaintext in their default configuration.  Don't give me a checkbox which requires the user to actively increase the security level, because that won't work.  In fact, don't even give the user a dialog which allows them to send the password insecurely, because they will.

Stop being a tease ? you know they all will (some require a little more foreplay than others).

But how do you propose to solve this in an everlasting manner?  Imagine how embarrassed you will be when your grandchildren break your perfect encryption system on their laptops.  From the womb.

--lyndon


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 817 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20140318/aa1fef39/attachment.sig>

On 19 March 2014 02:23, Bron Gondwana <brong@fastmail.fm> wrote:

> I'd be interested in seeing the actual stats for which clients can be
> convinced by a MITM to give up their credentials in plaintext in their
> default configuration.  Don't give me a checkbox which requires the user to
> actively increase the security level, because that won't work.  In fact,
> don't even give the user a dialog which allows them to send the password
> insecurely, because they will.
>

Inky does a single leap-of-faith to handle unverified certificates during
its account setup phase, and won't (ever) send passwords insecurely. This
limits providers alarmingly; many "free with your internet" providers still
seem to insist on cleartext passwords and no TLS.

The leap-of-faith is needed because it performs RFC 6186 lookups, as well
as heuristic discovery, and providers do not supply verifiable SANs in this
case - that is, Inky's only reference identifiers [RFC 6125] are typically
domains like "fastmail.fm" or "gmail.com" rather than hostnames supplied
directly by the user.

In these example cases, the provider supplies RFC 6186 records
authoritatively:

;; ANSWER SECTION:
_imaps._tcp.gmail.com. 86400 IN SRV 5 0 993 imap.gmail.com.
;; ANSWER SECTION:
_imaps._tcp.fastmail.fm. 600 IN SRV 0 1 993 mail.messagingengine.com.

However trusting these requires either DNSSEC (which I'm not sure either
domain supports; Inky certainly doesn't) or for the certificates to include
an identifier for either the domain (which I don't think they do) or the
service+domain restricted identifier (via sRVNames for example).

I think a good first step to helping MUA developers rely on a valid trust
path would be to ensure that a valid trust path actually exists (whether
that's via DNSSEC or sRVName SANs). Then you're in a much better position
to denounce the client developers for how awful and slack they are. :-)

Dave.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20140319/9fb46982/attachment.html>

On 3/18/2014 10:46 PM, Bron Gondwana wrote:
> And then it fell back to the Mozilla ISP database, but there's no 
> reason I couldn't have MITMed that and stolen the gmail creds too. 
> Thunderbird is pretty trivially fooled at setup time. Bron. 
The ISP database requires an https connection IIRC, but that's a minor 
detail (I thought autoconfig also required https and not http, but 
again, that's minor).

You seem to be coming from the standpoint that a security system that 
can't protect against everything is no better than one that protects 
against most things. Autoconfiguration can be fooled, true (even if 
https were required--we fallback to guessing servers and trying 
commands, so a DNS hijack setup could easily screw it over). But you 
have a 5-second window (and I'm being generous here) to do it. And if 
you miss that chance, you've lost it for another 3 years.

It's like ssh: ssh is actually weak to being MITM'd on the first 
connection (based on how people use it): people don't remember the keys, 
so they'll always say "yes" to the question "are you sure this key is 
correct?" Does that mean that ssh provides no protection? Of course 
not--the difficulty of intercepting the ssh connection is made extremely 
harder and makes attackers pour much more resources into doing so.

-- 
Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth

Hi Michael,

> On 19 Mar 2014, at 18:59, Michael M Slusarz <slusarz@curecanti.org> wrote:
> 
> Quoting Tony Finch <dot@dotat.at>:
> 
>> Bron Gondwana <brong@fastmail.fm> wrote:
>>> On Wed, Mar 19, 2014, at 08:25 AM, Michael M Slusarz wrote:
>>> >
>>> > STARTTLS deprecated the use of port 993, which isn't an official IMAP
>>> > port FWIW.
>> 
>> What do you mean by "official"? Have you seen RFC 6186?
> 
> Nothing in there registering 993 to IMAP.  RFC 6335 registry agrees that it hasn't been "officially" reserved:
> 
> http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=imaps
> 
> But this is just arguing semantics.  Real-world: 993 (& 995) have universal knowledge as to their current use.

I think IETF UTA WG is going to register them properly.

> michael
> A
> 
> _______________________________________________
> Imap-protocol mailing list
> Imap-protocol@u.washington.edu
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol

On Wed, Mar 19, 2014, at 02:00 PM, Lyndon Nerenberg wrote:
> Okay, not completely.  I was discouraging against SSL on 993 for one main reason:
> 
> If SSL is proven broken, where do we go?  Another port for another encryption layer?  How does that scale?

Badly, I presume.

> And I think that was the crux of the overall IETF argument against allocating dedicated ports to dedicated SSL versions of the existing protocols.  SRV was supposed to mitigate against that, but SRV hasn't taken over the protocol developer community.

Indeed.

> > We don't need a wayback machine to fix the future.
> 
> But we need it to fix the past, and that's what you are complaining about.

Not entirely, I'll articulate what I'm complaining about in a moment...

> But how do you propose to solve this in an everlasting manner?  Imagine how embarrassed you will be when your grandchildren break your perfect encryption system on their laptops.  From the womb.

I've seen an awful lot of "you are gonna need it" (to flip around what the
kids these days call YAGNI) justification for broken stuff in the standards
world.  Stuff that's so future-proof and optimised for the 1% cases that it
fails to perform the 99% case here and now adequately.

You see it all the time in standards with low and poor adoption.  Optimising
for the edge cases.  Case in point the argument against SUBMIT via IMAP and
POP - instead needing a separate authenticated connection for SMTP so that it
can support all the future extensions which might be added to SMTP.

Meanwhile everyone has been in a support nightmare for years.  I remember
ISPs with POP before SMTP rubbish to work around the fact that you couldn't
just shove the outbound message up your POP connection.

And I _still_ see issues where SMTP connectivity is blocked but IMAP is working,
and people can't send email from their clients on some networks.  Not a total
failure, but a partial failure.

And the "standard fix"?  BURL.  Instead of converting two possibilities of failure
into a single "it's on or off" it creates a triangle, in which any one of THREE
different interlinks could fail, making things break.  Funnily enough, I don't see
very much of it out there.

It's broken for now because of assumed future risks.  And that's my problem with
the standards world.

Bron.

-- 
  Bron Gondwana
  brong@fastmail.fm

On 19 March 2014 03:00, Lyndon Nerenberg <lyndon@orthanc.ca> wrote:

>
> On Mar 18, 2014, at 7:23 PM, Bron Gondwana <brong@fastmail.fm> wrote:
>
> > So why is 993 deprecated rather than STARTTLS deprecated now?  STARTTLS
> is _still_ a bad idea.
>
> That seemed to be a political argument within disparate IETF WGs.
>  Begrudgingly I would nominate Chris to talk about that history, as I
> recall he was involved (or argued) during the period.  But I also know many
> people want to forget about it.  I just ignored the whole thing due to the
> in-fighting.
>
> Okay, not completely.  I was discouraging against SSL on 993 for one main
> reason:
>
> If SSL is proven broken, where do we go?  Another port for another
> encryption layer?  How does that scale?
>
> And I think that was the crux of the overall IETF argument against
> allocating dedicated ports to dedicated SSL versions of the existing
> protocols.  SRV was supposed to mitigate against that, but SRV hasn't taken
> over the protocol developer community.
>
>
The main argument was mostly that TLS wasn't seen as the sole encryption
method, and it was possible (and in fact quite common at one stage) to find
better security via SASL security layers than by (export grade) TLS.

That argument has gone, I think.

The other argument relates to port number exhaustion, which turned out to
be unimportant because everyone uses either 80 or 443 these days.

It's possible that revisiting the issue might prove interesting.

I don't think that it's worth worrying over TLS breaking, though, I think
the custodians of that protocol are well able to maintain some kind of
upgrade path.

Dave.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20140319/41007874/attachment.html>

On Wed, Mar 19, 2014, at 03:13 PM, Joshua Cranmer wrote:
> On 3/18/2014 10:46 PM, Bron Gondwana wrote:
> > And then it fell back to the Mozilla ISP database, but there's no 
> > reason I couldn't have MITMed that and stolen the gmail creds too. 
> > Thunderbird is pretty trivially fooled at setup time. Bron. 
> The ISP database requires an https connection IIRC, but that's a minor 
> detail (I thought autoconfig also required https and not http, but 
> again, that's minor).

Yes, it did in my tcpdump, which is good.

> You seem to be coming from the standpoint that a security system that 
> can't protect against everything is no better than one that protects 
> against most things. Autoconfiguration can be fooled, true (even if 
> https were required--we fallback to guessing servers and trying 
> commands, so a DNS hijack setup could easily screw it over). But you 
> have a 5-second window (and I'm being generous here) to do it. And if 
> you miss that chance, you've lost it for another 3 years.
> 
> It's like ssh: ssh is actually weak to being MITM'd on the first 
> connection (based on how people use it): people don't remember the keys, 
> so they'll always say "yes" to the question "are you sure this key is 
> correct?" Does that mean that ssh provides no protection? Of course 
> not--the difficulty of intercepting the ssh connection is made extremely 
> harder and makes attackers pour much more resources into doing so.

No, you're absolutely right there.  It's definitely an improvement.
Thunderbird is one of the better clients out there.

Of course, it could try SRV records first.  There's a standard for that
now, and they could point you at port 993 (ours do) immediately.

Gmail also uses port 993 fwiw.

Bron.

-- 
  Bron Gondwana
  brong@fastmail.fm

On Mar 18, 2014, at 8:34 PM, Bron Gondwana <brong@fastmail.fm> wrote:

> It's broken for now because of assumed future risks.  And that's my problem with
> the standards world.

Where is your answer?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 817 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20140318/7a6cbfa2/attachment.sig>

So, should we expect STARTTLS12 any time soon?

TLS is  itself fairly self negotiating, though I wouldn't bet against
something needing a completely different impl.  That said, if the existing
thing is that broken, sunsetting the broken thing is necessary anyways.

And we don't seem to be adding protocols all that fast.

Anyways, I'm more worried about SMTP getting encrypted and actually
validated, IMAP at least is something you can mostly control yourself, with
SMTP interoperability and coexistence are required.

Brandon
On Mar 18, 2014 8:34 PM, "Bron Gondwana" <brong@fastmail.fm> wrote:

> On Wed, Mar 19, 2014, at 02:00 PM, Lyndon Nerenberg wrote:
> > Okay, not completely.  I was discouraging against SSL on 993 for one
> main reason:
> >
> > If SSL is proven broken, where do we go?  Another port for another
> encryption layer?  How does that scale?
>
> Badly, I presume.
>
> > And I think that was the crux of the overall IETF argument against
> allocating dedicated ports to dedicated SSL versions of the existing
> protocols.  SRV was supposed to mitigate against that, but SRV hasn't taken
> over the protocol developer community.
>
> Indeed.
>
> > > We don't need a wayback machine to fix the future.
> >
> > But we need it to fix the past, and that's what you are complaining
> about.
>
> Not entirely, I'll articulate what I'm complaining about in a moment...
>
> > But how do you propose to solve this in an everlasting manner?  Imagine
> how embarrassed you will be when your grandchildren break your perfect
> encryption system on their laptops.  From the womb.
>
> I've seen an awful lot of "you are gonna need it" (to flip around what the
> kids these days call YAGNI) justification for broken stuff in the standards
> world.  Stuff that's so future-proof and optimised for the 1% cases that it
> fails to perform the 99% case here and now adequately.
>
> You see it all the time in standards with low and poor adoption.
>  Optimising
> for the edge cases.  Case in point the argument against SUBMIT via IMAP and
> POP - instead needing a separate authenticated connection for SMTP so that
> it
> can support all the future extensions which might be added to SMTP.
>
> Meanwhile everyone has been in a support nightmare for years.  I remember
> ISPs with POP before SMTP rubbish to work around the fact that you couldn't
> just shove the outbound message up your POP connection.
>
> And I _still_ see issues where SMTP connectivity is blocked but IMAP is
> working,
> and people can't send email from their clients on some networks.  Not a
> total
> failure, but a partial failure.
>
> And the "standard fix"?  BURL.  Instead of converting two possibilities of
> failure
> into a single "it's on or off" it creates a triangle, in which any one of
> THREE
> different interlinks could fail, making things break.  Funnily enough, I
> don't see
> very much of it out there.
>
> It's broken for now because of assumed future risks.  And that's my
> problem with
> the standards world.
>
> Bron.
>
> --
>   Bron Gondwana
>   brong@fastmail.fm
> _______________________________________________
> Imap-protocol mailing list
> Imap-protocol@u.washington.edu
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20140318/891f099c/attachment.html>

Bron Gondwana <brong@fastmail.fm> wrote:
>
> You see it all the time in standards with low and poor adoption.  Optimising
> for the edge cases.  Case in point the argument against SUBMIT via IMAP and
> POP - instead needing a separate authenticated connection for SMTP so that it
> can support all the future extensions which might be added to SMTP.

Indeed. Particularly annoying.

Aside from the operational problems you listed, there is an architectural
problem with ESMTP for message submission: the IETF refused to describe a
way to represent envelope extensions in RFC 822 message headers, which
means MUAs have to invent their own non-standard ways to represent this
information in draft messages and saved copies of sent messages.

A sensible design would be like BCC: where the submission process
constructs the envelope based on information in the message header and
strips any extraneous headers. If you do that then draft and saved
messages can use a standard format and you can trivially put the
submission process into the IMAP server.

http://www.ietf.org/mail-archive/web/apps-discuss/current/msg11566.html

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
Trafalgar: Cyclonic 4 in southeast, otherwise northerly 5 to 7, decreasing 4
or 5. Moderate or rough. Fair. Good.

On Wed, Mar 19, 2014, at 02:43 PM, Lyndon Nerenberg wrote:
> 
> On Mar 18, 2014, at 8:34 PM, Bron Gondwana <brong@fastmail.fm> wrote:
> 
> > It's broken for now because of assumed future risks.  And that's my problem with
> > the standards world.
> 
> Where is your answer?

Pragmatic standards that solve the problems now, ahead of the perceived
potential problems of the future.  Designing for the future gets us ISO
7 layer networking, not TCP.

As an example:

In the mail space - it means replace authenticated SMTP with SUBMIT via IMAP.
That doesn't mean turn off authenticated SMTP, it means add SUBMIT via IMAP.
I'm willing to make a bet that client authors would jump on it - particularly
if it was implemented with a latch.

(by which I mean that the server sets a flag on the message upon successful
SUBMIT to the next hop)

Add a SPECIALUSE mailbox name for messages to be IMAP appended into, then:

> SELECT Outbox

> TAG UID SUBMIT $N (OPTS)
< TAG OK SUBMITTED $N ESMTP id A01306C0037

And you get single-copy-over-the-wire upload.  Define the few basics (strip
BCC) that everyone needs, and you've hit the 99% use case for right now.

Yet every time this kind of idea comes up, the naysayers are all screaming
"won't somebody think of the future" - and meanwhile exchange active sync
is out there eating lunches, which it so much should not be.

Bron.

-- 
  Bron Gondwana
  brong@fastmail.fm

On Wed, Mar 19, 2014, at 09:21 PM, Tony Finch wrote:
> Bron Gondwana <brong@fastmail.fm> wrote:
> >
> > You see it all the time in standards with low and poor adoption.  Optimising
> > for the edge cases.  Case in point the argument against SUBMIT via IMAP and
> > POP - instead needing a separate authenticated connection for SMTP so that it
> > can support all the future extensions which might be added to SMTP.
> 
> Indeed. Particularly annoying.
> 
> Aside from the operational problems you listed, there is an architectural
> problem with ESMTP for message submission: the IETF refused to describe a
> way to represent envelope extensions in RFC 822 message headers, which
> means MUAs have to invent their own non-standard ways to represent this
> information in draft messages and saved copies of sent messages.
> 
> A sensible design would be like BCC: where the submission process
> constructs the envelope based on information in the message header and
> strips any extraneous headers. If you do that then draft and saved
> messages can use a standard format and you can trivially put the
> submission process into the IMAP server.
> 
> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg11566.html

I've signed up to that list now.

I've argued about the SUBMIT via IMAP issues before, and every time I've
been shot down by the "it's not future-proof", and even more clear "we've
chosen another way to do that, and we're not going to rehash the arguments
we made at the time, go read the archives to see why you're wrong and also
stupid".

It kind of turned me off the whole standards world for a while, because for
every excellent thing like CONDSTORE you get a whole ton of architecture
astronaut solutions like BURL.

But standards are the only way to make things useful for more than your own
little walled garden, so there's really no choice.  I don't want to
improve one little walled garden.

Bron.

-- 
  Bron Gondwana
  brong@fastmail.fm