IETF Logo Mail Archive

Re: [TLS] SNI with early data

Kazu Yamamoto ( 山本和彦 ) <kazu@iij.ad.jp> Thu, 20 July 2017 12:27 UTC

Return-Path: <kazu@iij.ad.jp>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED32E12EC30 for <tls@ietfa.amsl.com>; Thu, 20 Jul 2017 05:27:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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=iij.ad.jp
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 rvhfiptq8tBz for <tls@ietfa.amsl.com>; Thu, 20 Jul 2017 05:27:29 -0700 (PDT)
Received: from omgo.iij.ad.jp (mo901.iij.ad.jp [202.232.31.77]) (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 5C215127058 for <tls@ietf.org>; Thu, 20 Jul 2017 05:27:29 -0700 (PDT)
DKIM-Signature: v=1;a=rsa-sha256;c=relaxed/simple;d=iij.ad.jp;h=Date: Message-Id:To:Cc:Subject:From:In-Reply-To:References:Mime-Version: Content-Type:Content-Transfer-Encoding; i=kazu@iij.ad.jp; s=omgo2; t=1500553642; x=1501763242; bh=X6zGPP4glJA6/NyU8OnbyX8wUs5HZLwBkbmF/I52Ufg=; b=x7U0Aqh5rJOONq y85Ce/iA8L2ksGwzn6UITthD6bhtTtm59UgXfILI+oTxXpWXVXe7Bt+FYcsAyPswluNqvDsBcmZjD nD3USXcF4o1hR1Jw0t05lIx3kMHCF+uQ8c1OgDPqvdwOqkraOKa+iLPXoDYKt+SNh9o818eHlGnba HwvB0c9gcun0wfsIupUCDKmXmLY2hQRiT/0YC6r+46J+2aW8tAGiIt9wPqt8WWl4x09r5bv28XnOv w1pLqvsu8BY2FarSiZb7OxHezWxuezjzLkPjotyNYNxMgFtcyBPkRVGD/uv4rL/LZQGbiXCyKmE0V MlpE4gBuZtP8Iy71Rj9w==;
Received: by omgo.iij.ad.jp (mo901) id v6KCRMpe001392; Thu, 20 Jul 2017 21:27:22 +0900
X-Iguazu-Qid: 33PuiKDfF3YaEw6jVQ
Date: Thu, 20 Jul 2017 21:27:18 +0900
Message-Id: <20170720.212718.2253444584236714400.kazu@iij.ad.jp>
To: frodo@baggins.org
Cc: tls@ietf.org
From: Kazu Yamamoto <kazu@iij.ad.jp>
In-Reply-To: <CAMoSCWatQZDT8qUv7EqmTH_FJ4OjrSTXVY+he6qw6MmfJ_w8vg@mail.gmail.com>
References: <CAMoSCWatQZDT8qUv7EqmTH_FJ4OjrSTXVY+he6qw6MmfJ_w8vg@mail.gmail.com>
X-Mailer: Mew version 6.7 on Emacs 25.1 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/8i7zGF26FhPOoHvfiIfjka9EZQ4>
Subject: Re: [TLS] SNI with early data
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Jul 2017 12:27:31 -0000

Hi Matt,

You might be also interested in this issue:

https://github.com/tlswg/tls13-spec/issues/1040

--Kazu

> I note in draft-21 the following text:
> 
>    When clients use a PSK obtained externally to send early data, then
>    the following additional information MUST be provisioned to both
>    parties:
> 
>    -  The TLS version number for use with this PSK
> 
>    -  The cipher suite for use with this PSK
> 
>    -  The Application-Layer Protocol Negotiation (ALPN) protocol
>       [RFC7301], if any is to be used
> 
>    -  The Server Name Indication (SNI), if any is to be used
> 
> Later it says this:
> 
>    In order to accept early data, the server MUST have accepted a PSK
>    cipher suite and selected the first key offered in the client's
>    "pre_shared_key" extension.  In addition, it MUST verify that the
>    following values are consistent with those negotiated in the
>    connection during which the ticket was established.
> 
>    -  The TLS version number and cipher suite.
> 
>    -  The selected ALPN [RFC7301] protocol, if any.
> 
> 
> The language about "during which the ticket was established" seems to
> suggest that the following checks do not apply to an external PSK -
> which I don't think is intended. Additionally there does not seem to
> be a requirement on the server to check that the SNI is consistent.
> So, there is a mandatory requirement for an external PSK to specify
> the SNI, but no requirement on the server to check that it is actually
> correct. Is this discrepancy intentional?
> 
> Matt
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

v2.23.0 | Report a Bug | By Email