Re: [TLS] Comments on TLS identity protection

[Eric Rescorla <ekr@xxxxxxxxxxxxxxxxxxxx>]

badra <badra@xxxxxxxx> writes:
> Pasi.Eronen@xxxxxxxxx a écrit :
>> The fact that anybody can
>> connect at any time does not automatically imply that lots of people
>> are connecting all the time! (And in particular, lots of people
>> without client certificates connecting all the time to servers that
>> always require client
>> authentication, and without malicious intent to DoS the server.)
>>
> But the "anybody" that can connect at any time will be able to
> establish several "double handshake" in parallel; especially when TLS
> is used over EAP or UDP (I don't have data but maybe Eric).
>
> My point is that double handshake will increase complexity and will
> not help in reducing TLS server overload factor, especially when
> legitimate clients that don't have certificates are trying to
> connect. Their number is not actually important.

Wait, there are two issues here:

1. General server load in the absence of malicious behavior.
   As Pasi points out, there's no evidence that the double
   handshake technique is widely enough used to cause this
   to be a problem.

2. Enabling DoS attacks. There are lots of ways to DoS a
   TLS server, and since this only doubles server load, 
   I don't think it's much of an amplifier.

>>>> (at least sufficiently to spend the $$$ for designing,
>>>> implementing,  testing, deploying, etc. a new mechanism).
>>>>
>>> How much :). The proposed changes are minimal.
>>>
>>
>> To get widespread deployment, several TLS implementations would have
>> to be updated, e.g. Microsoft Schannel, OpenSSL, Mozilla NSS, JSSE,
>> GnuTLS, etc. Getting any change, no matter how "minimal", to them is
>> not easy.
>>
>
> I don't see the point here. Any TLS feature will require updating TLS
> implementations.

Right, which is why it's a good idea to avoid making changes unless
we have to.

-Ekr

_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls