IETF Logo Mail Archive

[TLS] SNI and Resumption/0-RTT

Eric Rescorla <ekr@rtfm.com> Fri, 21 October 2016 00:34 UTC

Return-Path: <ekr@rtfm.com>
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 B25E21294BB for <tls@ietfa.amsl.com>; Thu, 20 Oct 2016 17:34:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 DIbFyEs5Mj45 for <tls@ietfa.amsl.com>; Thu, 20 Oct 2016 17:34:23 -0700 (PDT)
Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::22b]) (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 109F712947D for <tls@ietf.org>; Thu, 20 Oct 2016 17:34:23 -0700 (PDT)
Received: by mail-yb0-x22b.google.com with SMTP id g68so34921962ybi.0 for <tls@ietf.org>; Thu, 20 Oct 2016 17:34:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=Mm+Z2YXC+q6Uh75ynZtKKBvf3608fkhpOvPbmKDx/90=; b=Z74OZNrVie1QWoZPC/IOcVrwL2ohApE9Q/D+nSiDxdgigb6y51ARr+2V8Ju2MQ1ujg adP6yFVG56mMWRyJ+rrDODaFZpC72KBmbbuPO/rznpJDQrTnPgPbQz48lef5/dDpN+Kw YgE1wofuMEZF1s5zeQHMozGC3JBhnDr+znDzQkkK2/U1ESHat8+r/Hu2dRxwG2UcMPtB cgoMtt34/6xKnrdBWBxmY/65l3RaXPuClk3DujKzGgrMXExiMJmb13tW8ft0AHqzSTiM IxQ6ZRw4g3VwC2GYkircvsCMI9xNJIVrtwL//LCN/wM/p14ATiCUYo6U3Yu9z3rzMK8+ GfzA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Mm+Z2YXC+q6Uh75ynZtKKBvf3608fkhpOvPbmKDx/90=; b=KnYjCLuDGPC5u74j1n1cHlKE7fszIMfTeZFVcCCkVsjJMAu/vGNKiVdCjB4E2mtOFs imPHHHCJ5qGBfhdtWwgfIhxm45dPGRNPtUhCJAfrBnHv5kqVqpSsKCgwEXFFh7lBQqJj wucIJ4qegWNt2NLfh/ujOJtz4bqP5TaGjsuFjGGuzhmDzHZxtHGmTQjErC3NnQszg4ox 3eRsQHjLDj3tp6OOm+BIn2CC2EO4cZ0ylv5df8pZb1sJ+MsbRbonfs0JSLpWNvfgLbnA uC28fcb5pIKzhViZ84TPlL02xgtnIZWAEcr8gaKN/ijOJOVU9btBZe8tur5gkDmEb5/0 9c2A==
X-Gm-Message-State: AA6/9RmUon8W1niF6i9d/hqsuRuWDhvJ3CCUiuS2WaQQHxaO5dTOYPPDp8RwqKpm7fB5DJRNzjklAl/5oa96WA==
X-Received: by 10.37.246.15 with SMTP id t15mr4703824ybd.107.1477010061899; Thu, 20 Oct 2016 17:34:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.82.210 with HTTP; Thu, 20 Oct 2016 17:33:41 -0700 (PDT)
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 20 Oct 2016 17:33:41 -0700
Message-ID: <CABcZeBNroww_zA0BRsMrZPMCrF42b2OZPsQNZ9w0bjPoF+fSHw@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="f403045da0a611f418053f5534d2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/kBh_EFgrP3s62SZ301wLChblDL0>
Subject: [TLS] SNI and Resumption/0-RTT
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 21 Oct 2016 00:34:25 -0000

We used to explicitly say that you had to check SNI for 0-RTT (but
didn't say anything about resumption). On the principle that 0-RTT and
resumption should be the same I removed that, but it turns out that
the document doesn't actually have any rule at all other than the one
we've inherited from RFC 6066, which clearly says that you can't
resume with a different SNI [0].

Following the discussion in
https://github.com/tlswg/tls13-spec/issues/720 I've added a statement
to the draft clarifying that the RFC 6066 rule still applies [1]

With that said, it does seem like there might be situations where it
would be useful to allow resumption/0-RTT with different SNIs. My
intuition (partly informed by [2]) is that this is something we should
be pretty careful about and have the server opt-in explicitly (if at
all) but I'm willing to be wrong about that.

Comments?
-Ekr


[0] https://tools.ietf.org/rfcmarkup?doc=6066#section-3
[1]
https://github.com/tlswg/tls13-spec/commit/b26093b5e9143fb61f5b619d1da78c4ba54b2121
[2] http://antoine.delignat-lavaud.fr/doc/www15.pdf

v2.23.0 | Report a Bug | By Email