PRECIS WG - IETF 87 ======================================== 0) Administrivia ---------------------------------------- PARTICIPANT KEY: * AS - Andrew Sullivan * DN - Dave Noveck * JH - Joe Hildebrand * MB - Marc Blanchet * PSA - Peter Saint-Andre * YY - Yoshiro Yoneya * YO - Yutaka Oiwa 1) WG Deliverables ---------------------------------------- problem statement now RFC draft-ietf-precis-* ready for WGLC? 2) WG Status ---------------------------------------- Agenda: 2. Document updates / Discussion 2.1 WG I-Ds (1) Framework https://datatracker.ietf.org/doc/draft-ietf-precis-framework/ (2) Preparation and Comparison of Nicknames https://datatracker.ietf.org/doc/draft-ietf-precis-nickname/ (3) Mapping characters for precis classes http://datatracker.ietf.org/doc/draft-ietf-precis-mappings/ (4) Preparation and Comparison of Internationalized Strings Representing Simple User Names and Passwords http://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis/ 2.2 Individual Documents (1) HTTPAuthPrep: PRECIS profile for HTTP Authentication https://datatracker.ietf.org/doc/draft-oiwa-precis-httpauthprep/ 3. Next steps 2.1) Framework ---------------------------------------- Peter Saint-Andre working on Python tool to process/analyze unicode tables together with the precis framework to compare results with a modified version of a modified version of the idna createtables script to handle precis framework.. This lead to a few additional recommendations to the framework, such as modifying of processing order in the framework algorithm. PrecisMaker needs comparison to createtables.rb, once more features are in place: - wants to adjust output to be consistent with createtables.rb - compare stringprep + UNICODE 3.2 vs PRECIS + UNICODE 6.2 Helps to determine the impact the framework changes have over the previous stringprep * MB - I compared a client id inPRECIS + Unicode 3.2 (and up), versus stringprep. I'm not sure this testing will help move the framework forward. * Andrew Sullivan (AS) - I looked at this draft, but did not compare this against IDNA. Are there now differences in the order now? * PSA - There are some properties we have that IDNA doesn't. But I need check IDNA, but we were doing some things wrong. I think the order is the same, but we slotted in more things. * MB - We started with IDNA, but slotted in new stuff. * PSA - And slotted it in the wrong order. * PSA - I think the comparison is of interest to applications people. It can provide some practical guidance to implementers (e.g., help find gotchas in the migration). * MB - I think this can be good input for the guidance document. * Yoneya - Peter, do you think we need to wait for the table comparisons for WGLC, or can we do it in parallel? * PSA - The comparative testing can be done by the end of the month, so I think we should wait until then before moving forward. * MB - We're in August, and people take vactions around now. I'm thinking we should have WGLC in a few weeks. Anyone else implement this? (no hands). It would be good to have multiple implementations, but I think we can issue WGLC, because it's about finding issues. * PSA - Personally, I think things we find will be bugs in my Python. Having this code I think helps us finds issues, and the work left is more about presentation. * MB - So I think we should issue WGLC in about three weeks or so? 2.2) Nicknames ---------------------------------------- Completed WGLC, and no signficant issues found. Now waiting on writeup and will move onto IETF LC. * PSA - We completed last call last year, then kind of forgot about it. I did a couple of edits, but I think we can go for IETF LC, and it can wait in the editor's queue until the framework is ready. * Pete Resnick (PR) - If you make the normative reference, the RFC editor won't publish until the framework is ready. The question is if IESG review will wait until the framework is ready? I think the two should be reviewed in lock-step, but I can do the AD review now, and put them into a wait-state in my queue until the framework is ready. If you want to do the writeup now and wait on me, that's fine. 2.3) Mappings ---------------------------------------- Updated based on feedback, with new issue on local case mapping. Authors think it is ready for WGLC. * PSA - The framework document simply says that there might be additional mappings, and to look at this document for details. I think keeping them in this document is the right call. * PR - I think the silence means we should put it out for WGLC. I would recommend the chairs find additional reviewers outside the normal groups. * YY - Is there any objection moving to WGLC? (none in room) * YY - Do you think the timing is in parallel with framework, or can it go sooner? * MB - There are open issues, so I don't think we can go to WGLC now. * AS - It sounds like this issue is now closed with the proposal. * MB - But we need a revision still (-: 2.4) SASLPrep ---------------------------------------- case mapping from MUST to MAY. case mapping will be defined in the customer spec of saslprep. There are several layers here: * PRECIS * SASL * Application Want to make sure things are done in the right place. * AS - I haven't sent this to the list, but I am wondering if this is what SHOULD is all about. It seems to me that many of the arguments made will actually get them in trouble. I think this MAY will do damage to other protocols. * PSA - I tend to agree, but I need to look at the specific text in there. We don't want to give people "foot guns"! (-: * PR - Did Nico give any concrete examples, or was it a theoretical exercise? * PSA - I did not get any concrete examples. He was suggested this was done at the wrong layer. * PR - I agree with Andrew. We see exceptions, but this can get people into a lot of trouble. Given that Nico has a theoretical case before we change things. * PSA - Do you have any examples in mind? but further interrogation is useful. * AS - I get the layering argument, but I'm not sure this is right. I'll send something. Handling non-SASL applications? * Joe Hildebrand (JH) - Do we have text to say "This can be applied to non-SASL protocols"? * PSA - Not today * JH - Then I think we should add that. * MB - Do you think we should change this document's name? * JH - Since this is a -bis, I think it's fine to keep the current name, but we can update the abstract, intro, etc. * PSA - We're updating 4103, which happened to use the name saslprep, but it talks about internationalizing usernames and passwords. There's nothing in the title that is specific to SASL. I agree that we can say something that this can apply to things other than SASL. * PSA - And I think we should ask about this SHOULD on case mapping. We don't want people to have more "foot guns". * MB - What do you think is the status of this draft? * PSA - We've continued to approach the kitten WG, and have gotten feedback. We need to do some further generalization, but we haven't heard from many others yet. * YO - I'm a little confused about how to organize things. It has some general rules, and has some SASL-specific pieces. There are things this draft does not cover. Sharing things is good, but having a stack can be confusing. * PSA - We've tried to come up with layers that apply generally, then parts that guide other protocols. I think we need to get recommendations from http-auth. As I understand, you are working on updated versions of DIGEST and BASIC. And we need to be sure you're using this correctly, but that we account for your needs. * YO - In http-auth, we basically punted. * PSA - It seems to me if the experts here need to talk to the http-auth and understand what they're doing and provide recommendations on internationalization. I'm happy to look at the base specs. * YO - The current status is "just use UTF-8" and nothing more. They don't talk about normalization. * PR - Nico went through that document for review, but it's not clear that they know what they actually need so they can do a good review. The case mapping thing probably demonstrates the lack of understanding on internationalization. I wonder if we should frame some questions for them to answer first to try and get them in the right mindeset. * PSA - I've seen this in other places, and internationalization is kind of seen as special pixie dust to sprinkle on their protocols. * JH - The security directorate does this question list for when people come asking for the security dust. * DN - There are not just application protocols that need this special i18n dust. * PR - We need to understand where the concerns are -- is it dependent upon where the input comes from. does it come from users? * DN - The problem depends on where the inputs come from, which might be from other protocols or systems. And how do we deal with that? * PSA - I think we need to put together the questions for other application protocols, but I'm not sure it's in scope for us to do that everywhere. As a community, we have some folks that know what some of these questions are, and we need to capture them. Maybe it goes into these documents, or maybe it goes into something else. * PR - There's the set of questions for protocol designers, but there's also questions we need to have for our reviewers. We need to make sure we ask them that we understand how the other protocols work, that we are doing things correctly here. In the review case, we have to ask a pretty precise set of questions based on where this fits in their stacks. * JH - In the cases where we are handing this off to other protocols, we need to ask the same set of questions. We are asserting that, for the things we did ahead of time, then here is how to do things. * PSA - I think it would be helpful in these specs to provide some examples to describe our worldview. I will try to formulate something along those lines. * PSA - There was a spotify blog post recently. They were using a library that did stringprep (the XMPP stuff); they pointed to a pre-WG version of work (probably because it was the first result from Google search). They used it in a manner that allowed attackers to take complete control of other users. * PSA - Things like this are good reasons we need to have more user- or developer-friendly text to help people understand how important this is, and what you are getting from this profile. * MB - Is that exactly the goal of the guidelines document? * PSA - There are a couple of guidelines. Guidlines for those looking for how to apply i18n to their applications, as opposed to how to design new profiles. * MB - My take is that 75-90% of the text would apply to all of the problems. * AS - I have to agree with Peter. Even if it's cut-n-paste text, it's based on what people are going to skim to get to what they want. * PSA - A lot of what we've done has been to prevent people from hurting themselves. If we need to cut-n-paste some text, I think that's more important than centralizing all the text. * AS - I think you're right, and if we go back to the BoF discussion, people want some magic box that helps them fix the problem. * PSA - I think we need to be careful, and try to provide something that people aren't going to hurt themselves, but I also want to get the work done. * MB - So it looks like we need a new rev of this document, with the suggestions plus the new guidelines. * PSA - We need to make sure we are meeting the needs of the existing consumers, and we probably need to update all of our drafts to include this helpful text. * AS (off-mic) - I think have text that we can include. * YY - The next steps are to update for the known applications? !!! ACTION !!! - We need to incorporate some of this feedback. !!! ACTION !!! - We need to add text that this applies to other non-SASL applications. !!! ACTION !!! - We need to interrogate Nico et al more, and see if the current MUST is really a SHOULD (not a MAY). 2.5 HTTPauthprep ---------------------------------------- Document on how to apply PRECIS to http authentication schemes. * PSA - One thing we found in XMPP, the previous specification we were not clear on who enforces the rules. We fixed that some in RFC6122(bis) to say what the role of the server vs. the role of the client. I'll keep that in mind when I review your document. What rules are aplied where. * PSA - One of the comments I made on a list is that httpauthprep shouldn't be its own document, but rather I prefer that we have something that references the more general saslprepbis (which is probably mis-named). Processing rules for httpauth * PSA - We can't ask users to provide UTF-8. UTF-8 is a computer encoding, and not a user encoding. * YO - This meens, for example, if the user enters something UTF-8 encoded into a configuration file, it's ok. The intent is for command-line clients to do nothing. * MB - So senders SHOULD send prepared strings, and simple clients are senders. So what is simple? We are introducing an exception that people will over-use. * YO - I couldn't write text for this, but if input is text, then it must be prepared. But if that something comes from the registry, the client might send just the binary. * John Lennox (JL) - It sounds like you want the sender to send prepared strings, but not *where* that prepared string is coming from. If it's from the software preparing human input, then it's ok. If it's from a config file, then it needs to be prepared in the config file. * MB - If the software is preparing the configuration, then software is preparing the string. You're not specifying where the preparation is done, but whatever you are sending is always prepared. * AS - I don't want to put words in Marc's mouth, but this is in a layer that the IETF isn't any good at (user interface). I think you can say that the string needs to be prepared, but where it's done is left to the application to determine. * AS - I think the point here is, if it's part of the protocol, it needs to be prepared somewhere. For an analogy, look at how IDNA handles the mapping. Try to draw the line consistently, and you can avoid this exception case. * JL - I think you can have something informative that says you don't have to worry about it if you can have something else handle it for you. * JH - I don't think it's adequate for us to do what IDNA did, and say that it's up to the user interface. I think we should try to provide some guidance, such as looking at the locale. I'm especially concerned about the Web Community. * AS - I wasn't suggesting we should do what IDNA did, but that it does provide an idea of where to draw the line. We need to be very careful of where the line is between what's in the protocol and what applications do with it. Next Steps * MB - It would be better if all this text were in the base HTTP specs. That would be part of HTTPbis, and these topics would be clearly defined there. * YO - The problem is that the current documents are "done", and do not include even these base authentication schemes. I think that would be ideal, but it is too late to do. * PSA - I think that train as left the station. * PSA - I will review your document in more detail -- this rule to process on the client only is because the server will break authentication cryptography etc. And Nico made this argument as well, but it's not clear to me why the client MUST do it. * YO - In non-BASIC schemes, the server cannot do anything withe input. * MB - Are we touching the stored thing? Meaning, that which is the stored credentials in the server database, the server should be compared. The client MUST do the preparing before, but the server preparing can have different results. There is some wording that the server storage SHOULD be prepared, or we run into trouble. * PR - If the server takes the password, before it hashes, it MUST prepare. This is usually outside of the HTTP protocol. Since the server is receiving a HASH from the client, the client MUST prepare. * YO - In the BASIC scheme, the server could prepare it, but others it cannot. * MB - In gneralization, we say that, the string MUST be prepared before you apply any crypto. * JH - The reason this is different from XMPP is that this is authentication information, whereas in XMPP it is addressing information. * PSA - That is a helpful distinction, and would be useful to capture in our questions: "Are you using it for authentication, or is it also used for addressing." * JH - It would also help to know some other things. If it's authentication, then it needs to be prepared ahead of time. But if it's full-text search, we might want to store both the "raw" and prepared versions. * PSA - Right now this is an individual submission. Will this become a WG item for PRECIS, HTTP-AUTH, etc? * YO - I think it depends on how we document it. We must correlate with others. But I think this document is better here, because we have the expertise for i18n and for HTTP authentication. Ultimately it is up to the chairs, but I think PRECIS is a good place for at least discussion. * PR - (with AD hat) If I want to be technical about it, we may do replacements of old protocols. It doesn't say we can add new profiles. I certainly have no objections discussing this document here, but should we take it as a chartered item? I'm a little worried that over the long term that once we get framework and other base documents out, that we are probably need a PRECIS directorate because people will keep coming to us. As a working group, that is more difficult. As we complete the base document, we should start to think about this as a directorate where we can review the drafts. For now, let's leave it as an individual draft for now, and I'll bring it up with the IAB about what the transition steps are. If this were a year from now, we would probably say that you would work with the PRECIS directorate. * MB - My take is that it might be good for the community to have enough exercises of the framework before we go into darkness mode -- so it might be too preliminary to go into that mode. * PSA - We all know we need to make that transition someday, but where that happens we're not sure just yet -- we still have the questions to figure out. I think it's a good thing to raise with other IESG folk, but I'm not sure we're at the transition yet. * PR - What I'm trying to get my head around if this will be a long-lived WG instead of a directorate. WG are usually "we have a protocol, we form and build the protocol, and then we're done." But this might look more like DISPATCH -- no matter what we do, it's going to special. We'll continue to work with others regardless of whether this stays a WG or not. I'll talk to the IESG/IAB to see if there's a formula we follow, or if this is special pixie dust. * PSA - I think we need to come up with a support group instead of a working group or a directorate. * JH - I think that's an interesting idea that has logistical issues.