On 31 Jul 2017, at 19:55, John Levine wrote:
Other than the usual horrible problems getting certs installed and
configured, it's a great way to do client authentication.
+1
Specially when you manage your own CA and can issue your own certs to
the clients at onboarding.
-lem
_
In article
you write:
>If someone connects to you, they don't send you a cert unless you're
>dealing with client certs, and I don't think
>DANE covers that at all, though I haven't read through it completely.
The client can present a cert in the TLS handshake if it wants to.
Few do and equally f
On 07/28/2017 03:19 PM, Brandon Long via mailop wrote:
> If someone connects to you, they don't send you a cert unless you're
> dealing with client certs, and I don't think DANE covers that at all,
> though I haven't read through it completely.
It's my understanding that DANE covers client certs
That's a good point.
The number is only for encrypted, not authenticated and it looks like we
don't currently log verification.
We do CA verification and a GSuite domain can choose to require it for a
connection, but we don't use the
information generally. Presumably when we finish our STS and DA
On 07/28/2017 05:19 PM, Brandon Long wrote:
>
> We're hovering at 88% encrypted, inbound & outbound, if those in charge
> decided to move the needle, they could
> probably start a path along the likes of what Chrome is doing
> (https://security.googleblog.com/2016/09/moving-towards-more-secure-w
On Fri, Jul 28, 2017 at 5:58 AM, Michael Orlitzky
wrote:
> On 07/27/2017 01:44 PM, Dave Warren wrote:
> >>
> >> "Even if it were generally possible to determine a secure server name,
> >> the SMTP client would still need to verify that the server's
> >> certificate chain is issued by a trusted CA
On 07/28/2017 02:10 AM, Vittorio Bertola wrote:
On the Web, instead, users do want to know which company is actually
running the website that they are visiting, and not just that they are
really connecting to that hostname, so CAs offer additional value in
respect to DANE.
Full STOP!
I disag
In article <808816365.710.1501249729...@appsuite.open-xchange.com> you write:
>> The practical reason is that unencrypted SMTP has to work if you want to
>> be able to communicate with the world. ...
>This, by the way, is another advantage of DANE. By publishing a TLSA record
>for the ser
On 07/28/2017 06:58 AM, Michael Orlitzky wrote:
If someone connects to me and I don't like his CA, he
can fall back to plain text and I have to allow it (because of the
bajillions of people who don't do TLS over SMTP at all).
I disagree. You do have the choice to not accept messages over an
u
> Il 28 luglio 2017 alle 14.58 Michael Orlitzky ha scritto:
>
> The practical reason is that unencrypted SMTP has to work if you want to
> be able to communicate with the world. So, adding a second more-secure
> channel *in addition to* the existing unsecured channel doesn't really
>
On 07/27/2017 01:44 PM, Dave Warren wrote:
>>
>> "Even if it were generally possible to determine a secure server name,
>> the SMTP client would still need to verify that the server's
>> certificate chain is issued by a trusted CA (a trust anchor).
>>
>
> I've never understood why this is a speci
> Il 27 luglio 2017 alle 23.48 Brandon Long via mailop ha
> scritto:
>
> Well, yes, that is the DANE argument in a nutshell. That doesn't mean
> it's correct, and there are reasons why DANE was not the solution chosen for
> the browser market.
>
Can I ask which ones? I thought it was m
On Thu, Jul 27, 2017 at 9:05 AM, Vittorio Bertola <
vittorio.bert...@open-xchange.com> wrote:
>
> Il 26 luglio 2017 alle 19.10 Brandon Long ha scritto:
>
> Why can't smtp software being expected to maintain a list of trusted CAs?
> Or at least run on an OS that is expected to do so.
>
> There is
On Thu, Jul 27, 2017 at 11:32 AM, Grant Taylor via mailop wrote:
> On 07/27/2017 11:44 AM, Dave Warren wrote:
>
>> I've never understood why this is a special challenge in the SMTP world,
>> it's generally a solved problem for HTTPS, XMPP, and various other
>> protocols.
>>
>
> It's my understand
On 2017-07-25 at 22:10 -0400, Eric Tykwinski wrote:
> Sorry, probably straying from the topic, but does anyone know any good SMTP
> tests for DANE.
> I’m using https://dane.sys4.de/ currently and it works, but I would like
> something with some more details if possible.
Self-pimping:
https://
On 07/27/2017 11:44 AM, Dave Warren wrote:
I've never understood why this is a special challenge in the SMTP world,
it's generally a solved problem for HTTPS, XMPP, and various other
protocols.
It's my understanding that the problem has to do with the (lack of)
people involved in the transact
On Thu, Jul 27, 2017, at 09:05, Vittorio Bertola wrote:
>
>> Il 26 luglio 2017 alle 19.10 Brandon Long ha scritto:>>
>> Why can't smtp software being expected to maintain a list of trusted CAs?
>> Or at least run on an OS that is expected to do so.> There is a standard
>> explanation (liter
> Il 26 luglio 2017 alle 19.10 Brandon Long ha scritto:
>
> Why can't smtp software being expected to maintain a list of trusted CAs?
> Or at least run on an OS that is expected to do so.
>
There is a standard explanation (literally) in RFC 7672, section 1.3, and
especially 1.3.4.:
"Ev
> On Jul 26, 2017, at 5:42 PM, Steve Atkins wrote:
>
> It doesn't _really_ matter in the context of deciding whether a certificate
> is being presented by a legitimate domain owner or a MitM.
Well I think that’s the whole solution of DANE, ie validate through DNSSCEC
that the owner of the doma
> On Jul 26, 2017, at 1:43 PM, valdis.kletni...@vt.edu wrote:
>
> On Wed, 26 Jul 2017 10:10:53 -0700, Brandon Long via mailop said:
>> Why can't smtp software being expected to maintain a list of trusted CAs?
>> Or at least run on an OS that is expected to do so.
>
> Quick: What two CAs did Goog
If it becomes important, I'm sure it can be done.
I mean, you all update your av signatures at least daily, or your spam
rules.
And whether they would need to follow the browser list or whatever isn't
clear, sure.
It's early in this stuff for email, maybe DANE will be the solution that
catches o
On Wed, 26 Jul 2017 10:10:53 -0700, Brandon Long via mailop said:
> Why can't smtp software being expected to maintain a list of trusted CAs?
> Or at least run on an OS that is expected to do so.
Quick: What two CAs did Google just remove from Chrome's list?
Has your OS vendor followed suit? And
I think the key part is not "expect", but actually don't require it.
-lem
On 26 Jul 2017, at 10:10, Brandon Long via mailop wrote:
> Why can't smtp software being expected to maintain a list of trusted CAs?
> Or at least run on an OS that is expected to do so.
__
On Wed, Jul 26, 2017 at 1:23 AM, Vittorio Bertola <
vittorio.bert...@open-xchange.com> wrote:
>
> Il 25 luglio 2017 alle 22.25 Grant Taylor via mailop ha scritto:
>
>
> On 07/25/2017 09:14 AM, Vladimir Dubrovin via mailop wrote:
>
> To protect against passive Man-in-the-Middle, there is no actual
> Il 25 luglio 2017 alle 22.25 Grant Taylor via mailop ha scritto:
>
>
> On 07/25/2017 09:14 AM, Vladimir Dubrovin via mailop wrote:
>
> > > To protect against passive Man-in-the-Middle, there is no actual
> > difference between the self-signed certificate and certificate fr
> On Jul 25, 2017, at 7:46 PM, Brandon Long via mailop
> wrote:
>
> Agreed that STS and DANE are the solution for enforcing, however it's still
> early days for those.
>
> Brandon
Sorry, probably straying from the topic, but does anyone know any good SMTP
tests for DANE.
I’m using https://
On Tue, Jul 25, 2017 at 4:13 PM, Ted Cabeen
wrote:
> On 7/25/2017 8:14 AM, Vladimir Dubrovin via mailop wrote:
>
>> STARTTLS is opportunistic and doesn't protect against active
>> Man-in-the-Middle. In case of TLS problems it falls back to plain text.
>>
>
> Interestingly, that's not always the c
On 7/25/2017 8:14 AM, Vladimir Dubrovin via mailop wrote:
STARTTLS is opportunistic and doesn't protect against active
Man-in-the-Middle. In case of TLS problems it falls back to plain text.
Interestingly, that's not always the case now. We typoed the cert on
one of our list servers earlier t
On 07/25/2017 09:14 AM, Vladimir Dubrovin via mailop wrote:
STARTTLS is opportunistic and doesn't protect against active
Man-in-the-Middle. In case of TLS problems it falls back to plain text.
STARTTLS is opportunistic, but MTAs can be configured to require
protected channels and to refuse ema
I've not had any issues with self signed certs with TLS on SMTP. That said,
lately I've been using Lets Encrypt certificates with the certbot program
to manage them, and that has worked really well. The initial setup takes a
little effort to do a DNS based verification since the mail hosts are not
STARTTLS is opportunistic and doesn't protect against active
Man-in-the-Middle. In case of TLS problems it falls back to plain text.
To protect against passive Man-in-the-Middle, there is no actual
difference between the self-signed certificate and certificate from
recognized CA, so, except may b
31 matches
Mail list logo
