Subject: [Emu] Ben Campbell's No Objection on charter-ietf-emu-04-00: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Wed, 07 Feb 2018 18:13:49 -0800

Ben Campbell has entered the following ballot position for
charter-ietf-emu-04-00: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-emu/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Substantive:

First bullet point: "or other new concerns." makes this very open ended. Is
this planned to be a standing working group? If not, can we put some
constraints around "other new concerns"?

The prohibition against obsoleting RFCs seems harsh. It's possible to require
backwards compatibility without this restriction. I think it should be up to
the working group to decide whether work can be better organized using updates
or bis-drafts.

 The Feb 2019 milestone seems like two milestones.

Editorial:

-3rd paragraph: "And the
understanding of security threats in today's Internet evolves as
well,..."

I suggest dropping "And"

-- 2nd bullet: This is a bit hard to parse. I suggest:

OLD:
    Update the EAP-AKA' specification (RFC 5448) to ensure that its
     capability to provide a cryptographic binding to network context
     stays in sync with what updates may come to the referenced 3GPP
     specifications through the use of EAP in 5G.
NEW:
     Update the EAP-AKA' specification (RFC 5448) to ensure that its
     capability to provide a cryptographic binding to network context
     stays in sync with any 5G related updates to the referenced 3GPP
     specifications.

Same bullet point: The second paragraph seems out of place; was it intended to
be its own bullet point?

4th bullet point: The second sentence seems like a non-sequiter. I suggest a
top-level bullet point for "Analyzing opportunities to improve privacy..."

---

From: Jari Arkko <[email-masked]>
Date: Sun, 18 Feb 2018 13:46:09 +0200

Hi Ben,

And thanks for your feedback.

> constraints around "other new concerns”?

Understood.

Note that the sentence starts with “Update the security considerations…”
so the goal of these updates is about discovering new vulnerabilities and
the like; not any random other concerns. That being said, the text already
covers new vulnerabilities, so may be this is merely unnecessary text.

How about the following text:

OLD:
    Update the security
    considerations relating to EAP TLS, to document the implications
    of using new vs. old TLS version, any recently gained new
    knowledge on vulnerabilities, and the possible implications of
    pervasive survellaince or other new concerns.

NEW:

    Update the security
    considerations relating to EAP TLS, to document the implications
    of using new vs. old TLS version, any recently gained new
    knowledge on vulnerabilities, and the possible implications of
    pervasive surveillance.

(Also updates a typo.)

> the working group to decide whether work can be better organized using updates

There was a detailed discussion among the participants about this aspect and
a reasonable, strong opinion that the current EAP-TLS RFC remain as
the primary, and that the new RFC would be an update to it when it comes
to TLS 1.3.

That being said, hmm… even my own draft for EAP-AKA’ bis currently says
“Obseletes RFC 5448 (if approved”)… so… how about this:

OLD:

The current RFCs shall not be obsoleted but
rather updated with either new information or instructions on
what is needed, for instance, to employ a new TLS version.

NEW:

The current EAP-TLS RFCs shall not be obsoleted but
rather updated with either new information or instructions on
what is needed, for instance, to employ a new TLS version.

> I suggest dropping “And"

Yes.

For Kathleen’s benefit, listing this in OLD/NEW style:

OLD:

And the
understanding of security threats in today's Internet evolves as
well, which has driven some of the evolution in these underlying
technologies.

NEW:

The
understanding of security threats in today's Internet evolves as
well, which has driven some of the evolution in these underlying
technologies.

>     stays in sync with any 5G related updates to the referenced 3GPP

Seems good. Thanks.

> Same bullet point: The second paragraph seems out of place; was it intended to

I don’t have a strong opinion, but the two somewhat separate issues
were listed under the same bullet item since both of them should
go into the same draft (rfc5448bis). The EAP TLS bullet item
does the same thing, i.e., update tech + describe new knowledge
of vulnerabilities.

> top-level bullet point for "Analyzing opportunities to improve privacy..."

I’d be fine with that. Suggested text:

OLD:

  - Develop an extension to EAP-AKA' such that Perfect Forward Secrecy
    can be provided. There may also be privacy improvements that
    have become feasible with the introduction of recent identity
    privacy improvements in 3GPP networks.

NEW:

  - Analysing opportunities to improve privacy in EAP-AKA’. 

    Develop an extension to EAP-AKA' such that Perfect Forward Secrecy
    can be provided.

    There may also be other privacy improvements that
    have become feasible with the introduction of recent identity
    privacy improvements in 3GPP networks.

Jari

---

From: Ben Campbell <[email-masked]>
Date: Sun, 18 Feb 2018 11:32:26 -0600

Thanks, Jari, this all looks good to me.

Ben.

> On Feb 18, 2018, at 5:46 AM, Jari Arkko <[email-masked]> wrote:
> 
> Hi Ben,
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 19 Feb 2018 11:35:13 -0500

Thank you Ben and Jari.  The updates will appear shortly int he new version.

Best regards,
Kathleen

On Sun, Feb 18, 2018 at 12:32 PM, Ben Campbell <[email-masked]> wrote:
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu
>

-- 

Best regards,
Kathleen