MONDAY, November 14, 2011 - 0900-1130 Morning Session I 101C DNS-based Authentication of Named Entities WG Administrivia (Presented by Chairs) http://www.ietf.org/proceedings/82/slides/dane-1.pdf ------------ Agenda Bashing : No comments on Agenda Plan for the Meeting (Presented by Warren Kumari) http://www.ietf.org/proceedings/82/slides/dane-0.pdf ------------ No comments on plan for today's meeting Working the Open Issues (Presented by Richard Barnes) http://www.ietf.org/proceedings/82/slides/dane-2.pdf ------------ See list for Recently Closed Issued. This presentation will only cover open issues. All decisions made at this meeting will be double-checked on the list. Issue #23 Idea: Use DANE to assert that no TLS services exist at specified host and port Proposal: Defer to a separate document, don't address in the base specification *** No objections to the proposed resolution Andrew Sullivan: Is this committing the working group to write a second draft? Do we have a volunteer to write a new draft? Or are we deciding to do nothing (for now) and is everyone okay with that? PHB: This is not something DANE should do. There are other groups working on this. Tim Polk: We can table the issue for this draft without having a volunteer (or a definite decision) for a future draft. *** CONCLUSION: Do nothing in the protocol document Issue #37 Idea: Add a usage to assert a self-signed server certificate directly Proposal: Make no change to the core specification. This use-case can be covered via usage 2. *** Alex Mayrhofer : I think this would make things easier for some people using self-signed certs Richard Barnes: We could add an example to the document showing how to use usage 2 to address this use-case EKR: Doesn't what Richard says require PKIX validation Richard: Yes, there does need to be PKIX validation for usage 2, you can't just do byte-wise comparison EKR: This sounds a lot more complicated Alex M: I kind of agree with EKR. Let's go with direct certificate association to make this as simple as possible. This is a usability issue. Steve Kent: There is code for PKIX validation that is currently available. This code can just be re-used to do usage 2 of DANE. PHB: This is all a lot more critical if there is no choice about the exclusivity Richard B: There is a requirement in the use-cases that you should be able to do this with a minimum of key management. The current document text does not require two key pairs (it just requires two certificates). Jim Schaad: I am lost as to why this needs to be a separate certificate? Richard B: The question is whether existing software stacks can do this usage 2 with only one certificate. There was some lack of clarity on the list with regards to what can be done with existing software stacks. Bill Manning : I think this is a useful thing to have in the stack, regardless of whether we actually decide to deploy this. Code points are not scarce. Paul Wouters: There will be a case (eg bare public key cert_type) that will not have anything of a PKIX TA. Make sure that's clear to implement Richard B: If we support bare public keys in the future, we will probably need a new usage. *** CONCLUSION: After hum, there is no clear results, we will open a big discussion of this on the list. Issue # 38 Idea: Enable support for DANE within EAP-FAST Proposal: Do nothing in the protocol specification. *** No objects to this proposal *** CONCLUSION: Do nothing in the protocol document Issue # 8 Idea: What about DNSSEC last mile? Proposal: Add a note to the security considerations. Note the problem and possible existing solutions. *** Stephen AD: Somewhere it needs to be explained how to do this. It can be done by reference, but there needs to be an explanation of how to do this. Paul H: Can we do a null pointer? We don't currently have anything to point to and we are probably the wrong people to write this. Stephen AD: It needs to be clear how to solve the last mile problem. Paul H: Is this going to hold up the current document? Stephen AD: I believe that this is one of things that the working group took on as part of the problem that the working group agreed to solve. Andrew S: Are you suggesting that we give DNS operational advice as one of the products of this working group? I'm not convinced that this working group has the expertise to provide operational advice for DNS. Olafur Gudmundsson: We have an RFC 3655 that is attempting to answer this last mile issue. Read that document. If it is not good enough for your purposes then we should revisit that document, but we put a lot of effort into that document and I think it is good. Russ Mundy: Are you including API issues in what this working group needs to do? Stephen AD: No Bill Manning: Is there ever a reason to use DANE without "high assurance"? Richard B: The use of "High assurance" is just slide text, its not in the document. There is another issue later on with regards to use of DANE without DNSSEC. *** CONCLUSION: We take to the list proposed text to add to Security Considerations Issue #10 Idea: DANE (usage 2) could conflict with PKIX information about intermediate CAs (especially with regards to revocation). Proposed action: This is a property of usage 2 of DANE. Add a paragraph to the Security Considerations to note this. *** PHB: If a Cert has an OCSP declared then a client needs to check it DANE or no DANE. EKR: Revocation seems fine to ignore here. If DANE says the TA is okay, then we should be trusting DANE. Bill Manning: We have two conflicting options for certificate validation. We need clear text (in security considerations) explaining the conflict and the resolution of which security regime wins when there is a conflict (and why). Richard B: The document will say that PKIX wins Alex M: Does DANE have the authority to over-ride existing PKIX validation rules? Paul H: Yes, DANE over-rides existing PKIX validition in other cases, the case described in this issue is the only case where a lack of clarity exists. We propose to clarify (in security considerations). Tim Polk: This type of possibility already exists in PKIX when you have multiple TAs. What is being proposed is not a radical departure from PKIX. EKR: Why do we care if some irrelevant third-party doesn't like a certificate. PHB: Do we really want to give the Iranian Revolutionary Guard a way to break revocation of the intermediate cert in a DigiNotar type situation? Bill Manning: Yes, we want control locally. Paul Hoffman: We, the document authros will cycle some proposed text on the mailing list before putting it in a future version of the draft. *** CONCLUSION: We will add clarifying text to security considerations as proposed. Issue: #36 Idea: Remove the restriction that all TLSA records MUST have DNSSEC protection Proposed action: Add to "client processing" text that specifies behaivor in all DNSSEC validation cases *** Peter Koch: Your diagram on the slide seems to be missing a branch. In particular, you do not seem to handle authenticated denial of existence. PHB: I think that it is reasonable to state that anyone publishing DANE records MUST sign them with DNSSEC or else be ignored. However the only requirement on the client should be that it authenticates the data by some means that may include DNSSEC but may use a mechanism such as a secure tunnel to a trusted resolver. Paul Wouters: Unsigned dnssec tlsa record is the same as non-dnssec aware client. The state for both is "indeterminate" and not "insecure" Warren Kumari: It may be useful to think of different classes of attacker. You might conceivably have an attacker who can only monkey with bits to the server and not monkey with bits to DNS ... in which case insecure DNS records could actually be useful. Warren Kumari: Not every client can do DNSSEC and not every zone is capable of doing DNSSEC that chains to the global root. This is most useful because it can start being done tomorrow. Peter Koch: There are different reasons why DNSSEC might not be available to the client. Operationally this seems bad. If I operate a DNSSEC signed zone, then I need to be able to understand the behaivor of the client is. Russ Mundy: It becomes incredibly hard to do any analysis with any degree of precision, once you move away from fully DNSSEC validated. Warren Kumari: This has only been proposed for the "Ristrictive" DANE usage. You would not do this for the "Permissive" DANE use-case. Richard Barnes: Actually, Warren, I think that is still an open question. Paul Hoffman: Who are you trying to give assurance to? Are we telling a zone owner "If you publish this, you get this result". Or are we telling a client "If you get this, here is what it means". If the answer comes back "Indeterminate", who are we trying to protect. The second option on the slide will confuse a lot of people, because we don't give assurance to anyone. (Although as Richard pointed out to me over the weekend, doing anything except the second option will have bad results in some cases). EKR: As I was saying earlier on jabber chat, my position is that if you have unsecured (i.e., not obviously bogus) information from DNS that suggests that a given TLS cert is invalid, you ought not to be accepting that cert. Olafur G: On the publishing side, DNSSEC is mandatory. On the client side, if you don't get DNSSEC you fall back to something (determined locally). Warren Kumari: Allowing clients to use non-DNSSEC secure DANE information in the "Restrictive" usage seems to open up no new Tim Polk: This seems like scope creep. This is the kind of issue that causes you to rat hole and not get a document done. DANE's job is to specify what happens in the case when information is delivered securely. Clients will figure out what they want to do in other cases. Eric Osterwiel: I think we are slipping down the slope of "What constitutes a secure DNS record". That's not the job of DANE. Articulating the second option of 'Insecure+/-' will cause us to lose the transparency that is one of the great benefits of DANE. Peter Koch: I think we have a hard time mandating that on the publishing side that DNSSEC must be used. What does that even mean? If I sign my zone but don't register keying material with my parent zone, have a complied with the specification? We do not want to create a situation where both parties can point at each other "e.g., I did not sign, but you should have been liberal in what you accepted". PHB: If you are telling people to trust this key ("Permissive" usage) then you need DNSSEC. In the other usage you don't need DNSSEC. Bill Manning: Note that DNSSEC state is fluid. A client could get a "secure" response one minute and an "indeterminate" or "insecure" response the next minute, and then "secure" again 15 minutes later. It is inappropriate to dictate DNS operations from DANE. Listen to Tim Polk. Paul Hoffman: There exist people in the room who have changed their mind in the last 15 minutes. In the next weeks or month, people need to not be afraid to say on the list that you have changed your mind. Paul Hoffman: If you believe that this is not the right chart to be looking at .. then please send art to the list. Jeff Hodges: An actual diagram or state table would be very helpful. *** CONCLUSION: Authors will try to create some candidate text that describes the process shown on the diagram, leaving blank [or calling out] the parts where it is not clear what the client should do. Future of Dane (Presented by Chairs) http://www.ietf.org/proceedings/82/slides/dane-3.pdf ------------ Question: Does the working group need an Operational Document? Or is the operations-related text in the current protocol docuemnt sufficient? *** No one claims that the current text in the protocol document is insufficent. *** Ondrej : If you think we need an operational document but you are afraid that you will be forced to volunteer to write it, then send a message to the list from a new email address. Proposal: Once the protocol is done we go into haitus, and see after like half a year whether there is sufficient interest/energy to take on additional work. *** Paul Hoffman: I am happy to help work on IPsec and S/MIME, but I am happy to put off this work until later. However, I think it is inappropriate for us to go to haitus until we have done work on Bare Keys (note that this might be joint work with the TLS WG). I would be happy to co-author a bare keys document with Paul W. Andrew S: Vote for shutting down instead of haitus. DNS-related working group should not go into haitus, we do not want this to live forever. Sean Turner: Would like to see S/MIME done. Open Mic -------- Olafur G: The current protocol document says that they will submit the TLSA record type for expert review. Is the protocol stable enough to have that review? Richard Barnes: I believe that it is stable enough for expert review. There has been only one recent proposal for changing bits on the wire, and I think that is going to resolved soon on the list. Peter Koch: Formally, because this is standards track we should not formally require expert review (for standards track we trust the wisdom of the IESG). EKR: Please clarify Section 4. (EKR sent comments to the list) EKR: I am also concerned about this bit where it requires that a specific TLS alert be sent. I sent extensive comments about that a while ago… Paul H: We picked a specific TLS error code out of thin air. EKR has opinions, other people probably also have opinions ... please discuss this on the list. Andrew S: The expert review process can take a while, please submit for expert review as soon as the wire format is settled. (You could possibly change wire format after expert review, but please do not) Warren [as Chair]: Please do not re-open previously closed issues on the list. If you do not agree with the consensus or believe the issue was not closed properly or that consensus was not actually reached, please contact the chairs off-list.