Re: [Unbearable] Ben Campbell's Discuss on draft-ietf-tokbind-https-14: (with DISCUSS and COMMENT)
Andrei Popov <Andrei.Popov@microsoft.com> Tue, 26 June 2018 21:19 UTC
Return-Path: <Andrei.Popov@microsoft.com>
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98D3C130EEF; Tue, 26 Jun 2018 14:19:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.02
X-Spam-Level:
X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 oiLEHKF3o8hj; Tue, 26 Jun 2018 14:19:36 -0700 (PDT)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0138.outbound.protection.outlook.com [104.47.32.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73E77130EF3; Tue, 26 Jun 2018 14:19:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7/V4ut8Y4ghjVemliDbTDD0xsqVJgkM/HsXJ7nqn6YU=; b=E/QptJCA2breoU5aLh+pecqikIwSuv+wmWYSblidoH1aRPjV4ryoXhN7cs47s7SY/01HSOwFmfvz3Hs/GcKkpW6HoSUC/EdennXQmcpnqzl7tN+To3Af+VRdx4BfyS2xxERwTKMccWpYEX5/JXm7Ve7REh9hPxvFbZChHyBfQ+Y=
Received: from CY4PR21MB0774.namprd21.prod.outlook.com (10.173.192.20) by CY4PR21MB0472.namprd21.prod.outlook.com (10.172.121.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.930.0; Tue, 26 Jun 2018 21:19:34 +0000
Received: from CY4PR21MB0774.namprd21.prod.outlook.com ([fe80::9d01:113b:290a:750b]) by CY4PR21MB0774.namprd21.prod.outlook.com ([fe80::9d01:113b:290a:750b%3]) with mapi id 15.20.0930.005; Tue, 26 Jun 2018 21:19:34 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: John Bradley <ve7jtb@ve7jtb.com>, Ben Campbell <ben@nostrum.com>
CC: Eric Rescorla <ekr@rtfm.com>, Dirk Balfanz <balfanz=40google.com@dmarc.ietf.org>, "draft-ietf-tokbind-https@ietf.org" <draft-ietf-tokbind-https@ietf.org>, Tokbind WG <unbearable@ietf.org>, IESG <iesg@ietf.org>, "tokbind-chairs@ietf.org" <tokbind-chairs@ietf.org>
Thread-Topic: [Unbearable] Ben Campbell's Discuss on draft-ietf-tokbind-https-14: (with DISCUSS and COMMENT)
Thread-Index: AQHT59XA5IIayh1w/kSwtbPg5+4zz6RQtRGAgCE0KwCAAUGXgIAAAMlwgAAEBACAACWQAIAAAHkAgAABTlA=
Date: Tue, 26 Jun 2018 21:19:34 +0000
Message-ID: <CY4PR21MB077453A70AC47C98C59C21088C490@CY4PR21MB0774.namprd21.prod.outlook.com>
References: <152589833077.4037.7403393365772291429.idtracker@ietfa.amsl.com> <CADHfa2Aj9_-X-rtPR7OU-_cEXC=MnHpv88O_HTmB0-Yd-X_LLA@mail.gmail.com> <CABcZeBOb9G3jTnOg6ucba2060EqObM8LEo9F16mCCvwdHaU9=A@mail.gmail.com> <94E6261D-7920-4C65-BDB3-A0B3144323C5@nostrum.com> <CY4PR21MB0774D87B730D6A726AA272568C490@CY4PR21MB0774.namprd21.prod.outlook.com> <097D19CC-EAB7-4F9F-98C4-B4030B838464@nostrum.com> <CAANoGhJXuHiSGB8zY4cGqf4xpkbqCjWExJwL1ou1vXSRn3mUvw@mail.gmail.com> <CAANoGh+7BNCKo9NQhh4qvAKeoUFVeYkY6VJ7wBLRz=sRDmoVwA@mail.gmail.com>
In-Reply-To: <CAANoGh+7BNCKo9NQhh4qvAKeoUFVeYkY6VJ7wBLRz=sRDmoVwA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:80e8:8:28b5:a023:971b:e42c]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0472; 7:37tOsQ8iSD0uVT5F0GB41dkUNOmAzY7ICp6FmcVtj+r20q8HNalfivlTnosBHawSdmcnpPwSukxGLinW3GHAxv8GS/Vr43cq71L/65SxJlHykrOgO9RK/BF2GaVBv1D0hW41/gzFX4Cqa5qkmdd3e2EQowpGY932d10QRskT2y1BEDzh7G6mCuWKxO17fftHirto6+6d7cbEc4ESbVIZ9NY1HGmgLhMBqpR+8A9L0RUh/26ZIrxMG3hFnqr4yjwp
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 307f44fa-ca8b-492d-c109-08d5dbaa83ac
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600026)(711020)(48565401081)(2017052603328)(7193020); SRVR:CY4PR21MB0472;
x-ms-traffictypediagnostic: CY4PR21MB0472:
x-microsoft-antispam-prvs: <CY4PR21MB0472D1D448AB157A07E3F4EA8C490@CY4PR21MB0472.namprd21.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(278428928389397)(89211679590171)(120809045254105)(275740015457677)(189930954265078)(219752817060721)(21748063052155);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(3231254)(2018427008)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:CY4PR21MB0472; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0472;
x-forefront-prvs: 071518EF63
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39860400002)(396003)(136003)(376002)(366004)(13464003)(189003)(51914003)(199004)(5250100002)(6436002)(97736004)(8936002)(25786009)(606006)(4326008)(8990500004)(81166006)(81156014)(99286004)(2906002)(229853002)(86612001)(86362001)(476003)(11346002)(14444005)(54896002)(486006)(55016002)(256004)(6306002)(22452003)(316002)(5660300001)(93886005)(54906003)(110136005)(446003)(6116002)(19609705001)(6346003)(33656002)(72206003)(53936002)(478600001)(46003)(76176011)(2900100001)(68736007)(53546011)(186003)(7696005)(10090500001)(106356001)(105586002)(8676002)(6246003)(790700001)(10290500003)(7736002)(14454004)(966005)(74316002)(9686003)(236005)(102836004)(6506007); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0472; H:CY4PR21MB0774.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com;
x-microsoft-antispam-message-info: n3M/c25Qg5EZTGkepp9pT+N5ahkkm7VFelMcZu9nbKV0OA7B/TwF6PETLpK80uy0JGTjO2bmxMxgw4YDIU21KMXIn7XqY882Z0x/F61KfQWkhkAl3h5UMF1NVSlGGS2J0Swcg3AjKuuuI+pNzkjboAZ+D98fA+1rAGsAIewJUYJo3fN1RLeo9nC7PhdCzlORbs/OQdqdnFbaJzlpxMyO75qEmjoagmNZTPeZpqO0pbpaBSykhQxWFH7nQQVoYNrYIksM1XfqEye8syaWkg97axFvRfQ8nJjVGMK4n4mISR58TK9wttDTbWWjdUrp15lLJfucbkeGRvJ7iQlgwpkJgf0XHDi/jdILFzFEe8jUGxg=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY4PR21MB077453A70AC47C98C59C21088C490CY4PR21MB0774namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 307f44fa-ca8b-492d-c109-08d5dbaa83ac
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2018 21:19:34.1722 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0472
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/8mXlixVorz3ekqPfsCUWb51jYcE>
Subject: Re: [Unbearable] Ben Campbell's Discuss on draft-ietf-tokbind-https-14: (with DISCUSS and COMMENT)
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" <unbearable.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/unbearable>, <mailto:unbearable-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/unbearable/>
List-Post: <mailto:unbearable@ietf.org>
List-Help: <mailto:unbearable-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/unbearable>, <mailto:unbearable-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jun 2018 21:19:58 -0000
Done: https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/. From: John Bradley <ve7jtb@ve7jtb.com> Sent: Tuesday, June 26, 2018 2:14 PM To: Ben Campbell <ben@nostrum.com> Cc: Andrei Popov <Andrei.Popov@microsoft.com>; Eric Rescorla <ekr@rtfm.com>; Dirk Balfanz <balfanz=40google.com@dmarc.ietf.org>; draft-ietf-tokbind-https@ietf.org; Tokbind WG <unbearable@ietf.org>; IESG <iesg@ietf.org>; tokbind-chairs@ietf.org Subject: Re: [Unbearable] Ben Campbell's Discuss on draft-ietf-tokbind-https-14: (with DISCUSS and COMMENT) PS I suppose we need DIRK OR Andre to push a version with the changes. John B. On Tue, Jun 26, 2018, 5:12 PM John Bradley <ve7jtb@ve7jtb.com<mailto:ve7jtb@ve7jtb.com>> wrote: Thanks Ben. EKR once this Discuss is cleared are we good to move on to the final embrace of the RFC editor? Regards John B. On Tue, Jun 26, 2018, 2:58 PM Ben Campbell <ben@nostrum.com<mailto:ben@nostrum.com>> wrote: > On Jun 26, 2018, at 1:54 PM, Andrei Popov <Andrei.Popov@microsoft.com<mailto:Andrei.Popov@microsoft.com>> wrote: > > Hi Ben, > > Thanks for the review. > >> Are the “applications” from paragraph 3 the same as those from paragraph 2? > > Yes, the same throughout paragraphs 1, 2 and 3. > >> It seems like paragraph 2 is talking more about local APIs (at least, I see that was mentioned in the text in version 17 but not in 18), but paragraph 3 uses an example of a signal from a server. (I can accept that the difference in control may be weak enough for web applications that the distinction does not matter.) > > The APIs provided by the TB implementation and called by the application are local APIs. > The application needs to make a decision whether to request that the TB implementation include a Referred binding in the TB message or not. > In the example, the server provides a signal to the application using the Include-Referred-Token-Binding-ID HTTP response header. > The signal could be different, or an application may have out-of-band ways to determine this (e.g. a local database of RP->IDP associations). I just re-read the 3rd paragraph, and I think I missed the “then” in “which then signals” on the first reading. It’s fine as is. Thanks! Ben. > > Cheers, > > Andrei > > -----Original Message----- > From: Ben Campbell <ben@nostrum.com<mailto:ben@nostrum.com>> > Sent: Tuesday, June 26, 2018 11:41 AM > To: Eric Rescorla <ekr@rtfm.com<mailto:ekr@rtfm.com>> > Cc: Dirk Balfanz <balfanz=40google.com@dmarc.ietf.org<mailto:40google.com@dmarc.ietf.org>>; draft-ietf-tokbind-https@ietf.org<mailto:draft-ietf-tokbind-https@ietf.org>; Tokbind WG <unbearable@ietf.org<mailto:unbearable@ietf.org>>; The IESG <iesg@ietf.org<mailto:iesg@ietf.org>>; John Bradley <ve7jtb@ve7jtb.com<mailto:ve7jtb@ve7jtb.com>>; tokbind-chairs@ietf.org<mailto:tokbind-chairs@ietf.org> > Subject: Re: [Unbearable] Ben Campbell's Discuss on draft-ietf-tokbind-https-14: (with DISCUSS and COMMENT) > > Hi, thanks for the pointer. > > The text in version 18 is sufficient to clear my discuss. I have one remaining (or maybe new) non-blocking question for section 6: > > Are the “applications” from paragraph 3 the same as those from paragraph 2? It seems like paragraph 2 is talking more about local APIs (at least, I see that was mentioned in the text in version 17 but not in 18), but paragraph 3 uses an example of a signal from a server. (I can accept that the difference in control may be weak enough for web applications that the distinction does not matter.) > > I did not check my editorial comments. > > Thanks! > > Ben. > >> On Jun 25, 2018, at 6:30 PM, Eric Rescorla <ekr@rtfm.com<mailto:ekr@rtfm.com>> wrote: >> >> Ben, >> >> Does the following new text address your concern: >> https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?modeAsFormat=html/a<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fxml2rfc.tools.ietf.org%2Fcgi-bin%2Fxml2rfc.cgi%3FmodeAsFormat%3Dhtml%2Fa&data=02%7C01%7CAndrei.Popov%40microsoft.com%7Cf57a905ae88e4850fb8808d5dba9d524%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636656444842164263&sdata=Y%2BREp5UE5Jm9yUeshFJ1eXblnfs0C5W31uG%2Fk6mtIO0%3D&reserved=0> >> scii&url=https://raw.githubusercontent.com/TokenBinding/Internet-Draft<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fraw.githubusercontent.com%2FTokenBinding%2FInternet-Draft&data=02%7C01%7CAndrei.Popov%40microsoft.com%7Cf57a905ae88e4850fb8808d5dba9d524%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636656444842174271&sdata=Lg7YBDv2yEZP3pYMkztxew9u34xhtNnY8ocvLuujD8M%3D&reserved=0> >> s/master/draft-ietf-tokbind-https-18.xml >> >> >> On Mon, Jun 4, 2018 at 1:26 PM, Dirk Balfanz <balfanz=40google..com@dmarc.ietf.org<mailto:40google..com@dmarc.ietf.org>> wrote: >> Hi Ben, >> >> thanks for the feedback. Most of it is addressed in the new draft (https://tools.ietf.org/html/draft-ietf-tokbind-https-16<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-tokbind-https-16&data=02%7C01%7CAndrei.Popov%40microsoft.com%7Cf57a905ae88e4850fb8808d5dba9d524%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636656444842184279&sdata=IJHYDJSWoUy5Ao8EWj1lHn8s5WuqTCD%2FH5hAVbmMdVk%3D&reserved=0>). See below (inline) for details. >> >> On Wed, May 9, 2018 at 1:38 PM Ben Campbell <ben@nostrum.com<mailto:ben@nostrum.com>> wrote: >> Ben Campbell has entered the following ballot position for >> draft-ietf-tokbind-https-14: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut >> this introductory paragraph, however.) >> >> >> Please refer to >> https://www.ietf.org/iesg/statement/discuss-criteria.html<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html&data=02%7C01%7CAndrei.Popov%40microsoft.com%7Cf57a905ae88e4850fb8808d5dba9d524%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636656444842184279&sdata=irsD0beoR1vbnMm%2FB5vrDF4gwAs4HHulXEumzjFJj0M%3D&reserved=0> >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-tokbind-https%2F&data=02%7C01%7CAndrei.Popov%40microsoft.com%7Cf57a905ae88e4850fb8808d5dba9d524%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636656444842194288&sdata=m3aq2LeWis4PZmysUZeVb%2Fai%2BqEaewg%2BAlv8BB68%2FxM%3D&reserved=0> >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> I plan to ballot "YES", but I want to clear up once concern first: >> >> After reading section 6 several times, I don't know what it means. I >> think it's [...] >> >> Addressed in new draft. >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Substantive Comments: >> >> §1.1: Please consider using the boilerplate from 8174 across the >> cluster. Both this and the protocol draft have lower case keyword instances. >> >> Addressed in new draft. >> >> >> §8.2: >> - Does it really make sense to wait for a user to request the keys be expired? >> I suspect the average user does this about never. Did the working >> group discuss possibly making the keys default to expiring after some period of time? >> >> Yes, we did discuss it. This was chosen consciously to be in sync with cookies and their expirations / manual user-initiated purges. >> >> - Why >> is the SHOULD in paragraph 2 not a MUST? >> >> Addressed in new draft. >> >> >> Editorial Comments: >> >> §2: >> - Paragraph 1: "The ABNF of the Sec-Token-Binding header field is (in >> [RFC7230] style, see also Section 8.3 of [RFC7231]):" The open parenthesis before "in" >> seems misplaced. Also, as written the comma after "style" creates a >> comma splice. (Note that this pattern occurs elsewhere in the >> document.) >> >> - Paragraph 3: The paragraph is a single hard-to-parse sentence. >> Please consider breaking into simpler sentences. >> >> Addressed in new draft. >> >> >> - example: Am I correct to assume the backslashes are just for print >> purposes and are not in the actual message? If so, please mention that. >> >> Addressed in new draft. >> >> >> § 2.1: >> - first paragraph, "Within the latter context...": There was no former context. >> I suggest "Within that context..." >> >> Addressed in new draft. >> >> - 2nd paragraph: The first sentence is hard to parse. I suggest >> breaking it into separate paragraphs, or restructure without the >> center-imbedding. >> >> Addressed in new draft. >> >> - 2nd to last paragraph: Does "SHOULD generally" >> mean the same as just "SHOULD"? >> >> Addressed in new draft. >> >> >> §5.1: 2nd paragraph: Unneeded comma in "... itself, to another server..." >> >> Addressed in new draft. >> >> >> §5.2, >> - last bullet: " (between client and Token Consumer)" seems more than >> parenthetical. Please consider removing the parentheses. >> >> Addressed in new draft. >> >> - paragraph after last >> bullet: The parenthetical phrase starting with "(proving >> possession...) is quite long and makes the sentence hard to parse. >> Given that the concept is covered in the immediately preceding paragraph, can it be removed? >> >> Addressed in new draft. >> >> >> §7.1 and §7.2: These sections seem to be copied from (or restate >> requirements >> in) the protocol and negotiation drafts. Can they be included by >> reference instead, or at least attributed? >> >> Addressed in new draft. >> >> >> §7.2, 2nd paragraph: This seams like a restatement of §7.1. >> >> Addressed in new draft. >> >> >> §8.3: Unneeded comma in first sentence. >> >> Addressed in new draft. >> >> Thanks again for the thoughtful comments! >> >> Dirk. >> >> _______________________________________________ >> Unbearable mailing list >> Unbearable@ietf.org<mailto:Unbearable@ietf.org> >> https://www.ietf.org/mailman/listinfo/unbearable<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Funbearable&data=02%7C01%7CAndrei.Popov%40microsoft.com%7Cf57a905ae88e4850fb8808d5dba9d524%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636656444842194288&sdata=NLYzqLIc9d9qH0VTbDcC%2BYdYaSR%2Bs653eBpQ6Alk%2FbA%3D&reserved=0> >> >> >
- Re: [Unbearable] Ben Campbell's Discuss on draft-… Eric Rescorla
- Re: [Unbearable] Ben Campbell's Discuss on draft-… Andrei Popov
- Re: [Unbearable] Ben Campbell's Discuss on draft-… John Bradley
- Re: [Unbearable] Ben Campbell's Discuss on draft-… John Bradley
- Re: [Unbearable] Ben Campbell's Discuss on draft-… Ben Campbell
- Re: [Unbearable] Ben Campbell's Discuss on draft-… Andrei Popov
- Re: [Unbearable] Ben Campbell's Discuss on draft-… Ben Campbell
- Re: [Unbearable] Ben Campbell's Discuss on draft-… Eric Rescorla
- [Unbearable] Ben Campbell's Discuss on draft-ietf… Ben Campbell
- Re: [Unbearable] Ben Campbell's Discuss on draft-… Dirk Balfanz