Subject: [dane] unedited raw ietf-82 taipei DANE minutes

From: =JeffH <[email-masked]>
Date: Sun, 13 Nov 2011 22:37:04 -0800

exported from: https://tools.ietf.org/wg/dane/minutes
at approx 22:35h PST Sunday, November 13 2011
[ not sure who the minute-taker was.
   these are distinct from jabber room log ]

###

      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.

###