Re: How does a server identify a new connection?

Dmitri Tikhonov <dtikhonov@litespeedtech.com> Wed, 05 December 2018 14:10 UTC

Return-Path: <dtikhonov@litespeedtech.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1283812D7F8 for <quic@ietfa.amsl.com>; Wed, 5 Dec 2018 06:10:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.36
X-Spam-Level:
X-Spam-Status: No, score=-3.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIfXKNpeAxh1 for <quic@ietfa.amsl.com>; Wed, 5 Dec 2018 06:10:06 -0800 (PST)
Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DD4D1277C8 for <quic@ietf.org>; Wed, 5 Dec 2018 06:10:06 -0800 (PST)
Received: by mail-qk1-x731.google.com with SMTP id q1so11874149qkf.13 for <quic@ietf.org>; Wed, 05 Dec 2018 06:10:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=INe+eaRo9lZBs2ejz1LOOD0VQMuPigQuBNbfGzTel50=; b=vyl3vZkE6Vwx3xSizY7eAAkVX1aRoDSfvkVURY0jLOTdIHbRm/CAyE0WKyZbRBSd9+ fWsWN2iq5j8BTt24MNx+prJQu1/nG6X6x0pJhF2Qn6+oMZYB7AWGBFfkcyzukdZHyISv AljxWiZEdZfnzPkZL+dM3Pi65OU2SaZ4O7cp8Fpb5XflKnf3dIs66PvOqrLIoK4GE9Q7 rksyemP6dw4W+K6NNxSfOFne0m468cDP1tjtjaOiWMeoSG/8S/AllzumOONqKhixAhRj 5UeQJRwhuHeYh/rwKWwQ8F9s3kUn5oDzJqY69hg/XAwPO5nbihE4N39Gikdj+N/kdy3g Azpg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=INe+eaRo9lZBs2ejz1LOOD0VQMuPigQuBNbfGzTel50=; b=YJATvTIuGZm/QXKyC5m+2CGRok3LHPJdpRe19Z5F+8e9s5Wh2ziB2eq9Bw0ZOVKb3m rJHPG+wj3cAbQYrS8V1IYVAXYci5VLl491zEEkxUWoJ0TrtkzRP9dWzSI0V5XnzI1IGu CiIBIBjxSDjrnqrXLhXZipiMiKp77tIN4SO1vaNOaHGZBMxbDSCxezvtUyCgpLHrmWfN Z9kLyT9fwn95CXc5oLGmX2D2uAps1HUizHYfMCX49boUqxNmsPTalglsok6viO8HDl4q olwOFLJWOb5TbNW2ly35QGh8aZ7oSTvk4ZbDRfn9/7QUdhnVpnBdfz7XkvhCwxbg8qf2 oE+g==
X-Gm-Message-State: AA+aEWYQ9TNu3msHsMGubNAWcG8+6JslqNEv0RuPxXKC5G8Evr+YtU19 /aOqst5rem1TjajSIOUzyTbxXQ==
X-Google-Smtp-Source: AFSGD/W2BpKmPTK2BcGn4IsUiuxcOPjAZfG5K7aGgQy4VK2esbYFiMgivuMrNT4t1J5fYq6yDs0sYg==
X-Received: by 2002:a37:6084:: with SMTP id u126mr22011822qkb.118.1544019005672; Wed, 05 Dec 2018 06:10:05 -0800 (PST)
Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id y12sm17993998qta.13.2018.12.05.06.10.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Dec 2018 06:10:05 -0800 (PST)
Date: Wed, 05 Dec 2018 09:10:00 -0500
From: Dmitri Tikhonov <dtikhonov@litespeedtech.com>
To: Kazuho Oku <kazuhooku@gmail.com>, Christian Huitema <huitema@huitema.net>, Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, chuck_crisler@affirmednetworks.com, IETF QUIC WG <quic@ietf.org>, Martin Thomson <martin.thomson@gmail.com>
Subject: Re: How does a server identify a new connection?
Message-ID: <20181205140959.GA8843@ubuntu-dmitri>
Mail-Followup-To: Kazuho Oku <kazuhooku@gmail.com>, Christian Huitema <huitema@huitema.net>, Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, chuck_crisler@affirmednetworks.com, IETF QUIC WG <quic@ietf.org>, Martin Thomson <martin.thomson@gmail.com>
References: <20181203031430.GA29864@ubuntu-dmitri> <CANatvzxicJ2D48cpNJe3Cz8+ju0VJmf25+8NTdjSvJXH8j9bog@mail.gmail.com> <20181203135630.GA8140@ubuntu-dmitri> <CAN1APdd8h0wVSr6kpLXnc7T7O5tbPBbsij9jyV6ooUxMAHg8Xw@mail.gmail.com> <CAN1APdceYdWGGBgBLc-b6+SLP0x_dZHXDhDqq3TCpPmYdbssbA@mail.gmail.com> <5250b1be4c8f450f877f310aff0f0785@affirmednetworks.com> <CAN1APdd7LTk+eaOLg5MF7RL0_uzD2HBEosd1Ruyep-nN=-hBJQ@mail.gmail.com> <35a756a3-89e8-e817-bfd4-615fe6dfa2ba@huitema.net> <CANatvzxPvY7o6+7+nLhNBTXsYX6CnggRN58w7ej+KWeyG0VL0A@mail.gmail.com> <20181204135441.GA25658@ubuntu-dmitri>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20181204135441.GA25658@ubuntu-dmitri>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/RcGMHc-HUMXiogqq1UTfCIZTTC4>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Dec 2018 14:10:08 -0000

On Tue, Dec 04, 2018 at 08:54:41AM -0500, Dmitri Tikhonov wrote:
>     Is the server to try each of its connection candidates in
>     turn to see which one successfully decrypts the packet?

Kazuho,

You did not respond to this question, but it seems that this is
the way to implement the defense you propose on the server.  I
would like to point out that this sort of thing has a high cost
and in turn makes DoS attacks simpler.

  - Dmitri.

> On Tue, Dec 04, 2018 at 10:23:11AM +0900, Kazuho Oku wrote:
> > Therefore, man-on-the-side attack-resistant Initial exchange becomes
> > practical:
> > * if the server considers different initial ClientHellos as belonging
> >       to different connections
> >
> > [...]
> >
> > First point is what PR #2076 tries to address.
> 
> I would like to understand what server is expected to do.  Let's say
> it has several connections that have the same SCID/DCID.  Now the
> second packet from the client comes in:
> 
>     Is the server to try each of its connection candidates in
>     turn to see which one successfully decrypts the packet?
> 
>   - Dmitri.