* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Xmpp Status Pages

Extensible Messaging and Presence Protocol (Concluded WG)
Art Area: Adam Roach, Alexey Melnikov, Ben Campbell | 2009-May-29 — 2015-Sep-14 
Chairs
 


IETF-84 xmpp minutes

Slides

These are also available from the materials page:
Status and Agenda Bashing
End to End Encryption
Domain Name Assertiongs
Address Format Internationalization
Session 2012-07-31 1520-1650: Georgia A - Audio stream - xmpp chatroom

Minutes

minutes-84-xmpp minute



          Minutes - XMPP IETF 84 - Tuesday 31 July 2012 - Vancouver, CA
          
          Summary:
          
          Meeting materials available at
          http://www.ietf.org/proceedings/84/xmpp.html
          
          -- End to End Encryption
          
          Matt Miller presented draft-miller-xmpp-e2e-02. The sense of the room
          was that this draft is on the right track. There are some minor issues
          with JOSE concerning key wrapping and base64url that Richard et al will
          take to the JOSE meeting.
          
          -- Federation/Domain Name Assertions
          
          Matt Miller presented on draft-saintandre-xmpp-dna-00,
          draft-miller-xmpp-posh-prooftype-01,
          draft-miller-xmpp-dnssec-prooftype-02. The drafts were well received in
          general. The next steps are to get more feedback from the broader XMPP
          community (including the XSF), get feedback on POSH and DANE from security
          and apps areas, and encourage experimentation by implementors. The drafts
          may need more precision for implementors to experiment.
          
          -- Internationalized Addresses
          
          Peter St. Andre presented the current status of
          draft-ietf-xmpp-6122bis-02. This draft is still mostly waiting on the
          PRECIS framework. The group discussed the use of confusable tables vs
          limiting names to match local scripts.
          
          ---------------------------
          
          Raw Notes from Mary Barnes:
          
          IETF-84 MEETING NOTES
          
          XMPP (IETF 8 - Vancouver, CA) - Tuesday 31
          July 2012 1520-1650
          -- Status and Agenda Bashing -- 10 min (Chairs)
          
          SIP-XMPP mapping:
          --          draft-saintandre­‐sip­‐xmpp­‐*
            (expired)
          --          First four docs close to done.  WG should
          continue reviewing and figure out what to do?   --- DISPATCH, XMPP,
          AD sponsored
          End to End Encryption (Matt Miller) -- 15 min
          
          http://tools.ietf.org/html/draft-miller-xmpp-e2e-02
               (Note:
          Draft may also be discussed in JOSE)
          To do:
          --          Signing
          --
          Notes about sender offline
          --          Optimizations with  ?
          Richard:
          thinks this I son the right track.  Use of JOSE is kind of a hack, but
          that's because JOSE wasn't designed for this usage.
          Matt: issue is
          around key request
          Richard: because JOSE doesn't define wrapped keys
          as a first class, thus you have to treat key as content .  Doc does
          a good job about what needs to be changed with Jose.
          Joe: need to
          follow up with Jose – make sure they understand
          Richard and Matt
          will do that tomorrow in Jose session.
          Jabber room (florenz?) –
          don't know much about Jose – base 64 URL is different…
          Matt:
          could find a way about that one.  As far as JSON since trying to use
          encrypting and signing.
          Joe (on the floor): agree
          Richard: It's in the
          Jose charter to use JSON
          
          Domain Name Assertions (Matt Miller) – 45
          min
          
               http://tools.ietf.org/html/draft-saintandre-xmpp-dna-00
               http://tools.ietf.org/html/draft-miller-xmpp-posh-prooftype-01
               http://tools.ietf.org/html/draft-miller-xmpp-dnssec-prooftype-02
          (Note: *-dnssec-prooftype-02 may also be discussed in DANE)
          Federated
          identity delegation thing.  Two problems:
          1)  Secure delegation
          2)
          Identity verification
          Today delegation done by DNSSRV.
          DNSSEC Helps
          -
          Joe:  WG should consider which names in DNS are valid in PKIX world?
          -
          
          Identify verification :
          -     What is verification materials?
          (certificate, token.._
          -     What are the matching rules? (RFC 6125?)
          -
          Where do you get material?  (PKI, DNS. …)
          -     Do you need secure DNS
          to trust this material?
          -
          Prooftypes:
          -     the entity asserting
          its identify needs to prove the association using a recognized…
          PKI prooftype
          -     verification material: PKIX cert
          -     matching
          rules: 6125
          -     Source: PKI/trusted roots
          -     Secure DNS: nice
          but not necessary
          -
          Wes: it helps a lot more if you're expecting
          it to help with validation of cert.  The other part of DANE locks you
          into the CA you wanted.
          Matt: it's what we have today.
          Dialback
          Prooftype
          -     verification material: token
          -     matching rules:
          depends on implementation, but typically byte by byet
          -     source:
          sent over XMPP itself
          -     Secure DNS: needed in order to really
          trust the information
          Joe: do you think we would have a policy in the
          future to say don't do Dialback?
          Matt:  It is a trustworthy model.
          DANE Prooftype:
          -     verification: PKIX cert
          -     Matching rules:
          SubjectPublicKey Info or hash
          -     Source: DNS
          -     Secure DNS
          POSH  Prooftype:
          -     verification: PKIX
          -     matching rules: 6125
          -     source; https
          -     secure DNS: nice but not necessary
          Joe: do
          you think there will be a way to indicate POSH with bit in cert?
          Matt:
          want to make this immediately deployable – adding a new bit wouldn't
          allow that.
          Joe: maybe carry over XMPP . Concern is checking URL when
          only one server might support.
          Matt: there are optimizations.  But, this
          doesn't require  a ton of code. Operators understand how to put a file
          on their servers
          Wes: Did you consider case where there is no server
          running and FW in place and you never get TCP response?
          Matt: that's
          been mentioned.  It depends upon whether we want to do the signaling.
          Not important for 3 or 4 – maybe so for 25.   Don't know how long
          lived connections will be.  Not so concerned about long time outs.
          Wes:
          the client is waiting.
          Matt: could be doing a DANE connection.  Most SSL
          libraries let you hold off.
          Wes: happy eyeballs
          Standalone servers:
          -
          Use PKI as you do now
          -     USE DANE with secure DNS
          -     Use dialback
          keys, preferably with secure DNS
          -     POSH not needed, but OK
          Virtual
          hosts:
          -     PKI is not a realistic option, so….
          -     Use DANE with
          secure DNS (preferred in long term)
          -     USE POSH (not as elegant as
          DANE but immediately deployable)
          -     Use dialback keys (preferably with
          secure DNS)
          Next steps:
          -     XMPP community (WG+XSF)  feedback pn DNA
          framework
          -     Get feedback on DANE and POSH from security and APPs
          -
          Experiment with implementations
          Wes: if you are going to go down these
          steps, you need somewhere a framework document indicating what you are
          going to prefer.  OTW, you could get one to validate and another not.
          Matt: Yes - They validate differently.  Do have a framework draft.
          Peter
          SA: would prefer DANE
          Chairs:
          -     like idea to experiment with
          implementations
          Richard: likes to experiment with implementations but
          don't think it can be done with current doc – need more precision
          Joe:
          within XMPP community (WG + XSF), we need to get them to hear this.
          
          Address Format Internationalization (Peter St. Andre) --  10 min
          
          http://tools.ietf.org/html/draft-ietf-xmpp-6122bis-02
          Remaining work:
          -     1) Processing order: perform normalization first
          -     2) Map
          full-width and half-width code points to their decomposition mappings?
          -
          3) Error handling: add a sentence about using  (might go in 6120bis)
          4)     Wait for PRECIS framework to be done
          1 & 2 are remaining open
          issues.  Will wait for WG feedback on 3.   Discussions tomorrow on 4.
          
          Discussion:
          Peter: issue with registration of names that look like
          others.
          Joe: may want to consider here or PRECIS if you wanted to
          use new .Don't register two names with confusable mappings.
          Peter:
          this is outside scope of what we do -  have to say you can't run
          script through JID.
          Joe: can't use codepoints in confusable table.
          Before you allow reg of a name in your domain, run the confusable
          mapping and do a check.
          Peter: like that approach
          Matt J:  is the
          problem mixing of scripts?
          Joe: that's one of the possible things.
          Think the algorithm is not easy to describe.
          Matt M:  the idea of
          the confusable table – the more I think about it, it makes sense.
          If something can get confused, that's probably the right way to go.
          Joe:
          would add another column to table with JIDs – that would be unique
          Ben:
          agree.
          Peter: think will allow certain characters depending upon domain.
          Likely won't allow codepoints that its script is not familiar with.
          Joe:
          don't concede the point yet.   Run server with people from multiple
          countries.  Has multinational companies on server
          Matt M: don't think this
          should be formally codified – maybe provide guidelines
          Bernard: agree.
          Have done this with multiple countries./scripts.   Concentrate on things
          that cause real security problems.
          Peter: this seems to be an SP policy
          decision.
          Joe: the confusables check would have gotten that.
          Peter:
          don't think mixed script is that hard.  But, confusables seems to be a
          good way to do it.
          Matt: this needs to be dealt with by servers as much
          as possible.  Clients should not  be enforcing this .
          Joe: not sure how
          to tell if given string of codepoints is all from one script.
          Matt:
          with current rules, have no way to do normalization.
          Jonathan lennox :
          the whole case normalization problem – it's still unclear how a server
          can enforae all lower case.   It's easy for a cooperative client to follow
          rules, but hard for server to enforce because it depends on the locale.
          Joe: take that to PRECIS
          -- AoB and Open Discussion -- Any remaining
          time and energy
          
          
          -------------------------------
          
          Raw Notes from Wes Hardaker
          
                        XMPP IETF Meeting Minutes -- 2012/07/31
                        =======================================
          
          Date: 2012-07-31 Tue
          
          Table of Contents
          =================
          1 draft status
             1.1 sip-xmpp mapping
          2 end-to-end encryption -- XMPP E2E -- Matt Miller
             2.1 comments/discussion:
          3 Domain Name Assertions -- Matt Miller
             3.1 Comments:
          4 Address format internationalization -- Peter Saint-Andre
             4.1 Comments
          
          1 draft status
          ===============
          
          1.1 sip-xmpp mapping
          ---------------------
             + first four near done, just need final review
          
          2 end-to-end encryption -- XMPP E2E -- Matt Miller
          ===================================================
           + changes from -00 listed
           + key wrapping
             + have 2 keys;
               1. for messaging content and
               2. one to encrypt the messaging key
             + hopefully addresses some concerns
             + The content message key (CMK) is sent encrypted using the session
               master key (SMK)
           + todo
             + signing
             + sending offline
             + optimizations with
          
          2.1 comments/discussion:
          -------------------------
             + Richard Barns: feels like a hack in parts
               + Matt: biggest hack is near key wrapping
               + Richard: because JOSE doesn't define wrapping keys, you have to
                 treat the keys as content which is the problem.  This document
                 declares what needs to change in JOSE.
               + Joe Hildebrand: JOSE needs to understand that so please bring it
                 up in the JOSE meeting tomorrow.
             + Florin: do we have any chance getting around base64 URL which is
               different than base64 everywhere else, including JSON
               + Matt: we could certainly get around base64, but we can't get
                 around JSON
               + Joe: we can't get around json because it's in the charter, and
                 JOSE was charted to do this work for us.
          
          3 Domain Name Assertions -- Matt Miller
          ========================================
           + problems:
             1. how do I get to the right server?
             2. how do I check the credential of the server?
           + delegation
             + we use SRV records
             + but host names can be different in the SRV record from the
               hosted server name
             + DNSSEC can help assure us that everything is correct
             + useful for very large server farms (eg, gmail)
           + identify verification
           + prooftypes and 4 options
             + PKI: certificate and the name must match
             + DNSSEC is nice but not necessary
               + Wes Hardaker: DNSSEC may be needed to validate or to check
                 that you're using the right CA
               + Matt: yes, but I'm listing this as what we have today not what
                 might be good in the future
             + Dialback
               + verification material is a token
               + ideally needs dnssec
               + Comment from Joe:
                 + would we recommend policy at some point?  IE, don't do
                   dialback if DNSSEC is available
             + DANE (DNSSEC prooftype)
               + verification is a hash of the public key info
               + dnssec is necessary
             + POSH
               + verification material: PKIX
               + passes the material over HTTPS
               + Joe: are we going to need an extra pkix extension to indicate
                 that you can check POSH?  Otherwise how are they going to know
                 when to check or not, or check everybody?
                 + matt: the point is to make this as immediately deployable,
                   so an extension isn't quick
                 + Joe: I don't want to waste the network connections, etc,
                   when I don't need it.
                 + Matt: we could optimize, but we don't need a ton of code and
                   ops can already place files somewhere.  It's straight forward.
               + Wes:
                 + what about TCP SYN drops to servers that aren't running
                   https and thus the connection establishment is slow.
                 + matt: That's been mentioned, but I'm not concerned about the
                   delay.
             + stand alone servers
               + use PKI as now, dane as needed, posh, and then dialback
             + next steps
               + need feedback
          
          3.1 Comments:
          --------------
             + Wes Hardaker: you need a document somewhere that specifies which
               options to prefer, etc.
               + Matt: there is a framework document that the decision making
                 discussion could go into.
               + Peter/Jabber: I think we'd prefer DANE
             + Richard Barns: I like the idea of implementing it, but I don't
               think the current documents quite give me enough details to
               implement yet.
          
          4 Address format internationalization -- Peter Saint-Andre
          ===========================================================
           + -01 changes
             + I think people are on board with doing NFC, but I need to know if
               that's not the case
             + based on list discussion, changed SHOULD to MUST for A -> U labels
             + based on list discussion, enforcement rules specified
           + remaining work
             + not much remaining except for PRECIS framework that needs to be
               finished.
             + PRECIS is different in terms of IDNA processing order
             + the PRECIS work really needs to get done
          
          4.1 Comments
          -------------
             + Joe: we're happy you're doing the IDN work and I think people
               appreciate it.
               + Peter: we might want to define a policy for a service to disallow
                 unicode characters that match ascii ones and are too similar
               + Joe: we might want to put something in a document to describe
                 what to do in cases.
               + Peter: the sledge hammer approach of deny everything is easier
                 than using a "confusable table"
               + Joe: what I mean is use the confusable mapping to check if
                 something exists and is similar or not.  I'm not sure the
                 algorithm is easy to describe though
               + Matt: the idea of the confusable table first bothered me, but
                 it makes more sense now.
               + ben: I agree on this, ascii only would be easier but if
                 everyone did that then all this work is for not
               + joe: I run servers than have multiple cultures and enforcing
                 policies is problematic
               + matt: I don't think this is good to formally codify, but it's
                 good as operational notes.
               + ...
               + matt: it's a policy issue the client should never enforce
               + joe: I don't know how to make these code points all be the
                 same for all of it.
               + matt: for the current rules I don't have the ability to do
                 this today
               + johnathan: the whole case normalization problem is hard for a
                 server to enforce things like "all lower case".  It's easy for
                 a cooperative client to follow the rules, but it's very hard
                 for the server to enforce.
                 + that's a PRECIS problem.
          
          



Generated from PyHt script /wg/xmpp/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -