Re: [Uta] SMTP Over TLS on Port 26 - Implicit TLS Proposal

[Viruthagiri Thirumavalavan <[e-mail]>]

@Daniel Margolis

Thanks for the input. Really appreciate that.

@Vittorio Bertola

My apologies for being rude earlier. I was little upset when I saw your
post. I'm okay now. Again my apologies. I had to defend myself there.

I remember you from a few months ago on the DMARC-discuss list, when you
> tried to convince everyone that you had finally solved the problem of spam
> by introducing your proprietary standard "Sender Alias Domains" (where did
> that go?).


When you say something like that on this list, you are implying like "Hey,
this guy is not serious. You are wasting your time by helping him". And
that's much worse than the guys who attacked me on the DMARC list.

I think I already made it pretty clear. Trying to standardise a flawed
solution is the last thing I wanna do. So I have no problem if my proposal
get rejected due to flaws. But not because we already have STS and DANE.

This is how you responded

I would advise you to make sure that you fully appreciate the explanations
> that are given to you on why your proposal is fundamentally flawed, rather
> than just adjusting the original proposal a bit and keep posting it again.


I posted in ietf-smtp and this is how they responded

Especially if you are new, please interpret my response (and
> those of several others) as "we aren't convinced about your
> idea" or "we think there are better alternatives", not as "your
> proposal is bad and will cause problems".   I'd like to see a
> lot more discussion before the latter conclusion is reached
> although I'd encourage you to read the comments carefully and
> see if they suggest ways to improve the proposal.  I believe
> that it is very important that new ideas to which long-time
> participants have initial negative reasons get careful
> consideration and every reasonable chance to succeed before they
> are dismissed.


They even go an extra step to show their hospitality

Also, the IETF functions much better when document proposals are
> posted as Internet Drafts.   See
> https://www.ietf.org/standards/ids/ and
> https://datatracker.ietf.org/submit/tool-instructions/ and the
> other headings on the latter page.   Under normal circumstances,
> I'd volunteer to help you get an Internet-Draft together from
> you github posting but this week is just too busy.  Perhaps
> someone else can help you get started (that is a call for
> volunteers, folks), otherwise please get back to me next week.

welcome to the IETF.


These folks are down to earth. And I would be ready to work with them any
day.

Feel free to criticise my work. I even thanked many people in this list for
that. But please don't insult me just to prove a point.

I'm gonna continue this proposal discussion in ietf-smtp list. I wish you
good luck and my apologies once again for what I said earlier.

Thanks

On Mon, Jan 7, 2019 at 9:59 PM Daniel Margolis <dmargolis=
[e-mail]> wrote:

> Yeah, I wanted to chime in on this thread to say something similar. ;)
>
> I have always admired how modern browsers have been able to really push
> the boundaries on security UI (e.g. showing warnings for weak ciphers, etc)
> and consequently change the state of security for most of the Web
> ecosystem. I would (speaking personally here) love to see major mail
> providers do something similar to what Alice said and sunset weak
> (unencrypted, or unauthenticated) SMTP.
>
> But there are, I think, at least two ways in which mail is somewhat
> different than the Web for this:
>
> 1. There's no great *synchronous* UX to show users auth failures or
> downgrades and get them to approve, nor do identifiers even indicate an
> expected state of security. (Users who enter "https" manually--which
> admittedly is probably a very rare behavior--are explicitly indicating
> something akin to Require-TLS, whereas email traditionally has no such
> indicator; more importantly, perhaps, there's no great mechanism to show
> users "we tried STARTTLS but couldn't negotiate it; do you want to
> continue?" since mailing is async.)
>
> 2. Mail is quite commonly outsourced to a hosting provider, so you can't
> just require server identities to match the @domain--you need to somehow
> validate the MX.
>
> Admittedly both of these problems are fixable with existing technologies:
> a Webmail provider could check for DANE and DNSSEC on the MX zone and warn
> users at message compose time where it's not present, for example. But it
> does feel to me hard to shoehorn this into the SMTP ecosystem as it
> currently exists, though perhaps we're all just too incrementalist or
> something.
>
> I do see improvements, however--notably, that opportunistic TLS is now
> very common, DANE is of increasing usage, and MTA-STS hopefully provides an
> alternate for those who cannot adapt DANE, and Require-TLS is an experiment
> in giving users that UI control. So I think things are moving in the right
> direction.
>
> Viruthagiri, I appreciate the bold suggestions. New things would never
> happen without them! If people are a little crusty sometimes, I think it's
> only feedback about the difficulty of fully understanding context and
> history when making a new proposal.
>
> Dan
>
> On Mon, Jan 7, 2019 at 3:42 PM Alice Wonder <[e-mail]> wrote:
>
>> On 1/7/19 6:24 AM, Vittorio Bertola wrote:
>> >
>> >> Il 7 gennaio 2019 alle 13.23 Viruthagiri Thirumavalavan
>> >> <[e-mail]> ha scritto:
>> >>
>> >> @Vittorio Bertola
>> > Hello,
>> >
>> > it looks like you misinterpreted my reply completely, reading things in
>> > it that I never thought or said, but in any case, if you felt offended
>> > by it, I apologize. I actually think that the IETF is often too
>> > unwelcoming and rude to new participants and I do not want to be part
>> of
>> > that attitude at all. At the same time, though I actually praised your
>> > boldness in repeatedly trying to tackle big issues, the consensus seems
>> > to be that your proposal cannot be supported, no matter how much you
>> fix
>> > it, and so there is not much help we can give you, other than
>> explaining
>> > to you the technical reasons for that conclusion, as I did in my reply;
>> > please accept the conclusion without taking it as a personal attack.
>> >
>>
>> Hear hear, and I share the passion too.
>>
>> If it were up to me, an RFC would be published deprecating opportunistic
>> TLS for SMTP.
>>
>> System administrators would have three years, but after that, TLS 1.3+
>> would be required for SMTP.
>>
>> Reason for TLS 1.3+ is that it requires ciphers with forward secrecy.
>>
>> But I know it will never fly. It's what I want though.
>>
>> _______________________________________________
>> Uta mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/uta
>>
>
>
> --
> How's my emailing? http://go/dan-email-slo
> _______________________________________________
> Uta mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uta
>


-- 
Best Regards,

Viruthagiri Thirumavalavan
Dombox, Inc.