[TLS] Fwd: New Version Notification for draft-kazuho-protected-sni-00.txt

Kazuho Oku <kazuhooku@gmail.com> Wed, 19 July 2017 03:42 UTC

Return-Path: <kazuhooku@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id A38D012EAA5 for <tls@ietfa.amsl.com>; Tue, 18 Jul 2017 20:42:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id JnsA6vR4Lftb for <tls@ietfa.amsl.com>; Tue, 18 Jul 2017 20:42:26 -0700 (PDT)
Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (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 3A9C412783A for <tls@ietf.org>; Tue, 18 Jul 2017 20:42:26 -0700 (PDT)
Received: by mail-pf0-x236.google.com with SMTP id o88so14383809pfk.3 for <tls@ietf.org>; Tue, 18 Jul 2017 20:42:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=z20/5ftQrcISiWQ7TB3T2Sdgc/Rfm0ouHMZGqmUJMJ0=; b=NM1/tKUD3MLL5YXA+r1c1y0+SjBShhobE4jvbZodIa2ywsTZ1Qb+xcaswXOFOHxElU Qafw03gxMbF7q+wNaRUmf42cdSEBXOrJUFyzjDqXhGbAH/55nvBJL8WGChax1SoKAY+n IeLZ8cittfCIk+WQn/yM4LrJIjdI3Cw6GvVkz93TQ3ClXfJk2eSPgfXrsnf2qUQ7iPPq laGG7ghlPNV97DRcOSDXHtY/ptwkI6yZsOHxJ/c2Zpd9zObbDq0ZI6aNLewMQKThmlLo 6J9roLawsUxl4Xus2DGTBn4hrrwpJqPOVNxNv/tv3yguKeG5UFxbolkY83q1HcQtO3RO 7lWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=z20/5ftQrcISiWQ7TB3T2Sdgc/Rfm0ouHMZGqmUJMJ0=; b=iaSIoKeOSDcNS+Lt+p2Ido17paZxkDkprEAO6kKeXrKXBbL82LOpAGeiDMklIpATYG N55FNCKhX4sBg+U95hm+DBYV6yveE3y3mHBlWEzKYavJn+gQfjkUGjWM6nL275Y7FCFZ Rjea05myVad4CQAKAxKO/W6x92bGs0b9C8nmz1LLeSkSmZPgXceSxgCoUINGJ7xgGIqn 41sOpz81ndI1gn8PFzMC+pNw6J0BrFL5SyfApSBL3mt5fA+KNJOadmJW1Zqdv6q3RwtC 0DoC4hNbK0SqK0OOG/LDGFuORnpauZHS8vBstr6O3fQU8/IF2s+qMlior4AfxKc6S2Yq n7AQ==
X-Gm-Message-State: AIVw1131ji52gTY4yfpfsXokyg6k9q57GXa3ElWyb4U62vY6rpHUWuF6 a/PgoINTdnhLg74CfCN4Yz/+WlyAoA==
X-Received: by with SMTP id p2mr938708pge.194.1500435745609; Tue, 18 Jul 2017 20:42:25 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 18 Jul 2017 20:42:24 -0700 (PDT)
In-Reply-To: <150043553129.25392.13213180786681889232.idtracker@ietfa.amsl.com>
References: <150043553129.25392.13213180786681889232.idtracker@ietfa.amsl.com>
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Wed, 19 Jul 2017 05:42:24 +0200
Message-ID: <CANatvzyus----nLQE4qAVY4E3sfnXetUHJLAMj3JcCahkhZGRA@mail.gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/1NSddDPV_2Ob4_lItclZ1n9LfqE>
Subject: [TLS] Fwd: New Version Notification for draft-kazuho-protected-sni-00.txt
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: Wed, 19 Jul 2017 03:42:29 -0000


I am happy to see us having discussions on how to protected SNI. I am
also happy to see that draft-huitema-tls-sni-encryption [1] proposes
actual methods that we might want to use, and that the I-D discusses
about various attack vectors that we need to be aware of.

On the other hand, as stated on the mailing list an on the mic, I am
not super happy with the fact that the proposed methods have a
negative impact on connection establishment time.

So here goes my straw-man proposal, as an Internet Draft:

In essence, the draft proposes of sending information (e.g.,
semi-static (EC)DH key) to bootstrap encryption in ClientHello as a
DNS record. Clients will use the obtained (EC)DH key to encrypt SNI.

Since DNS queries can run in parallel, there would be no negative
performance impact, as long as DNS responses can be obtained in a
single RTT.

The draft mainly discusses about sending a signed bootstrap
information together with the certificate chain, since doing so is not
only more secure but opens up other possibilities in the future (such
as 0-RTT full handshake). However, since transmitting a bootstrap
record with digital signature and identity is unlikely to fit in a
single packet (and therefore will have negative performance impact
until DNS over TLS or QUIC becomes popular), the draft also discusses
the possibility of sending the EC(DH) key unsigned in the "Things to
Consider" section.

I would appreciate it if you could give me comments / suggestions on
the proposed approach. Thank you in advance.

[1] https://datatracker.ietf.org/doc/draft-huitema-tls-sni-encryption/

---------- Forwarded message ----------
From:  <internet-drafts@ietf.org>;
Date: 2017-07-19 5:38 GMT+02:00
Subject: New Version Notification for draft-kazuho-protected-sni-00.txt
To: Kazuho Oku <kazuhooku@gmail.com>;

A new version of I-D, draft-kazuho-protected-sni-00.txt
has been successfully submitted by Kazuho Oku and posted to the
IETF repository.

Name:           draft-kazuho-protected-sni
Revision:       00
Title:          TLS Extensions for Protecting SNI
Document date:  2017-07-19
Group:          Individual Submission
Pages:          9
Status:         https://datatracker.ietf.org/doc/draft-kazuho-protected-sni/
Htmlized:       https://tools.ietf.org/html/draft-kazuho-protected-sni-00

   This memo introduces TLS extensions and a DNS Resource Record Type
   that can be used to protect attackers from obtaining the value of the
   Server Name Indication extension being transmitted over a Transport
   Layer Security (TLS) version 1.3 handshake.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

Kazuho Oku