NEW_TOKEN token should be encrypted

Kazuho Oku <kazuhooku@gmail.com> Fri, 22 March 2019 00:29 UTC

Return-Path: <kazuhooku@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 A8DFC131286 for <quic@ietfa.amsl.com>; Thu, 21 Mar 2019 17:29:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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] 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lb-SZ0t-E_eb for <quic@ietfa.amsl.com>; Thu, 21 Mar 2019 17:29:28 -0700 (PDT)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 EE96713126A for <quic@ietf.org>; Thu, 21 Mar 2019 17:29:27 -0700 (PDT)
Received: by mail-lj1-x22c.google.com with SMTP id l7so558699ljg.6 for <quic@ietf.org>; Thu, 21 Mar 2019 17:29:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=SWhFbXjRBXSTZH6C3sqH1BvH368fJANPYbdmythhEeo=; b=pqjEtxQGZpruCI1/74woBwWLWbS6O5L0EyXUY5APonnHwfgkXJoM7ECT1/zjBA7ByQ VPpAJPRPTQxjWUzv0vV5xvhxWjjsXQBf5VKcVhgtYoT2YJsKibsr7NLc0izobDEOrvYq M9E1eV62qnjzRGdwsdZrZWznVHgy47AmM/ykVj9AjDGeWrlRx/+vE3mhJwbHWwGSNabT oxITlCfhSpzcZa9/OsgafkfzX6C9KaTVrub/t2dPDRfzfiu4OayBi7rofw1BCPSbhda8 +2IHia9BCwf+pKQdu8GzVPLP6dV29eF8bhQqsFEtUQftvWRODi6SqJvlc8WyxtZUvN37 OpWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=SWhFbXjRBXSTZH6C3sqH1BvH368fJANPYbdmythhEeo=; b=lTPyeh6GJ/mJD06BfltgoKPbrVtyhM6nCQze/IT2BQ5jsPAXCdnGoNEAWIkV5Pv7NF a6nFokYi+dkoQuRLD7W74NlLhpD5sYTI2spcbkf4XtkMXlYTJoYbT/Jh2Zu6IjSihFVa wcYM4AnrDh3E19HLcOgey7m48ZZsRvYDo2crePlJRHZG66pZAm11+KuYHbBIAzeEOcWc 0VR82qCcISXSZEvjPUrGAd3u52MnZHB6IHfTktWGrmw9+eyc65tJSILsEi5ssoAqYmkG GwmVCzqUWjPmRdDkO9Dh+ErSs8TZnRi3sxSw6c6lsmEi7t0Beg/gkWRUrQAa96hEehiJ tfew==
X-Gm-Message-State: APjAAAXxVa8MZNjcF5ldkkZxvPLIB6ZLjUmerCca4WHCoW1pfHnArgJQ 3h7BE/MjioAbjx4Pz4CzvCi/tdicfbiVN7vdonX1jUhy
X-Google-Smtp-Source: APXvYqzH22sqXkvR5Vp+ZUpxqHz/gjTz5SBeSUwSPXNuSOtuSG3UMYHH8RzVCyOFYowkNL2/rh097JzduqhBOZE/l24=
X-Received: by 2002:a05:651c:114:: with SMTP id a20mr3510332ljb.53.1553214566018; Thu, 21 Mar 2019 17:29:26 -0700 (PDT)
MIME-Version: 1.0
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Fri, 22 Mar 2019 09:29:14 +0900
Message-ID: <CANatvzwmNxt5m06yYgfqs0G-nPJXPhRPgR76_QvxiOmWhSqbig@mail.gmail.com>
Subject: NEW_TOKEN token should be encrypted
To: IETF QUIC WG <quic@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/qLx9IncF8iV-37IJ6H0TM8hjP28>
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, 22 Mar 2019 00:29:31 -0000

As stated in https://github.com/quicwg/base-drafts/issues/2543, my
understanding is that a token sent in a NEW_TOKEN frame SHOULD be
encrypted. The only exception would be the case of the token carrying
only an opaque and randomly-generated key identifier in a stateful
design (i.e. a server using a key-value store to retain the
information of previous connections).

Otherwise, an observer can use the information contained in the token
sent in an resuming connection, to correlate that connection to the
previous connection that issued the token. For example, if a server
includes the generation time of the token in plaintext, an observer
can extract that information found in an Initial packet to nail down
the connection that issued the token.

While I think we might be call this an editorial issue, I think we
should clarify this as a normative requirement (e.g., SHOULD). Hence
bringing the discussion to the mailing list as well.

-- 
Kazuho Oku