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

[Daniel Harkins <[e-mail]>]

  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" <[e-mail]> wrote:

    
    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. "

[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. 

    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.

[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.
    
    [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
    > [e-mail] mailing lists by 2017-01-13. Exceptionally, comments may be
    > sent to [e-mail] 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.
    > 
    > 
    > 
    > 
    >