Subject: [IPsec] Pre-meeting reading

From: Paul Hoffman <[email-masked]>
Date: Fri, 2 Nov 2012 18:08:47 -0700

Greetings again. Here's the agenda for Monday's meeting. Notice how many of those drafts you have not read? Imagine how much useful our time together will be if you, and most of the other people in the room or listening to the audio, had read them all!

--Paul Hoffman

IPsecME WG
Monday, November 5, 2012, 1740-1940

Easiest way to get slides: http://www.ietf.org/proceedings/85/ipsecme.html

Blue sheets, agenda -- 2 mins
WG status -- 5 mins
	draft-ietf-ipsecme-ad-vpn-problem
	ECDSA design team	

draft-ietf-ipsecme-ike-tcp -- 15 mins
	Status report
	Open issues
	Next steps

draft-kivinen-ipsecme-oob-pubkey  -- 15 mins
	Motivations
	Description of problem that is being solved
	Question about whether this updated 5996 to replace RSA raw key format

draft-mcgrew-ipsec-me-esp-ah-reqts  -- 15 mins
	Motivations
	Description of problem that is being solved

draft-zhang-ipsecme-multi-path-ipsec -- 15 mins
	Motivations
	Description of problem that is being solved

draft-harkins-ikev3 and draft-kivinen-ipsecme-ikev2-minimal -- 15 mins each
	Motivations
	Description of problem that is being solved

draft-mglt-mif-security-requirements -- 10 mins
	Introduction and where to follow up

draft-gont-opsec-vpn-leakages -- 10 mins
	Introduction and where to follow up

---

From: Daniel Migault <[email-masked]>
Date: Sat, 3 Nov 2012 14:46:29 +0100

Hi,

Here is an updated version of the draft-mglt-mif-security-requirements-03.
https://docs.google.com/file/d/0B4Irj7ik6yY1XzBTeVFrUjkxXzQ/edit

Best Regards,

Daniel

On Sat, Nov 3, 2012 at 2:08 AM, Paul Hoffman <[email-masked]> wrote:

> Greetings again. Here's the agenda for Monday's meeting. Notice how many
> of those drafts you have not read? Imagine how much useful our time
> together will be if you, and most of the other people in the room or
> listening to the audio, had read them all!
>
> --Paul Hoffman
>
> IPsecME WG
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Michael Richardson <[email-masked]>
Date: Sun, 04 Nov 2012 10:46:01 -0500

What in practice, for an implementer and/or his marketing manager, is
the difference between "MAY" for algorithm and not listing it at all? 

I would understand if we had "MAY+", but really, that is what "SHOULD" means.

Could there implications on UIs, such that things listed SHOULD/MUST
are listed in the first page, things listed MAY are on the "Advanced
options" page, and whatever country-specific vanity ciphers that might 
get included are under some even more obscure button.

Or is the intent of MAY to give a clue to cryptoanalysis people as to what
things to focus on? Or for people GREP'ing the RFC archives as a result
of an attack will come up with IPsec as a user/

-- 
Michael Richardson
-on the road-

---

From: Michael Richardson <[email-masked]>
Date: Sun, 04 Nov 2012 10:34:49 -0500

The question is, I think whether this is an extension to 5996, or an
update?    If an update, then it could obsolete payload 11?
Could new implementations decline to implement type 11?  I think that
this would be marginally acceptable.

-- 
Michael Richardson
-on the road-

---

From: "David McGrew (mcgrew)" <[email-masked]>
Date: Tue, 6 Nov 2012 00:16:07 +0000

Hi Michael,

>of an attack will come up with IPsec as a user/

For what it's worth, RFC 4835 has two MAYs, NULL authentication and
HMAC-MD5-96.  

My thinking was that it makes sense for the document to mention the
algorithm options that had been defined at the time of writing, so the
reader isn't left wondering.   There are other ways that this could be
dealt with other ways, though.  For instance, we could remove the MAYs
from the tables in Sections 2.2 and 2.3, and then add a new section that
says something like "The following algorithms were considered and it was
determined that there was no need for recommendation to implement, or not
to implement."  

Someone mentioned in the WG meeting that algorithms that were previously
SHOULDs, but have been deprecated to MAYs, should be included in the
tables going forward, so that the reader doesn't wonder where it went.
This seems like a good point to me.   AES-CTR is the one algorithm in that
category in the draft so far.

Thanks,

David

---

From: Michael Richardson <[email-masked]>
Date: Tue, 06 Nov 2012 13:25:24 -0500

David McGrew (mcgrew) <[email-masked]> wrote:
    DM> My thinking was that it makes sense for the document to mention
    DM> the algorithm options that had been defined at the time of
    DM> writing, so the reader isn't left wondering.  There are other

Surely we have lots of vanity crypto which has code points which aren't
in this document.?

    DM> Someone mentioned in the WG meeting that algorithms that were
    DM> previously SHOULDs, but have been deprecated to MAYs, should be
    DM> included in the tables going forward, so that the reader doesn't
    DM> wonder where it went.  This seems like a good point to me.
    DM> AES-CTR is the one algorithm in that category in the draft so
    DM> far.

I agree with this.

-- 
Michael Richardson
-on the road-