Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
 by ietfa.amsl.com (Postfix) with ESMTP id DC11E130FF7
 for <quic-issues@ietfa.amsl.com>; Fri,  7 Dec 2018 10:15:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.46
X-Spam-Level: 
X-Spam-Status: No, score=-9.46 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001,
 MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key)
 header.d=github.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 R4fKW6zt2re6 for <quic-issues@ietfa.amsl.com>;
 Fri,  7 Dec 2018 10:15:16 -0800 (PST)
Received: from out-10.smtp.github.com (out-10.smtp.github.com [192.30.254.193])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by ietfa.amsl.com (Postfix) with ESMTPS id 61341130FAB
 for <quic-issues@ietf.org>; Fri,  7 Dec 2018 10:15:16 -0800 (PST)
Date: Fri, 07 Dec 2018 10:15:14 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com;
 s=pf2014; t=1544206515;
 bh=xqpJsGP5OfQny+dC+O/h2Rmo+rOk27QnFZHjHKkJby8=;
 h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID:
 List-Archive:List-Post:List-Unsubscribe:From;
 b=A89/zMSaF7g02SlUhLBrVbzUpatSo7VNH8WW7q56p+Wvhvoi2pwplMalsIfc597+9
 KoUEQnw1YI7UemZrntwFIg7nuvBnlkkYoFPMWtDHx4dROYd0k1jMjwOndHCqzTYndE
 uU68zpjRigAJrxLC3Id4uaZ23+Sha+NezYQug3ts=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+0166e4aba3273e33c77fa742fb20b7e790faf0772086b05a92cf0000000118227ab292a169ce16f92d74@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2064/c445318555@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2064@github.com>
References: <quicwg/base-drafts/pull/2064@github.com>
Subject: Re: [quicwg/base-drafts] Amplification attack using retry tokens and
 spoofed addresses (#2064)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_5c0ab8b2e3fe1_44913fd6172d45c4199942";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/RQ9F0auI8O81RPbs7s4nCF7QkLg>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG
 <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>,
 <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>,
 <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Dec 2018 18:15:23 -0000


----==_mimepart_5c0ab8b2e3fe1_44913fd6172d45c4199942
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

@marten-seemann 
> I don't a short token life time works as a protection here. I expect servers to issue tokens (in NEW_TOKEN frames) that have the same life time as TLS session tickets, which, if I remember correctly, is a 7 days.

I am not sure if that's correct. IIUC, the reason we split information that are maintained across connections to TLS session tickets and tokens was because they have different properties, including lifetime. Tokens are per-path objects and they should have a short span. If that's not clear, I think we should clarify that.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2064#issuecomment-445318555
----==_mimepart_5c0ab8b2e3fe1_44913fd6172d45c4199942
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p><a class=3D"user-mention" data-hovercard-type=3D"user" data-hovercard-=
url=3D"/hovercards?user_id=3D1478487" data-octo-click=3D"hovercard-link-c=
lick" data-octo-dimensions=3D"link_type:self" href=3D"https://github.com/=
marten-seemann">@marten-seemann</a></p>
<blockquote>
<p>I don't a short token life time works as a protection here. I expect s=
ervers to issue tokens (in NEW_TOKEN frames) that have the same life time=
 as TLS session tickets, which, if I remember correctly, is a 7 days.</p>=

</blockquote>
<p>I am not sure if that's correct. IIUC, the reason we split information=
 that are maintained across connections to TLS session tickets and tokens=
 was because they have different properties, including lifetime. Tokens a=
re per-path objects and they should have a short span. If that's not clea=
r, I think we should clarify that.</p>

<p style=3D"font-size:small;-webkit-text-size-adjust:none;color:#666;">&m=
dash;<br />You are receiving this because you are subscribed to this thre=
ad.<br />Reply to this email directly, <a href=3D"https://github.com/quic=
wg/base-drafts/pull/2064#issuecomment-445318555">view it on GitHub</a>, o=
r <a href=3D"https://github.com/notifications/unsubscribe-auth/AWbkqxlizn=
QDK_vd_RlF8PyxQInJiZc2ks5u2rAygaJpZM4Y4UIy">mute the thread</a>.<img src=3D=
"https://github.com/notifications/beacon/AWbkqx5_8MQUcOKa4jPcityPbRHlX2F9=
ks5u2rAygaJpZM4Y4UIy.gif" height=3D"1" width=3D"1" alt=3D"" /></p>
<script type=3D"application/json" data-scope=3D"inboxmarkup">{"api_versio=
n":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name"=
:"GitHub"},"entity":{"external_key":"github/quicwg/base-drafts","title":"=
quicwg/base-drafts","subtitle":"GitHub repository","main_image_url":"http=
s://assets-cdn.github.com/images/email/message_cards/header.png","avatar_=
image_url":"https://assets-cdn.github.com/images/email/message_cards/avat=
ar.png","action":{"name":"Open in GitHub","url":"https://github.com/quicw=
g/base-drafts"}},"updates":{"snippets":[{"icon":"PERSON","message":"@kazu=
ho in #2064: @marten-seemann \r\n\u003e I don't a short token life time w=
orks as a protection here. I expect servers to issue tokens (in NEW_TOKEN=
 frames) that have the same life time as TLS session tickets, which, if I=
 remember correctly, is a 7 days.\r\n\r\nI am not sure if that's correct.=
 IIUC, the reason we split information that are maintained across connect=
ions to TLS session tickets and tokens was because they have different pr=
operties, including lifetime. Tokens are per-path objects and they should=
 have a short span. If that's not clear, I think we should clarify that."=
}],"action":{"name":"View Pull Request","url":"https://github.com/quicwg/=
base-drafts/pull/2064#issuecomment-445318555"}}}</script>
<script type=3D"application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/quicwg/base-drafts/pull/2064#issuecomment-4=
45318555",
"url": "https://github.com/quicwg/base-drafts/pull/2064#issuecomment-4453=
18555",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
},
{
"@type": "MessageCard",
"@context": "http://schema.org/extensions",
"hideOriginalBody": "false",
"originator": "AF6C5A86-E920-430C-9C59-A73278B5EFEB",
"title": "Re: [quicwg/base-drafts] Amplification attack using retry token=
s and spoofed addresses (#2064)",
"sections": [
{
"text": "",
"activityTitle": "**Kazuho Oku**",
"activityImage": "https://assets-cdn.github.com/images/email/message_card=
s/avatar.png",
"activitySubtitle": "@kazuho",
"facts": [

]
}
],
"potentialAction": [
{
"name": "Add a comment",
"@type": "ActionCard",
"inputs": [
{
"isMultiLine": true,
"@type": "TextInput",
"id": "IssueComment",
"isRequired": false
}
],
"actions": [
{
"name": "Comment",
"@type": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n\"commandName\": \"IssueComment\",\n\"repositoryFullName\": \=
"quicwg/base-drafts\",\n\"issueId\": 2064,\n\"IssueComment\": \"{{IssueCo=
mment.value}}\"\n}"
}
]
},
{
"name": "Close pull request",
"@type": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n\"commandName\": \"PullRequestClose\",\n\"repositoryFullName\=
": \"quicwg/base-drafts\",\n\"pullRequestId\": 2064\n}"
},
{
"targets": [
{
"os": "default",
"uri": "https://github.com/quicwg/base-drafts/pull/2064#issuecomment-4453=
18555"
}
],
"@type": "OpenUri",
"name": "View on GitHub"
},
{
"name": "Unsubscribe",
"@type": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n\"commandName\": \"MuteNotification\",\n\"threadId\": 4174157=
30\n}"
}
],
"themeColor": "26292E"
}
]</script>=

----==_mimepart_5c0ab8b2e3fe1_44913fd6172d45c4199942--

