Subject: [anonsec] revision of proposed WG charter

From: Black_David at emc.com ([email-masked])
Date: Fri Nov 19 16:15:19 2004

Joe,

> > Doing the requirements work here could help line up binding requirements
> > with the other requirements that motivate this work whereas asking
> > others to draw up requirements externally could result in a draft that
> > requires public keys and certificates for binding, necessitating AD
> > intervention to sort out the resulting uproar when this group objects
> > to the requirements.  OTOH, I could see the usage guidelines for binding
> > being done outside, although I'd be tempted to try to roll them into
> > one draft with the requirements, as the result is probably more useful.
> > 
> > Thanks,
> > --David
> 
> <BOF chair hat on>
> 
> Doing binding requirements work here seems off-topic, and likely to 
> diffuse the effort of this group. While there are some who feel that 
> binding motivates this work, there are others who feel this work is 
> critical even without binding. Further, there is certainly utility to 
> the binding work elsewhere (assuming conventional IKE) as well (not all 
> certificates have the same meaning or strength). 

I think we have to agree to disagree at this point.  While binding is
doubtless off-topic for the initial problems that motivated BTNS, I
think it's within scope of what ought to be done, as it has the
potential to considerably broaden applicability and usability of
the results to additional protocols.  Your current proposal for
a "do not preclude" promise to adhere to the requirements of an
externally generated requirements draft strikes me as all but
ruling out channel binding, as some of the potential contents of
that draft have already generated strong opposition in this discussion.

I would like to see a good faith effort to support binding as opposed
to immediately siding with "others who feel this work is critical even
without binding".  If compromise between those who want binding and
those who care primarily about leap-of-faith style authentication
proves unworkable, then pruning binding from the scope may make sense
later.

Perhaps what we need is to stop arguing over which form of binding
to choose and provide support for both:
- Binding to certificates where available.
- Binding to DH or similar exchange where possible.
- Otherwise, I'm not sure ...

Thanks,
--David

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri Nov 19 16:26:48 2004

<bof hat still on>

> Joe,
...
> that draft have already generated strong opposition in this discussion.

The key question is whether we have to solve the channel bindings system 
problem before we can solve how to integrate it with this work. If so, 
that adds substantially to the effort, at least.

<hat off>
If BTNS requires channel bindings, then it's not reducing deployment 
effort, but increasing it. BTNS must be useful in the absence of channel 
bindings -first-, IMO.
<hat back on>

> - Otherwise, I'm not sure ...

I'd like to have the AD (Sam) weigh in on this. He appeared to feel 
strongly about the 'does not preclude' issue.

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/anonsec/attachments/20041119/7a385cbd/signature.bin