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
- NEW_TOKEN token should be encrypted Kazuho Oku
- Re: NEW_TOKEN token should be encrypted Mikkel Fahnøe Jørgensen
- Re: NEW_TOKEN token should be encrypted Kazuho Oku
- Re: NEW_TOKEN token should be encrypted Mikkel Fahnøe Jørgensen
- Re: NEW_TOKEN token should be encrypted Martin Thomson
- Re: NEW_TOKEN token should be encrypted Kazuho Oku