Lamps Status PagesLimited 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
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.