Re: [Imap-protocol] STARTTLS after PREAUTH

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" <[email protected]> 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
>   [email protected]
> _______________________________________________
> Imap-protocol mailing list
> [email protected]
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>

_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol