IETF Logo Mail Archive

Re: Requiring per application data in session ticket seems wrong

Benjamin Kaduk <bkaduk@akamai.com> Fri, 13 September 2019 16:42 UTC

Return-Path: <bkaduk@akamai.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 0C6FA1200DB for <quic@ietfa.amsl.com>; Fri, 13 Sep 2019 09:42:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 aubWNIElY6Ng for <quic@ietfa.amsl.com>; Fri, 13 Sep 2019 09:42:55 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 932801200D7 for <quic@ietf.org>; Fri, 13 Sep 2019 09:42:55 -0700 (PDT)
Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id x8DGfxuU024200; Fri, 13 Sep 2019 17:42:49 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : content-transfer-encoding : in-reply-to; s=jan2016.eng; bh=b5B5HrISieAMhvRHn6fFixN44G8T+I1GDDp0JZT98v8=; b=Ri+ZZL7XjhQQMxXEog+lLwI5xlm3c/8PV4IgAsyYM71jnkahxmWsUBlt9tor43hRd8Dj CSOaOf2/erVnbebkjF7ePP1kv1Y3IkdtQQWvEXXpex3O7Hx485lXRsUdQhbmm0yG8lDG XT2rkiFcIp+hF2feFQZ+R4wx75Syh+zVidQIfG18hkMeZkzTV3s4ODe/fWobIvhOG3Vk pLo4/Z+OdnuCX72tIzLvJlYs5AgZ4ADcXgQwMILg3vi0D89FmBE7MOR2EUnvkEVSjiZW 4HVin6mXN9w3K9tKEluovBhBC6oTb3vDyqYZdTrtXPt2rxdogIZ7jD1SkZHCxHql0Hkx 9g==
Received: from prod-mail-ppoint4 (prod-mail-ppoint4.akamai.com [96.6.114.87] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2uytcnv9b5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 13 Sep 2019 17:42:49 +0100
Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x8DGWr5f016527; Fri, 13 Sep 2019 12:42:48 -0400
Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint4.akamai.com with ESMTP id 2uyth4e9h7-1; Fri, 13 Sep 2019 12:42:45 -0400
Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id 6A19920067; Fri, 13 Sep 2019 16:42:34 +0000 (GMT)
Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from <bkaduk@akamai.com>) id 1i8oeW-0003rB-TC; Fri, 13 Sep 2019 09:42:32 -0700
Date: Fri, 13 Sep 2019 09:42:32 -0700
From: Benjamin Kaduk <bkaduk@akamai.com>
To: Christian Huitema <huitema@huitema.net>
Cc: IETF QUIC WG <quic@ietf.org>
Subject: Re: Requiring per application data in session ticket seems wrong
Message-ID: <20190913164232.GN3806@akamai.com>
References: <a3d65ce8-6075-5f39-9532-d24fad6da572@huitema.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <a3d65ce8-6075-5f39-9532-d24fad6da572@huitema.net>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-09-13_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=653 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1909130167
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.70,1.0.8 definitions=2019-09-13_07:2019-09-11,2019-09-13 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 adultscore=0 mlxlogscore=662 impostorscore=0 malwarescore=0 bulkscore=0 lowpriorityscore=0 spamscore=0 mlxscore=0 priorityscore=1501 phishscore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1909130169
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/Z9UDj_QzbQE4Ke2Lk9kU1u29yQE>
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: Fri, 13 Sep 2019 16:42:57 -0000

On Thu, Sep 12, 2019 at 09:52:01PM -0700, Christian Huitema wrote:
> I am busy implementing draft-23 in picoquic, and I found out the new
> section 5.4. of the transport draft, "Required Operations on
> Connections".  It is fine, except for the requirements that servers are
> able to encode application specific settings in the session resume
> tickets. This makes the ticket specific to the combination of SNI +
> ALPN, instead of just SNI as implied by RFC 8446. Seems like a bad idea.
> More discussion in https://github.com/quicwg/base-drafts/issues/3028.

It's not clear to me that this specifically makes the ticket tied to the
ALPN, but rather that a given ticket (still tied to SNI) may or may not
have some additional information that allows for additional
functionality when used with a specific ALPN.  A ticket with that
additional information could well be used with a different ALPN and the
same SNI (though the logistics of getting additional information in
place that would allow a single ticket to get enhanced functionality
with more than one ALPN could be challenging.  In this case, if you
don't have that additional information, you can't use early data, for example.

-Ben

v2.23.0 | Report a Bug | By Email