Subject: Re: Last Call: <draft-harkins-owe-05.txt> (Opportunistic Wireless Encryption) to Informational RFC

From: Stephen Farrell <[email-masked]>
Date: Mon, 16 Jan 2017 16:35:40 +0000

Hi Dan, Warren,

The (extended) last call for this is now over.

There were minor comments from the gen-art [1] and opsdir
reviews (not sent to a list?) and some additional editorial
comments received offlist (from IEEE folks I believe).

As promised, I also asked some IEEE folks about this and got
one substantive comment, which is below. (The author of that
didn't yet say yes when I asked if it was ok to forward their
email, so I'll post the comment itself and send a link to this
to the author, who can then decide to engage or not.) The
comment was:

"It's possible to do this via EAP, either as a new EAP method
implementing OWE or as an extension to EAP-TLS wherein client certs are
not required and a DH/DHE TLS ciphersuite is used. These approaches are
squarely within IETF's jurisdiction.  Why not go that route?  Indeed
there are a couple extra round trips required in the protocol, but you
don't commit any standardization cardinal sins along the way. "

I don't think any of the above are fatal to proceeding but would
like if Dan and/or Warren can respond to those comments and submit
a revised ID if one is needed. Assuming nothing major ensues as a
result I'll put this draft on an upcoming IESG telechat.

Cheers,
S.

[1] https://www.ietf.org/mail-archive/web/ietf/current/msg100064.html

On 05/12/16 16:48, The IESG wrote:
> 
> The IESG has received a request from an individual submitter to consider
> the following document:
> - 'Opportunistic Wireless Encryption'
>   <draft-harkins-owe-05.txt> as Informational RFC
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2017-01-13. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>    This memo specifies an extension to IEEE Std 802.11 to provide for
>    opportunistic (unauthenticated) encryption to the wireless media.
> 
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-harkins-owe/
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-harkins-owe/ballot/
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 
> 
> 
>

---

From: Daniel Harkins <[email-masked]>
Date: Mon, 16 Jan 2017 17:09:04 +0000

Hi Stephen,

(an outlook update has fubar'd my mail response formatting so sorry for
any confusion that arises below, I'll preface with a [DNH])

On 1/16/17, 8:35 AM, "Stephen Farrell" <[email-masked]> wrote:

    Hi Dan, Warren,

    

[DNH]There are a number of reasons not to do this with EAP. I present
them in no particular order:

  1. EAP sucks :-)
  2. What would the client put in the Identity response? Nothing?
      Typically that is used to decide which EAP method to proffer. While
      it would be possible to define how to proceed, it would be
      arbitrary and seem kind of a hackish (put "anonymous@owe" in
      the response and hope that owe is never used in a RADIUS
      routing message, or put "owe" in the response and hope that
      there are no users in the world whose username is "owe").
  3. The network would show up as "WPA-2 Enterprise" and many
      supplicants will immediately ask for a username/password. We
      want this to show up as "Open" and the client is not bothered
      in order to get opportunistic encryption. Doing EAP might cause
      the user to have to do something and that defeats the whole 
      purpose.
  4. There's a bunch of pointless encapsulations (TLS encapsulation, 
       EAP encapsulation, dot1x encapsulation) and pointless negotiations
       (TLS negotiation, EAP "negotiation") on top of the simple DH that
      OWE is doing. See #1.
  5. This is for small cafes and the like and these people don't know
       EAP from shinola and they certainly don't want to learn just to
       deploy OWE. While lots of the EAP-specific goo can be hidden from
       the admin it does get messy. See #4.
  6. It would require an EAP server on the AP (since we're not going to
       require AAA servers deployed in cafes just to do OWE!) which is
       more code that some low-end APs do not have. See #1.
  7. I do not believe any cardinal sins of standardization are being
      committed with OWE and therefore there is no need to solve the
      problem using a new EAP method. 

[DNH] I don't believe a revised ID is needed based on this comment but
there is a need for a revised ID from the other comments received. Warren
and I will produce a revised ID.

  thanks,

  Dan.
    
    Cheers,
    S.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 16 Jan 2017 21:29:08 +0000

> and I will produce a revised ID.

Sounds fine.

Thanks,
S.