ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] guidance on how to secure against sniffing and paid backdoors

2013-09-20 15:28:32
On 09/20/2013 11:37 AM, keld(_at_)keldix(_dot_)com wrote:
On Fri, Sep 20, 2013 at 08:24:54AM +0100, Sabahattin Gucukoglu wrote:
On 19 Sep 2013, at 21:05, keld(_at_)keldix(_dot_)com wrote:
On Thu, Sep 19, 2013 at 06:42:05PM +0100, Sabahattin Gucukoglu wrote:
On 19 Sep 2013, at 17:33, keld(_at_)keldix(_dot_)com wrote:
On Thu, Sep 19, 2013 at 09:37:18AM +0200, Rolf E. Sonneveld wrote:
So first things first, let's start with a proper threat analysis.
I don't know how to write such an analysis, and it seems like red tape to me.
I am just advocating that we migrate SMTP to TLS, and then I want a plan
that could evolve into an succesful migration, without hurting
interoperablity.
I've already explained in one way how interoperability is guaranteed to be 
hurt, even if your threat model only includes passive attackers. And I'm really 
not sure I'm happy about weakening TLS by making verification optional without 
making it very clear to implementers that their choice to use a CA-signed 
certificate is completely undermined for the sake of those who don't, 
regardless of how pointless verification may be.
And I already outlined a way to accomodate your concerns.

You would strengthen SMTP security overall by employing TLS.
I understand that it is only a few SMTP implementations that have the problems
you described. And those implementations are most likely contaminated anyway.
CA-signen certifications are most likely also contaminated, and self-signed 
certificates
are most likely having more chances of not being contaminated.
So interoperability isn't *that* important.  I'm happy with people choosing 
that option, as long as they realise that it's a precondition for your scheme.

Interoperability is important. I have outlined ways to keep interoperability,
even with bad current implementations of STARTTLS.
Another way to handle bad STARTTLS implementations is to keep track
of bad implementations in a greylisting manner, if TLS did not work,
then don't offer it next time around. For sending MTAs, then just put
it in the queue, for receiving MTAs that depends on the bad MTAs handling
but at least next time around the mail will get thru. The receiving
MTA could also consult a reltime black list of bad MTAs, to not
offer TLS.

You keep talking about solutions, without defining the problem.

I also need to point out that you've made many assumptions about 
implementations and CAs.  Do we really need to go there?  If nothing else, 
you're proposing nothing less than to undermine the entire CA industry--a sweet 
thought, to be sure, but not likely to go down too well with said industry. :)
It was only to do a weighting about priority to paid certificates
vs. self-signed. People can continue to buy their certificates.
Anyway the CA-industry have deliberately decieved their costumers
by selling them contaminated certificates.

Please provide some references to articles. I know there have been a number of CA 'issues' (Diginotar, Turktrust) and we all have our thoughts about to what extent CA's have been/are resistant against possible requests from governments, but so far I have not seen an article describing the fact that CA's have provided contaminated certificates. I may have missed that one, between all other revelations that followed the Prism scandal.


But look, what *is* your threat model? Who are you up against? What 
capabilities do they have? Is this about Prism, or something much worse 
involving active network attackers or server takeover? Without this we really 
don't know how we can best solve the problem, and even if we did, we'd probably 
disagree on the means, or the utility, or the interoperability problems.

What are the requirements for the specs for a threat analysis?
Who made  such a requirement?
Can you provide a link to the requirements?
And a good example of one?
Here's a general description of a threat analysis:
http://www.sans.org/reading_room/whitepapers/auditing/overview-threat-risk-assessment_76
Thanks for the link. I will have a look. I understand that this is not an IETF 
requirement.

I'm not a security person, but I think the idea is pretty straightforward: 
figure out what it is we're worried about.

FWIW, I think Prism is what we should be worried about, but it's a baby step in 
the scheme of things to simply turn on TLS everywhere with self-signed certs.  
I'd much rather we pushed DNSSEC+DANE as that's the only thing which will cater 
to stronger security requirements while also being interoperable with CA certs. 
 But perhaps you feel differently.
I am all for better security, but my main aim was to get TLS employed,

TLS employment is not a goal in itself.

and that
seems hard enough to get consesnsus on in this group.

Don't blame the group if you're just seeking consensus about TLS employment without defining what problem this solution will solve.

My main aim is to maintain interoperability, so if we can employ .
better security without hurting interoperability, that would be fine.
Using DNSSEC could be an option then.

And another option: good old typewriters and snail mail... [1]

/rolf

[1] http://www.theguardian.com/world/2013/jul/11/russia-reverts-paper-nsa-leaks
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp

<Prev in Thread] Current Thread [Next in Thread>