Re: [saag] Additions to RFC 3631?

Steven Bellovin <smb@cs.columbia.edu> Mon, 21 May 2012 18:09 UTC

Return-Path: <smb@cs.columbia.edu>
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 55B7821F8611 for <saag@ietfa.amsl.com>; Mon, 21 May 2012 11:09:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syOkFy5EFB9M for <saag@ietfa.amsl.com>; Mon, 21 May 2012 11:09:39 -0700 (PDT)
Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by ietfa.amsl.com (Postfix) with ESMTP id 9141021F85DF for <saag@ietf.org>; Mon, 21 May 2012 11:09:39 -0700 (PDT)
Received: from [192.168.2.166] (74-92-112-54-Philadelphia.hfc.comcastbusiness.net [74.92.112.54]) (user=smb2132 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id q4LI9XXh015915 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 21 May 2012 14:09:34 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset="us-ascii"
From: Steven Bellovin <smb@cs.columbia.edu>
In-Reply-To: <CAK3OfOjJviVNPpHfsie_KToVfO2rNB3Bq6MgkQvfuPSSKMhkog@mail.gmail.com>
Date: Mon, 21 May 2012 14:09:33 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <89DF3552-70F5-4110-8FDB-70C642610776@cs.columbia.edu>
References: <300A2E9F-E99B-46FA-A101-E3611BD0D197@cs.columbia.edu> <877gw69h81.fsf@latte.josefsson.org> <4FB9ECA4.3010904@gmail.com> <D54BB652-9B1D-4A19-8F8F-AF288E4ADE24@cs.columbia.edu> <78F24BEE-DD3B-474D-9E0B-1AC73CBE373A@vpnc.org> <CAK3OfOj=jR4R+hBDTcv-DNqqU0AdHHonSTOmsMpR3ZqmhDmbdQ@mail.gmail.com> <416327B2-6E60-4D09-B3E7-D314F4FDD4E1@cs.columbia.edu> <CAK3OfOjJviVNPpHfsie_KToVfO2rNB3Bq6MgkQvfuPSSKMhkog@mail.gmail.com>
To: Nico Williams <nico@cryptonector.com>
X-Mailer: Apple Mail (2.1278)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, IETF Security Area Advisory Group <saag@ietf.org>
Subject: Re: [saag] Additions to RFC 3631?
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: Mon, 21 May 2012 18:09:40 -0000

On May 21, 2012, at 2:07 02PM, Nico Williams wrote:

> On Mon, May 21, 2012 at 12:59 PM, Steven Bellovin <smb@cs.columbia.edu> wrote:
>> On May 21, 2012, at 1:06 49PM, Nico Williams wrote:
>>> On Mon, May 21, 2012 at 11:42 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:>>> +1 to adding EAP as a mechanism.
>>>> 
>>>> +/-0 to adding channel bindings, given how few people understand them.
>>> 
>>> EIther it's important/useful or not.  If it is then having some text
>>> in this RFC would help those people who don't understand CB.
>>> 
>> I agree.
> 
> But is it important/useful?
> 
> Given that MSFT has implemented and deployed it I think it's at least useful.
> 
> I do think CB is important -- certainly as a protocol design/analysis
> tool.  I also think it should be used more often.  You'd think I would
> think that, given that I'm the author of RFC5056, but I like to think
> that I'm objective enough on this topic...  enough so that I can tell
> you what the biggest problem with CB is: the fact that it's one more
> thing that the application developer has to know about and do.  It'd
> be nice if more of the protocol stack up to and including
> application-layer authentication (where there is the option to do
> that) were abstracted.  Still, CB is relatively simple: extract the CB
> from the channel, feed it to authentication.


Thinking further, I'm not sure how much text should be in 3631bis, as opposed
to just having a pointer to 5056.  But that's a minor point.

		--Steve Bellovin, https://www.cs.columbia.edu/~smb