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

Lamps Status Pages

Limited Additional Mechanisms for PKIX and SMIME (Active WG)
Sec Area: Eric Rescorla, Kathleen Moriarty | 2016-Jul-01 —  
Chairs
 


IETF-99 lamps minutes

Session 2017-07-17 1740-1840: Karlin I/II - Audio stream - lamps chatroom

Minutes

minutes-99-lamps-00 minutes



          LAMPS Session at IETF 99
          17 July 2017
          
          Executive Summary
          
          All of the deliverables in the current charter are with the IESG.  Three
          potential work items have been suggested for a re-charter.  There was a
          lot of interest in re-chartering to work on rfc6844bis and the addition
          of the SHAKE128/256 and SHAKE256/512 algorithms for PKIX and S/MIME.
          There was almost no interest in including the specification of a
          first-issued certificate extension in the re-charter.
          
          
          0)  Minute Taker, Jabber Scribe, Bluesheets
          
          Yoav Nir will take notes.
          Jim Schaad is Jabber Scribe.
          
          
          1)  Agenda Bash
          
          No agenda changes.
          
          
          2)  Any issues from documents that have been sent to the IESG
              a)  draft-ietf-lamps-rfc5280-i18n-update
              b)  draft-ietf-lamps-eai-addresses
              c)  draft-ietf-lamps-rfc5750-bis
              d)  draft-ietf-lamps-rfc5751-bis
          
          No comments have been received on any of these documents.
          
          
          3)  Proposals for additional work items
          
          All of the deliverables in the current charter are with the IESG.  Three
          potential work items have been suggested for a re-charter.
          
          
          3a)  rfc6844bis
          
          Phillip Hallam-Baker suggests that the re-charter include a work item to
          update PKIX CAA document.  The CA/Browser Forum will require mandatory
          CAA validation starting 8-Sep-2017.  The original intent of the CNAME
          and DNAME resource records in the DNS is obsolete because of CDNs.  They
          want to administer various CNAMEs as one unit, but CNAME cannot be used
          to distinguish between the two needed use cases.  A prefixed SRV record
          seems like a better approach.  An update to RFC 6844 is needed to
          address this situation.
          
          Proposed charter text: "Specify a discovery mechanism for CAA records to
          replace the one described in RFC 6844".
          
          Sean Turner: Yes, let's do it.
          
          HUM to include rfc6844bis in the proposed re-charter.  Many for yes;
          silence for no.
          
          Phillip Hallam-Baker volunteered to be editor.
          
          
          3b)  Adding SHA3 to PKIX and S/MIME
          
          Quynh Dang (NIST) suggested that the SHAKE128/256 and SHAKE256/512
          algorithms be specified for use with PKIX and S/MIME as a backup to
          SHA-256.  There are no know concerns with SHA-256, but it is prudent
          to have an alternative available.  The SHAKE algorithms offer better
          performance than other members of the SHA3 algorithm family.
          
          Jim Schaad: How exhaustive of a signature algorithm list are you
          proposing?
          
          Quynh: They are efficient functions.
          
          Russ Housley: Which set of signature algorithms would you like to use
          with the SHAKE functions?
          
          Quynh: They're good for them all.
          
          Quynh: Don't need the HMAC construction for use with the KECCAK.
          
          Jim: The problem is education. People don't know that you can use SHAKE
          without HMAC.  Implementations would need to be changed to not do HMAC
          for AuthenticatedData.  Everyone is used to using HMAC in this context.
          
          Sean Turner: I don't know we need to pick the actual curves for ECC
          signature algorithms right now.  We thought about RSA-PSS and ECDSA,
          but we do not need to pick now.
          
          Eric Rescorla: Why? Isn't the SHA2 family good enough?
          
          Quynh: Just in case we find a problem with SHA2.
          
          Eric: We've been trending away from defining points without a clear
          advantage.
          
          Quynh: They are very secure.
          
          Eric: SHA2 has a wide margin.
          
          Quynh: SHA3 has an even greater margin.
          
          Eric: It's just another algorithm.
          
          Phillip Hallam-Baker: We need two algorithms for each primitive: One to
          use, another as a spare.  And make them rather different.
          
          Sean Leonard (Jabber): Aren't algorithm agility and cryptographic
          diversity sufficient reasons in and of themselves? Also, software
          testing of modularity and interoperability is important.
          
          Jim: There is a reason to do the AuthenticatedData stuff with SHAKE.
          Since it is one-pass it is going to be faster.
          
          Eric: Where do you use MACs that is not replaced by AEAD?
          
          Russ: There are a few places where confidentiality is not needed.
          
          Bron Gondwana: Having a spare algorithm that is not routinely used is
          not enough.
          
          Phillip: Ed448 already includes SHA3. So, this would not really be
          adding code. Just adding code points.
          
          Quynh: If you have a code point, some people will use it.
          
          Eric: We have code points for SHA-512, but almost nobody uses SHA-512.
          
          Bron: Some implementations will support it wrong, but nobody will
          notice until you have to use it. It needs to be used all of the time
          to know that it works.
          
          Max Pala: I think the agility argument is sufficient.
          
          HUM to include the SHAKE functions in the proposed re-charter.
          Many for yes; silence for no.
          
          
          3c)  An first-issued certificate extension (Phillip)
          
          Phillip Hallam-Baker suggests that we specify a first-issued certificate
          extension. This is not a new idea; it was previously presented in
          Chicago, July 2007. The age of certificate is useful, because an old
          certificate is evidence of longevity.  It is like "Member since" on a
          credit card. And now, short-lived certificates are coming back (see the
          ACME session this Friday).  It offers user accessible safety information,
          like "established 1977". Some people object to this extension, saying that
          they do not want to deploy it.  Other say that PKIX doesn't work. Others
          say the information is available in Certificate Transparency logs.
          However, Phillip says that the CT logs do not offer the information in a
          way that users can understand it. It requires more processing.
          
          Robin Wilton: From the user perspective: you get a warning about a recent
          certificate. Is this going to happen a lot?
          
          Phillip: Security UI is garbage.
          
          Robin: So how can we avoid the bad stuff. Most users would not see it
          at all.
          
          Paul Hoffman: First Issued by whom?  Same CA? Another trusted CA?
          
          Phillip: There are ways of doing it. Sign the new CSR with the old key.
          
          Eric: Which relying parties will use this information?
          
          Phillip: Not in primary chrome, but while looking at the certificate by
          clicking the padlock.
          
          Eric: Which relying parties are interested?
          
          Phillip: We want to tell people how to be safe online, but we don't have
          a way to tell them how.  This is one piece of information might help.
          
          Rich Salz: Useful in email.
          
          Sean Turner: Last time we said it was lock-in to one CA.
          
          Jeff Hodges: Don't understand how to link them. I can get owned at any
          time.
          
          Phillip: Bad sites are usually short-lived.
          
          Stefan Santesson: It's targeting the wrong end of the problem. The
          CA/Browser Forum should need to define it on the policy side. The
          extension is the easy part.
          
          Phillip: In ACME we're defining the validation criteria.
          
          Sean Leonard (Jabber): Is this actionable by an end-user?
          
          Paul: I don't want to build the chain and sign new certificate signing
          request (CSR) with production key. Let CAs do it. One CA could lie.
          
          Yoav Nir: Don't think it's a good signal to make decisions.
          
          Eric: Doesn't seem like it's useful on the web.
          
          Bron: Banks would send an email to all customers that the name/date is
          going to change. An attacker would do the same.
          
          Phillip: It can help users determine whether this is the good or bad
          part of the Internet.
          
          Rich Salz: You can't define (algorithmically) good vs bad areas on the
          Internet. How long you've been paying a CA is not a good indicator. Yet,
          it may be useful for email.
          
          HUM to include the first-issued extension in the proposed re-charter.
          Silence for yes; many for no.
          
          



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