Re: Questions about Version Negotiation Concerning Possible Handshake Interruption

[Lingmo Zhu <[e-mail]>]

On 10/02/2018 07:24, Christian Huitema wrote:
 >
 > In theory, it should be possible to protect against "man on the side"
 > attacks. Do some kind of speculative execution on the first packet that
 > you receive, but also keep the context available for some time in case a
 > "better" packet comes later. With that approach, the attacker could not
 > just inject a "packet of death"; they will also need to suppress the
 > correct response from the actual server. That's an interesting idea.
 > Have you tried some experiments?

No experiments yet but I'd love to. Though my current work is not so
related to this field so maybe I'm not professional enough.


On 2018/02/10 17:00, Kazuho Oku wrote:
> 2018-02-10 17:34 GMT+09:00  <[e-mail]>:
>> On 10/02/2018 07:24, Christian Huitema wrote:
>>>
>>> In theory, it should be possible to protect against "man on the side"
>>> attacks. Do some kind of speculative execution on the first packet that
>>> you receive, but also keep the context available for some time in case a
>>> "better" packet comes later. With that approach, the attacker could not
>>> just inject a "packet of death"; they will also need to suppress the
>>> correct response from the actual server. That's an interesting idea.
>>> Have you tried some experiments?
>>
>>
>> Alternatively, what about a "no fallback" mode for sensitive applications
>> like DNS ?
> 
> I agree that providing such an option would narrow the attack window.
> The other option is to let the client propose multiple versions and
> the server select one, as proposed in my previous mail.
> 
> But even if we do that, there's still the chance of an attacker
> injecting a Handshake packet that contains a corrupt ServerHello
> message. In such case, the client would fail to complete the handshake
> with the server.
> 
> To evade such attacks, a client is required to create a backup of its
> TLS context before handling the Handshake packet that might have been
> sent from an attacker, so that it could restore the context one the
> TLS handshake ends up in an error.
> 
> However, I am not sure if any of the TLS stacks provide such a feature
> (personally I would be interested in adding one in picotls, though).
> 
> 

IMHO even though we want no fallback for service like DNS, in reality
that could not be possible for several years due to deploying progress
and its critical position (if no fallback, no name resolving would be
available if QUIC & TLS connection failed if my understanding is
correct).

To be cleared, spoofing clear text VERSION NEGOTIATION packet is cheap
from my POV so it could be misused easily. I'm not sure but injecting
corrupt ServerHello message could be sort of expensive thanks to
encryption so I didn't consider that far. So if we still decide to use
current version negotiation mechanism, considering only the attack
approach using VERSION NEGOTIATION and we hold different contexts for
a short period, there would be several cases:

* fake VERSION NEGOTIATION with no acceptable versions was sent to the
   client but the server could accept the QUIC version INITIAL packet
   used, it could be mitigated by simply wait for a short period. Retry
   might be applied considering packet lost.
* sever actually could not accept any version that the client supported,
   client would abort the QUIC connection after several retries and that
   should be expected.
* fake VERSION NEGOTIATION with no acceptable versions was sent to the
   client and the server also rejected the QUIC version with a VERSION
   NEGOTIATION with acceptable versions, client could try an acceptable
   version and process the handshake.
* fake VERSION NEGOTIATION with acceptable versions was sent to the
   client and the server could accept the QUIC version INITIAL packet
   used, things could be tricky. At least two contexts should be hold
   by the client. If the new version selected by client is not acceptable
   to server, that could be a better scenario since the original context
   would simply become the finally negotiated one. But if the new version
   is also acceptable by server, I'm not sure what would happen.
* fake VERSION NEGOTIATION with acceptable versions was sent to the
   client but the server rejected the QUIC version with a VERSION
   NEGOTIATION with acceptable versions, things would be really complex.
   But the downgrade attack mentioned by Mikkel should be tolerant by
   current verifying mechanism. I'm not sure if we should consider this
   case.

So as a summary, holding original context for a short period should be
enough for mitigating the interruption caused by VERSION NEGOTIATION
according to the first three cases. But for the remaining misuse cases,
it might need further consideration if they should.

Lingmo Zhu

>> _________________________________________________________________________________________________________________________
>>
>> Ce message et ses pieces jointes peuvent contenir des informations
>> confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
>> ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
>> electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, deforme ou
>> falsifie. Merci.
>>
>> This message and its attachments may contain confidential or privileged
>> information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and
>> delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have been
>> modified, changed or falsified.
>> Thank you.
>>
> 
> 
>