IETF Logo Mail Archive

Re: [EXTERNAL] Re: ALPN negotiation (was Re: Add extension work to Interop matrix)

Lucas Pardue <lucaspardue.24.7@gmail.com> Thu, 09 January 2020 14:59 UTC

Return-Path: <lucaspardue.24.7@gmail.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 F2390120089 for <quic@ietfa.amsl.com>; Thu, 9 Jan 2020 06:59:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Level:
X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 vQcYI69-IZSX for <quic@ietfa.amsl.com>; Thu, 9 Jan 2020 06:59:40 -0800 (PST)
Received: from mail-vk1-xa32.google.com (mail-vk1-xa32.google.com [IPv6:2607:f8b0:4864:20::a32]) (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 C100D120019 for <quic@ietf.org>; Thu, 9 Jan 2020 06:59:40 -0800 (PST)
Received: by mail-vk1-xa32.google.com with SMTP id t129so2029028vkg.6 for <quic@ietf.org>; Thu, 09 Jan 2020 06:59:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=GS/iLnIUApWCWLNM1anGAIaqqNdL+x08oLoG7sRLi4Q=; b=Z0iGz5PRmCQpbIRwknb4X0T75aWOjyBbpY9bqd+u91CegRKXvD6LXIIShhIWppkUei q/FlTImPLljvSazHOd6PJX40Oy7ZvmITMWtvouP2Tc3XyZ15gNnNPwcEy8s/dMIXpTXZ hNDyj8pXyNKyFEvPqjgIlO2GYUpntYMSUXxBRHVwdlrZ7M8Ra0iuWSn/LTUXTnI9XSNN th7I+29/hFKAQHFNU6hHf68EtirjXaQEwkcQRkRwEqMzCdH7+m7Ybi4umHjp0/f4sFoa L1FlRfVroZ0VpX/Y5E1d0nTU/7jBFBriD42gJ6buwXuqPrbq/L3bLbVCytCy7DNPM1+C 1J4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=GS/iLnIUApWCWLNM1anGAIaqqNdL+x08oLoG7sRLi4Q=; b=d2aD6il2T8KzCLYUFkq5kXiDX6xT2kcZ75T4BenQgzDeBJJ303H0QvPux/r2HlZH4d tCQ4TjC39+jZpJ7BO22fjDXVUdiSrokNMJWzg8PZyh41XyR9+z0dvlJwJPRrTemi7D/4 nfCnpMxoClUycfHWiCsiCAqWMjYCeSUaXsbcE0M/p1pEj0Tjs88ECMjjTNi+ZmbFh6Y/ f2IPKBakqvsW9Y9E0ZXuUaZAwGldtzkWY2mpfKyl5gIHezCRK1YkrwKA9xN9xABmi+hl /4uS4mJN4xxd+4BFSBiEM6pVDNdilUWJu1krApzq86xgAlIjO9Utdfu97R03f+1aQnZ4 w8DA==
X-Gm-Message-State: APjAAAUuZPDUVztc9HYzpcwBjL5z3xsGhdc7+O5XmuJpEaXu0Ylg8Kf8 +KUuiDCJJ9zceDZe9EcRa3kWo+ozkCqto1MVXB8=
X-Google-Smtp-Source: APXvYqzJgW1JfTHbWsR38hNjbuME5edQh/PEOS2EZqTFWSBv+AEtDYBQyEZX6tCBzbdA4f9L1AL9f5AZcpE900bU4bk=
X-Received: by 2002:a1f:4d85:: with SMTP id a127mr6793239vkb.67.1578581979798; Thu, 09 Jan 2020 06:59:39 -0800 (PST)
MIME-Version: 1.0
References: <20200107143114.GC14229@ubuntu-dmitri> <d27fc30c-7f51-85f3-4bb1-e7b7b500ac72@huitema.net> <20200107194543.GK14229@ubuntu-dmitri> <BN8PR00MB045127DC046153EB655CAF1A8C3F0@BN8PR00MB0451.namprd00.prod.outlook.com> <20200109135420.GB7263@ubuntu-dmitri>
In-Reply-To: <20200109135420.GB7263@ubuntu-dmitri>
From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Thu, 09 Jan 2020 14:59:28 +0000
Message-ID: <CALGR9oYLSHWPeeC+KAtUBg6aE_yQoY90j5NC7tSiawinfZ6v=A@mail.gmail.com>
Subject: Re: [EXTERNAL] Re: ALPN negotiation (was Re: Add extension work to Interop matrix)
To: Andrei Popov <Andrei.Popov@microsoft.com>, Christian Huitema <huitema@huitema.net>, IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000027a17e059bb642e2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/93Vr4NzU4SVBwtUb6Pcj8Kd3B7k>
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: Thu, 09 Jan 2020 14:59:43 -0000

While writing up a response I was reminded of David Benjamin's TLS
Extensibility draft, draft-ietf-tls-grease-04 [1], which probably covers
some of the discussion in this thread and defines ALPN grease values.

If we want to do something QUIC specific we may want to incorporate some of
that. Interop tests would probably require some idea of the client knowing
what to expect the server to select, without that, how success is measured
is tricky (as mentioned above).

I'm starting to wonder if such a test becomes a little contrived though.
ALPN for HTTP/1.1 and HTTP/2 seems to be working fine on the Internet.
There might be merit in expanding the scope a little to think about testing
connection establishment including negotiation extension. The example case
is DATAGRAM, where "h3-NN" is agreed in ALPN but there is a mismatch of the
QUIC connection parameters for  max_datagram_frame_size.



[1] https://tools.ietf.org/html/draft-ietf-tls-grease-04

v2.23.0 | Report a Bug | By Email