Re: Alternative ways to keeps ODCID on the server

Christian Huitema <huitema@huitema.net> Tue, 28 January 2020 00:09 UTC

Return-Path: <huitema@huitema.net>
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 720C83A114D for <quic@ietfa.amsl.com>; Mon, 27 Jan 2020 16:09:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 LtGHvwsjQlfk for <quic@ietfa.amsl.com>; Mon, 27 Jan 2020 16:09:57 -0800 (PST)
Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B9E43A114B for <quic@ietf.org>; Mon, 27 Jan 2020 16:09:57 -0800 (PST)
Received: from xse268.mail2web.com ([66.113.197.14] helo=xse.mail2web.com) by mx37.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1iwES3-0006qC-A1 for quic@ietf.org; Tue, 28 Jan 2020 01:09:56 +0100
Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4866SL2Xkhz1mMn for <quic@ietf.org>; Mon, 27 Jan 2020 16:09:54 -0800 (PST)
Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1iwES2-0005jB-7M for quic@ietf.org; Mon, 27 Jan 2020 16:09:54 -0800
Received: (qmail 7345 invoked from network); 28 Jan 2020 00:09:53 -0000
Received: from unknown (HELO [192.168.1.105]) (Authenticated-user:_huitema@huitema.net@[172.58.46.251]) (envelope-sender <huitema@huitema.net>) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for <quic@ietf.org>; 28 Jan 2020 00:09:53 -0000
Subject: Re: Alternative ways to keeps ODCID on the server
To: Kazuho Oku <kazuhooku@gmail.com>, Ian Swett <ianswett=40google.com@dmarc.ietf.org>, Marten Seemann <martenseemann@gmail.com>, IETF QUIC WG <quic@ietf.org>
References: <20200124222434.GA8279@ubuntu-dmitri> <7b228c14-c0d3-6458-77ab-945e713ef429@huitema.net> <CAOYVs2qhPBtbjrVEXE+oMXWUWRBqhzDfZsiOatRW5Zd67e1sWg@mail.gmail.com> <ee0f625b-b260-9e3d-12b6-80291fc110eb@huitema.net> <CAKcm_gNKu5b__cjy5212pWN=PKwdZKX23rXHs423-u8hZMjr+w@mail.gmail.com> <20200125135411.GA19655@ubuntu-dmitri> <CANatvzyTHXog=46wwpmVshkYcY0YFGdvWXj0dGjKVUj0dXa7pA@mail.gmail.com>
From: Christian Huitema <huitema@huitema.net>
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8=
Message-ID: <f25d2034-0938-f716-c356-5873eeb58cda@huitema.net>
Date: Mon, 27 Jan 2020 16:09:56 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <CANatvzyTHXog=46wwpmVshkYcY0YFGdvWXj0dGjKVUj0dXa7pA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Originating-IP: 66.113.197.14
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.197.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.11)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0YfsolMNZcEgL2mqy3zzv3mpSDasLI4SayDByyq9LIhVCmDszCcl/fI2 D3yDKYAq9ETNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDcnqpk5VeF3xR4kF6iVwRtbgN zB/4Jkrw1eDLcif59ft4ZAzz0D20WjtwnPf8qRgmU7Tmz6iKnkQL9gqsxD347235Nhqq+/HvroPq 8GSPg+7KJix/R2qbtdH2ZflMjNgfMm/JD3cPBOX47Hg3FEpDo46jSvfpO+1kZkomjtjB6X5Q5Q9f RUeIpTIC2ySfqvnqLwoxlgatmaBb0rBiK9xbkDrUqzcKIief90MVLZY9LbIZh9+IQ1oS9LBn3VIP 95Jz7ujRlJ9wSMlhvaudJXZ9EIBG/qaR+8r9SKFMmPJLf850OvZYsmoVQuOIhwKLK6IKBNB4LZ0v UHHKTzJX7b1JhLSQQ4vSj0QEim26t/Moy0UPX5E73H1QfrH/5kkrV/Cr0bm2vWdo8usP65i82q1C dZgGrpL44wdx9eXqjQjbvUopOMQJvQ/Ck3iiU+4DQAj3fuQgzT3K9JUHTNiGwfwAm4Mn5ODoMuXT e61GOROcBldP1gB2VhyL18pVuJYmbB3RAWB9VtuInwtVSpvsBYw9eQeYUOp7A73HI6oJg7w/VocK FIxNlsy2WJpil5s07kEDyBw3j/aBxjxoZyMqfIL/jJq7xqDoiTjjGpNS1XGXbXLAL4l3nUyswZIn 8yRupTACAztqzrCt4TZ/wLtujY/tpftciEiqouGJBZyO6KT73SipeRtU2OIeUIKMcqvqa+rkPAlb DjazCbhs7qBpykynMvtDTtO+u9LH2FRC7Cqll7UjBRkzNE01ZvxVb15SjDSHNWOfRy3it5pbjqbJ QF61U112fwop9BTafX0DKHjywhGbO+8nMRYL9kekVL4dhx06ifnL+9wgoTj4ygNPw1XfN0zsCG5v xMF5WG1gYscNCfISP4VPJRUjPgTf43t5z5OGMMhkxyAKDRV/o3FuwxpnRHnKFOL2qbwhklIekV0n lts=
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/hjq4HPdBsa6Pf3poBFWZNXqz1tM>
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: Tue, 28 Jan 2020 00:09:58 -0000

On 1/27/2020 2:39 PM, Kazuho Oku wrote:

> I am not sure if I agree with dropping the sentence.
>
> IIRC, this sentence (i.e. "server MAY proceed with the connection
> without verifying the token, though the server MUST NOT consider the
> client address validated.") suggests that a server might proceed the
> handshake as if it did not receive the token when that token cannot be
> used.
>
> I think that is not an unreasonable thing to do along with the other
> two stated option (i.e. discard packet, send CONNECTION_CLOSE without
> creating state).

That's actually what I implemented. If the token can be verified, accept
the connection, treat it as validated. If it cannot be verified, check
whether the token is necessary, e.g., would any incoming connection
trigger retry. If it is necessary, drop the connection; if not
necessary, continue as if no token was there.

-- Christian huitema