Re: [saag] Input for conflict review of draft-secure-cookie-session-protocol

Stephen Farrell <stephen.farrell@cs.tcd.ie> Sun, 21 October 2012 21:00 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 841D721F869C for <saag@ietfa.amsl.com>; Sun, 21 Oct 2012 14:00:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.532
X-Spam-Level:
X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8W5w-1KqRrKh for <saag@ietfa.amsl.com>; Sun, 21 Oct 2012 14:00:00 -0700 (PDT)
Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 613FB21F8435 for <saag@ietf.org>; Sun, 21 Oct 2012 14:00:00 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 823A117147A; Sun, 21 Oct 2012 21:59:58 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1350853198; bh=V/C+T6pq1WQ1tH Mm3T93DK8YltDrrFHYijBNpysGUm0=; b=5e84nwM0s40OfG61LiyIxrVk+xHwzp vPavMd/7EHI47uCdMbFWjFp408pblB2J0gxcoMxjrMOPT0IZUTTLGV5Tku57KKuF j7nPoT3eWP+QE184x4T8UaUM9CUkjUJv3azUQfgjuxBbl+gsQvG3PNoWYaqioBPz G5+BKr1b3O87uAyvmTr5SsPCuCtprmURBE1IOrfCKYJlkzqK1jiG7tuiZIf1F85b DwdoAssNa8Zpu0uv3qi1WfhJVl9qcEmG341rMGTw0BRi8z2Oqd/OuLqIXdst7WUM V4bv+HrTdK4m/6KkosKn2+d+qSodAJ27egn5JWKP5+75VQ2KZsDSS9TA==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id jauLb-UtSBMg; Sun, 21 Oct 2012 21:59:58 +0100 (IST)
Received: from [10.87.48.4] (unknown [86.44.64.186]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id B6528171478; Sun, 21 Oct 2012 21:59:52 +0100 (IST)
Message-ID: <50846248.5090403@cs.tcd.ie>
Date: Sun, 21 Oct 2012 21:59:52 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121017 Thunderbird/16.0.1
MIME-Version: 1.0
To: Thomas Fossati <tho@koanlogic.com>
References: <CALaySJKJR59dGJTPjnTRk+eo00+gyy8zs1=tLf8-v0EzP7TPuA@mail.gmail.com> <5083DB5B.6010401@cs.tcd.ie> <CAByMhx9FdYJ+UDnZD8C_uOhwUS_E-JJcSWmKLFG493S8E45eog@mail.gmail.com>
In-Reply-To: <CAByMhx9FdYJ+UDnZD8C_uOhwUS_E-JJcSWmKLFG493S8E45eog@mail.gmail.com>
X-Enigmail-Version: 1.4.5
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: draft-secure-cookie-session-protocol@tools.ietf.org, saag@ietf.org, Nevil Brownlee <rfc-ise@rfc-editor.org>
Subject: Re: [saag] Input for conflict review of draft-secure-cookie-session-protocol
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Oct 2012 21:00:05 -0000

Hi Thomas,

On 10/21/2012 08:49 PM, Thomas Fossati wrote:
> Hi Stephen,
> 
> On Sun, Oct 21, 2012 at 12:24 PM, Stephen Farrell
> <stephen.farrell@cs.tcd.ie> wrote:
>> What do folks (incl. authors) think of that?
> 
> I think you've hit the point, and (as author) I share the proposed way-out.
> I only have a bit of concern about sticking the name of a company in
> the title, which seems quite an unusual practice... 

Actually, its relatively common for independent-stream RFCs that
specify protocols to be called "<company>'s <foo> protocol"

S.

> Would
> "HTTP-friendly authentication tokens" be a less controversial
> synthesis for what SCS actually is ?
>