LAMPS Session at IETF 98 30 March 2017 Executive Summary Significant issues about name constraints were raised during IETF Last Call. The Area Director has returned the document to the LAMPS WG to address them. The WG suggests that the rfc822Name constraints apply to both the rfc822Name and the SmtpUTF8Name. This approach requires an update to RFC 5280 that the name constraints apply to the domain or the host name of the email address, but not the mailbox name. 0) Minute Taker, Jabber Scribe, Bluesheets Minute Taker: Sean Leonard Jabber Scribe: Carl Mehner 1) Agenda Bash None. 2) Open issues from IETF Last Call 2a) draft-ietf-lamps-eai-addresses (Alexey and Wei) Wei Chuang presented the latest draft. There was significant discussion of name constraints, and how rfc822Name and SmtpUTF8Name name constraints interact. There are advantages to using name constraints in the CABForum process. Some approaches to name constraints that were discussed: - treat smtpUTF8Name separately from rfc822Name, - treat them together and ensure that they match, - drop LHS matching support since there is very little support for it, - marking the name constraints extension as critical, and - use certain invalid TLDs. Removing the ability to constrain the LHS would allow the rfc822Name constraints to be applied to both fc822Name and SmtpUTF8Name. This approach will be taken to the WG mail list to see is this approach is acceptable to everyone. The WG mail list review should also consider dependencies between software libraries, how different libraries interact, and interoperability with legacy systems. Draft has additional modernizations. Internationalized Domain Names must conform to IDNA2008. Also clarification that email address conforms to RFC 5321 (SMTP) and RFC 5322 (Internet Message Format). It is best prohibit address that contain A-labels that contain two ASCII characters followed by two hyphens (like cc--). And case-folding is only used for ASCII domain labels, but there is no case-folding of the localPart or U-labels. Stefan Santesson: are name constraints used in any real way? Wei Chuang: There is little use today, but they are used. Name constraints are important, especially as email addresses get put into certificates. There is an interest in having these types of name constraints. There are advantages to using name constraints in the CABForum process. If a relying party encounters a certificate extension that it doesn't understand, the certificate fails verification. John Klensin: All of the convolutions are a little scary. The internationalization stuff, doesn’t make it more scary, it’s more scary because of multiplicity of cases. We want high-quality consistency. Viktor Dukhovni: Code for this draft has been submitted to OpenSSL. I looked at the code, and there are bypass issues, so I joined the discussion during Last Call. I am not sure how many applications developers will be involved. The job of the X.509 stack should not be tricky, and it should tell the application whether the email address in the certificate is valid or not. Viktor: Making the name constraints extension critical causes a real concern, especially in intermediate certificates. Its one thing to mark end-entity certificates, but marking an intermediate certificate would make it useless. The original proposal was for the CA to craft functionally equivalent rfc822Name constraints, and avoid critical. Wei: Name constraints are already marked critical already, that’s what I’ve seen. Viktor: No, but not sure. Sean Leonard: How about looking at it pairwise? Applications that do not support smtpUtf8Name, will just ignore it. Applications that support smtpUtf8Name must enforce rfc822Name and smtpUtf8Name constraints on both of the name types. The smtpUtf8Name constraints must be consistent with rfc822Name constraints when the name can be represented in both forms. Richard Barnes: You could require that rfc822Names MATCH smtpUtf8Names that are present. Take the intersection of these strings. Housley: Something like that existed in earlier draft, and Viktor spoke against it. That is what started this discussion. Viktor: There are two use cases: legacy verifier, against SmtpUTF8Name verifier, and CA that is completely agnostic or ignorant, is the WORST case. If I have to constrain the universe that knows about example.com, and then issue a certificate that has a UTF8 local-part. How would the verifier go through that? Barnes: Not sure, but you may be right. Dukhovni: Should be applied somehow. It is too restrictive in other ways. We need ways to create sensible constraints without doing complicated conversions. So, the proposal is to keep the namespaces largely separate, but no opportunity for bypass. If one or the other side is not aware of the new name form, then the verifier is still sure that the right things are happening. Housley: What you are describing is not in the document. Dukhovni: Only one of the cases is problematic. What’s new today is use of critical extensions. I have a different way, both are satisfactory, but which is more practical? Imposing a requirement to mark intermediate certificate critical, because now can ONLY be used to sign things for verifiers that understand that extension. It is a big step for intermediate certificates. I dont know how practical that will be. Santesson: Can rfc822Name constraints apply to both name types? Housley: RFC 5280 talks about three cases. The CA can constrain the domain, the host, or left hand side (LHS) of the at sign. The first two cases can be the same for rfc822Name and SmtpUTF8Name, but not the third case because the rfc822Name constraint cannot carry an UTF8String. Housley: Does anyone use a name constraint with anything on the LHS of email address? If CAs can only constrain the RHS, then the solution can be much simpler and easier. Is there a way to find out answer to that question? Eric Rescorla: Is there a way to specify the RHS, and that’s great, and LHS if only some people want it? Housley: Did we put too much flexibility in RFC 5280? Are we better off taking the ability to constrain the LHS out? Rescorla: If a lot of complexity is about restricting both sides, deal with the RHS now, and deal with the LHS when someone shows up that needs the capability. Sean Turner: There is too much complexity in RFC 5280! Santesson: Is it worth the complexity? Jim Schaad: Perhaps we need something like an AA certificate, where you do a complete match. Housley: That would be need to constrain both the LHS and RHS. But if we want to constrain only the RHS, then any A-Labels that apper in the rfc822Name constraint cane be converted to U-Labels for comparison with the SmtpUTF8Name. Dukhovni: I'm cool with constraining only the RHS, it doesn’t need to do translations because all name constraints are not allowed to carry UTF8. So, we always have to map SmtpUTF8Names to A-Label form. So, they'd have to be normalized to a A-Label. That is already what RFC 5280 says to do. Housley: It was the new requirement to support UTF8 on the LHS that was creating the additional name constraint format. Dukhovni: I've never seen a certificate that includes a constraint for a particular email address. Housley: Is there anyone that thinks we should not reduce complexity by removing the ability to constrain the LHS? NOBODY. Housley: Ok, have way forward. This is a significant update to the draft. This direction need to be confirmed on the mail list. Klensin: Two more things. First, ff somebody is using a library that is dependent on UTR#46, then reversibility and mapping back and forth without loss, between U-Labels and A-Labels is NOT GUARANTEED, and that is a source of potential difficulties and attacks. Second, in the internationalized Domain Name world, there is not an invalid TLD as indicator. Crowd: But .invalid is reserved, and you can use star (*). Housley: We dont have consensus on best way forward yet. The Area Director will return this document to the WG, and this discussion will continue on the mail list. 3) Open issues from WG Last Call 3a) draft-ietf-lamps-rfc5750-bis (Jim) 3b) draft-ietf-lamps-rfc5751-bis (Jim) Last Issue Resolved: SHOULD use AES-GCM, otherwise AES-CBC, otherwise sender's pick. That is already what the document says, so it is ready to go forward to the IESG. The room agreed to move forward with the drafts. 4) Proposals for additional work items [Addressed in reverse order] 4c) OCSP response extension for revocation hint text (Rich) Rich Salz presented the motivation to annotate the OCSP response, such as "revoked by ticket 123123 by rsalz", which can be displayed to OCSP client. It provides a hint about the reason for revocation. OpenSSL says next release would have it, and CABForum will eventually profile it out. Sean Leonard: You may want language tagging on the revoke-hint, since it's human-readable. HUM: Consensus in the room to suggest this for a future LAMPS WG charter. Sean Leonard and Sean Turner volunteered to help Rich Salz work on it. 4b) Updates to CAA for RFC Erratum 4514 (Phil) Phillip Hallam-Baker described the errata that was filed against RFC 6844. The CA/Browser Forum is looking to implement CAA, and the issue was discovered during those their discussions. The CAA record tells which CA can issue certificate for a particular domain. Consider CNAME record: example.com -> example.net Should one follow the CNAME, then look for the CAA record there? Or, should one look in the parents of the record containing the CNAME? The semantics of CNAME turn out to be ambiguous. RFC 6844 maps this name onto this tree, and it was just administrative internal thing; however, CDNs are using it differently, so RFC 6844 is not aligned with the intended semantics at all. The suggestion is to start by going to the pointed to record, then do not look in the parents of that record. Instead, look in the parents of the record that contained the CNAME (.com in the example above), if anyone prefers the first semantics, we need you to say something pretty soon. Eric Nygren: Remember that you cannot put a CNAME and a CAA recors in the same location. Phillip Hallam-Baker: You do a CAA query, and now you get the CNAME. Nygren: But you can't undo it. Hallam-Baker: Right. Nygren: There is an ordering issue. You might want to get a different certificate at different hosting provider. You might want to have the CAA record stored in _caa.www.example.com. Hallam-Baker: Okay. Daniel Kahn Gillmor: Why would you ever want to look up host.example.net? Hallam-Baker: Consider a situation where 500 domain names point to a single corporate site. They just want to administer all of the names as if one logical entity. All the names point to the same place. Just want target record. They use CNAME as original intention; it is a pure alias. John Klensin: This is getting messy. If these people want 500 names pointing to same place, they can get 500 certificates and 500 CAAs and go merrily on their way? Do not make a patch to support bad behavior. Semantics of certificates and DNS likely being different, leads to a recipe for trouble. Jacob Hoffman-Andrews: If you look up CAA with recursive resolver and you get the CAA record, then all is well. However, if you get a CNAME then you need to go back. It would be more of a departure to refuse the policy. Nygren: Looking at the original slide, it is even more messed. There seems to be a bunch of cases that need to get clarified. Maybe an errata would get too long. This really needs a bis document. Nygren: What happens with CNAME pointing to CNAME pointing to CNAME ...? Hallam-Baker: I ran it by DNS experts who said do it by CNAMES. Well it seems that nobody wants the status quo. So errata in short term. And then CA/Browser Forum can say do this next time. Martin Thompson: If you had two CNAME hops on the bottom there, what is the proposal? Hallam-Baker: Continue following CNAME chain, until it resolves. Thompson: So, on the slide, 3 and 4 go away. Only 2, 5, and 6. Hallam-Baker: Yes. HUM: Consensus in the room to suggest this for a future LAMPS WG charter. Nobody immediately volunteered to write or review documents. 4a) Adding SHA3 to PKIX and S/MIME (Sean) Sean Turner presented the topic of adding SHA3 to PKIX and CMS. The document would include the object identifiers and how to use the SHA3 family of one-way hash functions in the protocols. The proposal is that SHA3 be considered the backup in case SHA-256 falls in the future. But, is SHA-384 enough? Russ Housley: We need a backup algorithm implemented and deployed in case SHA-256 falls. Eric said on the mail list that using SHA-384 is the answer. Do we want to do work here to specify the SHA3 family of algorithms for use with PKIX and CMS? Sean Turner: We want algorithm agility. Martin Thompson: SHA-2 for SHA-3. Eric Rescorla: If you want to put the effort in... Phillip Hallam-Baker: If you do curve 448, you have to do the SHAKE that includes the SHA3 sponge function. HUM: Many people in the room to suggest this as a topic for a future LAMPS WG charter; however, a significant number thought it should not be done. Sean Leonard and Jim Schaad volunteered to work on it further. Housley: This one needs more discussion on the mail list. 5) Wrap Up Any other business? NO. Enjoy bits-n-bites tonight. Session closed at 18:40.