Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv

[Watson Ladd <[e-mail]>]

On Mon, Jan 27, 2014 at 6:46 PM, Martin Rex <[e-mail]> wrote:
> Watson Ladd wrote:
>> "Martin Rex" <[e-mail]> wrote:
>> >
>> > Which server implementers are eager to send such a fatal alert as
>> > is contained in this proposal anyway?  I will certainly ensure that
>> > our server implementation will NEVER grow such silly behaviour.
>>
>> Let me get this straight: all SAP applications will be vulnerable to
>> downgrades even when clients are fixed because that behavior is "silly".
>
> Nope.  We do not implement reconnect fallbacks, so none of our stuff
> is downgradable.
>
> There might be defective browsers who will needlessly downgrade
> to insecure behaviour or suggest end users to not use HTTPS at all,
> but that is a defect of those browsers, not of our server.

So let me get this straight:
Because none of your clients ever need to implement reconnects and
none of your servers are ever
connected to by clients that do, this proposal is a problem for you
because...? You can always not
implement it.

I'm much more inclined to take seriously the complaints from folks who
actually have to live with the
proposal. So far the Firefox and Chrome folks have supported this
proposal. The servers probably will
support it: I think I can do PolarSSL without too much trouble, and
someone far more skilled then me in
arcana can do OpenSSL.

>
>
>>
>> I'm sure your clients will be happy to hear how seriously SAP takes
>> security.
>
> We do take security very seriously.  But we also take robustness,
> support and performance very seriously, but the reconnect fallback
> approach is neither robust, nor supportable and a royal PITA for
> performance.

Yes it is. But the browser folks disagree: being able to connect to a
small minority
of broken servers is worth the pain for them.

>
> How many TLS clients beyond a negligible small amount of browsers
> is doing the reconnect fallbacks anyway? How many POP/IMAP/SMTP/LDAP
> clients and programmatic HTTPS clients is doing reconnect fallbacks?

If they aren't doing fallbacks, then this doesn't affect them. This is
a much easier change
(bail out if you think you can support TLS 1.2) then your proposal.

>
>
> I refuse to blame the apps folks that they will have to jump hoops
> to workaround the botched TLS feature negotiation, rather than fixing
> the TLS feature negotiation within the TLS protocol itself.

Dead hands. Our ability to redo the negotiation at this point is about nil.
I've got no idea why it was done this way
Hopefully with TLS 1.3 we won't screw it up even further: perhaps TLS
1.2.1 is a better
name. The apps folks can always refuse to support servers that can't
negotiate properly.
Or we can make TLS APIs and libraries that handle the uglyness of
reconnection for the apps.

>
> -Martin



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin