Subject: Re: [IPsec] Charter review

From: Michael Richardson <[email-masked]>
Date: Mon, 03 Nov 2014 20:44:10 -0500

Kathleen Moriarty <[email-masked]> wrote:
    > The chairs provided text for an updated charter in line with the newly
    > adopted working group items.  The recharter text has been posted and
    > I'd like to give the WG a little time to comment prior to adding this
    > to a telechat for review.

    > Here is a link:

    > http://datatracker.ietf.org/doc/charter-ietf-ipsecme/

I agree with Paul Wouters that inclusion of channel binding into the charter
is probably premature, and does not really jive with opportunistic security
concepts that the application should not know/care that it is private,
as there should be no extra authorization implied.

Channel Binding is clearly easiest to implement if you can annotate
individual TCP connections with their security properties, and this is
probably easiest to do if you do kernel modifications.
However, the draft-ietf-btns-abstract-api (which was never published) was
designed specifically so that it did not require kernel changes, and proof of
concept implementation back in 2005 (ish) did not require kernel changes.

Still, I think that channel binding should be left off the charter for now:
mostly because I don't think that we have the right people here to actually
get the work done in a way that would result in a deployed standard.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian Weis <[email-masked]>
Date: Tue, 4 Nov 2014 21:21:23 -0600

On Oct 31, 2014, at 4:05 PM, Kathleen Moriarty <[email-masked]> wrote:

> Hi,

I support the work item looking at defending against DDoS, and have no objection to the opportunistic work item (after omitting the wording on channel binding).

Brian

> Thanks.
> Best regards,
> Kathleen
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

-- 
Brian Weis
Security, Enterprise Networking Group, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 6 Nov 2014 15:36:01 -0800 (PST)

On Tue, November 4, 2014 7:21 pm, Brian Weis wrote:
> On Oct 31, 2014, at 4:05 PM, Kathleen Moriarty
> <[email-masked]> wrote:
>
>> Hi,
>>
> I support the work item looking at defending against DDoS, and have no
> objection to the opportunistic work item (after omitting the wording on
> channel binding).

  +1

  How about we also get rid of the mention of a formal security proof
of opportunistic encryption? The security is just that afforded by D-H.

  Dan.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 6 Nov 2014 21:03:07 -0500 (EST)

> of opportunistic encryption? The security is just that afforded by D-H.

Maybe replace it with wording to ensure opportunistic <word> will not
reduce the security of the non-opportunstic parts that might be added.

I think that was the mean concern.

Paul

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 07 Nov 2014 10:03:24 +0200

<hats off>

Regarding formal security proofs, I strongly disagree.

The current wording is extremely mild. It does not require an actual 
security proof (which would not be realistic), but says "The solution 
should be in line with current best practices, including ... possible
formal protocol security proofs."

This to me means that people have looked at the modified protocol and 
can say that the new stuff does not inhibit such a security proof in the 
future, and that we formally understand the security properties that are 
supposed to be provided by the protocol.

We are making a major change to IKE, and as much as I care about its 
goals, we should try to do it right. Relying on "the security afforded 
by DH" is not easy when in the real world, both peers might be reusing 
exponents and/or using too short DH groups.

Thanks,
	Yaron

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 7 Nov 2014 06:08:19 -0800 (PST)

> exponents and/or using too short DH groups.

  This "major change" is to remove authentication. Peers reusing
exponents is already entirely permissible in IKE. Authenticating a
reused exponent does not change the problem caused by reusing
an exponent. I don't even know what "too short DH groups" are but
if you can do it in IKE with authentication then what's the issue that
is introduced when you take away authentication?

  I welcome the new interest in formal security proofs in the IETF but
I don't think this particular charter change compels one.

  regards,

  Dan.