IETF
dane@jabber.ietf.org
Monday, 14 November 2011< ^ >
Room Configuration

GMT+0
[00:21:39] stpeter joins the room
[00:22:23] stpeter has set the subject to: DANE WG | http://tools.ietf.org/wg/dane/
[00:29:59] Bjoern A. Zeeb joins the room
[00:47:30] =JeffH joins the room
[00:51:22] jimsch1 joins the room
[00:51:54] Yuri Nawata joins the room
[00:52:17] =JeffH leaves the room
[00:52:33] =JeffH joins the room
[00:52:49] mlepinski joins the room
[00:53:00] EKR joins the room
[00:54:50] =JeffH leaves the room
[00:56:59] Meetecho Scribe joins the room
[00:59:11] Lorenzo Miniero joins the room
[00:59:27] naptee joins the room
[00:59:59] Frederico Neves joins the room
[01:00:41] Andrew Sullivan joins the room
[01:01:08] guangqing joins the room
[01:01:32] bje joins the room
[01:01:34] PHB joins the room
[01:01:40] <Andrew Sullivan> Hi
[01:01:48] Paul Hoffman joins the room
[01:02:00] <Andrew Sullivan> Some of us are double-booked and can't listen to the audio stream
[01:02:12] <mlepinski> Chairs just announced that meeting will start 5 minutes late
[01:02:20] fujiwara joins the room
[01:02:28] Hiroki Suenaga joins the room
[01:02:30] <Andrew Sullivan> Any poss of not fully echoing here, but indication of where the discussion is?
[01:02:42] <mlepinski> Dane minutes in real-time (if you are interested) : http://tools.ietf.org/wg/dane/minutes
[01:02:54] John doe joins the room
[01:03:00] <Andrew Sullivan> oh, good reminder. Thanks!
[01:03:09] sftcd joins the room
[01:03:20] Scott Schmit joins the room
[01:03:50] ogud joins the room
[01:04:20] <PHB> anyone know how to get the audio to work on Windows?
[01:04:25] =JeffH joins the room
[01:04:33] MeetechoAudioFeed joins the room
[01:05:19] <Lorenzo Miniero> PHB, if you have VLC installed you can open the RTSP stream
[01:05:28] <Lorenzo Miniero> rtsp://taipei1.conf.meetecho.com/3330002.sdp
[01:05:33] <EKR> PHB: use your windows machine to buy a Mac.
[01:06:00] <PHB> EKR, i have plenty of MACs, they don't connect into the audio system
[01:06:17] <EKR> Use your PC to buy speakers for your mac? :)
[01:06:41] <Meetecho Scribe> Slide 1: DANE WG
[01:06:42] <Meetecho Scribe> Slide 2: Welcome to DANE
[01:06:59] <PHB> Ah that worked
[01:07:11] Olaf Kolkman (adium) joins the room
[01:07:52] Alex M joins the room
[01:08:04] yoav.nir joins the room
[01:08:04] <Paul Hoffman> Can actually-remote people hear Warren?
[01:08:13] <Alex M> Chairs slide: Welcome & overview slide.
[01:08:19] <EKR> I can.
[01:08:23] <Meetecho Scribe> Slide 3: Note Well.
[01:08:23] PaulWouters joins the room
[01:08:25] <EKR> But it's not in stereo, really.
[01:08:27] <EKR> Kinda a nnoying
[01:08:36] <=JeffH> minutes URI ?
[01:08:42] <mlepinski> http://tools.ietf.org/wg/dane/minutes
[01:08:46] <PHB> he sounds mumbly
[01:08:48] <Lorenzo Miniero> the volume is a bit low
[01:08:48] Meetecho Scribe leaves the room
[01:08:49] Melinda joins the room
[01:09:00] <Paul Hoffman> OK, that's what I expected.
[01:09:14] <PaulWouters> volume seems good for me
[01:09:22] Meetecho Scribe joins the room
[01:09:39] Meetecho Scribe leaves the room
[01:09:43] russmundy@jabber.org joins the room
[01:09:43] richard.barnes joins the room
[01:09:48] <richard.barnes> morning, all
[01:09:52] <Alex M> Agenda bashing - no comments.
[01:09:58] Meetecho Scribe joins the room
[01:10:11] semery joins the room
[01:10:18] <Alex M> "What we want to accomplish" - Slide Deck
[01:10:39] <Alex M> "Grand plan" slide.
[01:10:43] <Meetecho Scribe> Slide 1: DANE WG
[01:10:46] <Meetecho Scribe> Slide 2: Welcome to DANE
[01:11:29] Alex M notes: "Meetecho Scribe" seems to be behind slightly.
[01:11:44] <Meetecho Scribe> Meetecho session is up now
[01:11:49] <Meetecho Scribe> Slide 3: Note Well.
[01:11:54] <Alex M> "The additional fixes" slide is shown
[01:12:06] <Meetecho Scribe> yes
[01:12:08] <Meetecho Scribe> sorry
[01:12:26] <Alex M> no questions on the "grand plan".
[01:12:38] <EKR> Should I be seeing slides on the Meetecho? I'm just seeing hte logo
[01:12:39] <bje> awake on jabber here!
[01:12:41] <EKR> and "no presentation"
[01:12:45] <Alex M> Richard Barnes: "DANE WG Issues status".
[01:14:09] <Alex M> "What will be covered" slide.
[01:14:10] <PaulWouters> (feeedback argh)
[01:14:35] <Paul Hoffman> Feedback on remote? We're not hearing it in the room.
[01:14:41] <bje> audio is clipping
[01:14:50] Karen O'Donoghue joins the room
[01:14:50] <EKR> I don't think it's feedback. It's richard too close to the mike
[01:14:54] <Alex M> "issue #23" slide shown.
[01:15:06] <=JeffH> richard said "issue 1" but really means issue #23 is first to discuss
[01:15:25] <EKR> no, it's still a problem
[01:15:53] <Scott Schmit> I would think that the hastls propsoal would work for this too
[01:16:00] <bje> seems OK at the moment, on audio
[01:16:13] <PaulWouters> (yes it is ok now)
[01:16:17] <EKR> yes
[01:16:20] <Alex M> guys, if you want me to reflect something on the mic, pleas eprefix with "mic:"
[01:16:34] <Alex M> "issue #37" slide shown.
[01:17:32] <EKR> mic: doesn't what Richard just say require PKIX validation?
[01:18:01] <Scott Schmit> this requires that anyone adding dane to reconfigure their servers
[01:18:18] <Scott Schmit> others might believe that type 2 already allows for this, the authors clearly disagree
[01:18:44] <Paul Hoffman> The authors don't clearly disagree.
[01:19:12] <EKR> mic: that sounds a lot more complicated than "just use this cert and compare with memcmp()"
[01:19:16] <=JeffH> rbarnes: this means pkix validation up to a trust anchor that the domain controls
[01:19:22] <Scott Schmit> they said just now (or their representative) that "to use type 2, you must create a TA and sign the TLS cert"
[01:19:31] <EKR> humming against
[01:19:38] <PHB> humming against
[01:19:39] <jimsch1> I think that Richard is incorrect - if it is a TA and it is the only certificate then a memcmp is all that is needed
[01:19:40] <PaulWouters> hummm against
[01:20:14] =JeffH leaves the room
[01:20:24] <PHB> mic: This is all a lot more critical if there is no choice about the exclusivity
[01:21:03] <PHB> mic: if you want to boss people arround you have to make things practical and cover all the corner cases
[01:21:22] Sean Turner joins the room
[01:22:25] pawal joins the room
[01:22:31] =JeffH joins the room
[01:22:55] <EKR> So, specifically, if one wanted to use Paul's "Bare Key" thing, what would one do?
[01:23:34] <EKR> wow, two certs with the same key pair seems shockingly awful
[01:23:58] John doe leaves the room
[01:24:25] <PHB> mic: One keypair and two certs? Seriously? That is the worst of both worlds. Do one or the other
[01:24:36] <PaulWouters> EKR: I think the next type in the draft covers that use case?
[01:25:03] <PaulWouters> EKR: but its getting really weird.
[01:25:05] <EKR> Paul: I'm not sure. As the mail I just sent to the list indicates, I'm getting a bit lost. :)
[01:25:21] richard.barnes leaves the room
[01:25:39] <EKR> I'd like to see a flowchart of the validation rules for each of these cases.
[01:26:13] <PaulWouters> mic: 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
[01:26:52] Phillip Hallam Baker joins the room
[01:26:52] <=JeffH> ekr: flowchart in spec ?
[01:27:14] Rick joins the room
[01:27:29] <EKR> Well, maybe we could start with seeing one and then decide if the spec needs it :)
[01:27:58] <=JeffH> ekr: agree
[01:28:03] <PaulWouters> ping-pong :)
[01:28:39] sali joins the room
[01:29:11] Francisco Arias joins the room
[01:29:22] <EKR> hum for needs to be explored on list
[01:29:24] <Alex M> hum: Usage #2 with additional text will cover this?
[01:29:31] <Scott Schmit> hum
[01:29:44] <PHB> hum to agree with EKR
[01:29:48] <Alex M> 1/3 for each "covered", "to be explroed more", "have no idea"
[01:29:49] <PaulWouters> hum for more talk on the list
[01:29:57] <=JeffH> ondrej: no clear result from that humming
[01:29:58] <Alex M> no clear concensuls
[01:30:00] <EKR> I'm open to being convinced this is good enough but it's not clear to me now.
[01:30:20] richard.barnes joins the room
[01:30:26] <sftcd> back to issue#23 for a hum
[01:30:26] <Alex M> one slide back to #23 - Ondrej taking hum.
[01:30:40] <Meetecho Scribe> Slide 3: Issue #23: DANE exclusivity
[01:30:54] <Scott Schmit> hum
[01:31:14] <Meetecho Scribe> Slide 5: Issue #38: EAP-FAST
[01:31:16] <Alex M> more people for "doing nothing".
[01:31:25] <Alex M> regarding #23.
[01:32:27] <PHB> MIC: I think that this is something that DANE should not do ever
[01:32:43] <PHB> MIC: There are other groups doing this, DANE is not the place to do it
[01:33:33] <PHB> that was on 23
[01:33:39] <Alex M> thanks!
[01:34:07] <Andrew Sullivan> +1 that was what I wanted to make clear
[01:34:29] <Meetecho Scribe> Slide 5: Issue #38: EAP-FAST
[01:34:33] <=JeffH> warren: if folks that think issue #23 is important, then they should write an I-D specifically regarding it
[01:35:51] <Scott Schmit> hum
[01:35:59] <Scott Schmit> I can actually hear that one!
[01:36:01] <Meetecho Scribe> Slide 6: Issue #8: The last mile problem
[01:36:03] <=JeffH> jim schaad @mic: happy to have wg not address issue #38 now, will write draft later if motivated
[01:36:05] <Alex M> no hum against from the room.
[01:36:37] pawal leaves the room
[01:36:41] pawal joins the room
[01:37:15] <PaulWouters> haha
[01:37:23] <PaulWouters> backspace backspace backspace
[01:37:27] <PaulWouters> he was just in time :)
[01:37:35] antoin joins the room
[01:37:44] <=JeffH> so wrt Issue #8: The last mile problem -- proposal is to add section to sec cons in dane spec
[01:37:59] antoin leaves the room
[01:38:13] <EKR> will that section say "this technology does not actually work?"
[01:38:16] <Alex M> people lining up to the mic.
[01:38:24] Hiroki Suenaga leaves the room
[01:38:27] antoin joins the room
[01:38:46] <ogud> is RFC3655 good enough ?
[01:39:38] Karen O'Donoghue leaves the room
[01:40:22] <PHB> I just lost sound, anyone else?
[01:40:26] <EKR> no, I still have sound
[01:40:33] <PaulWouters> still have sound
[01:40:33] <Scott Schmit> I lost sound
[01:40:36] <EKR> huh.
[01:40:38] =JeffH just to note, this discussion is being pretty well reflected in the minutes here: https://tools.ietf.org/wg/dane/minutes
[01:40:42] <Lorenzo Miniero> PHB try opening the stream again
[01:40:44] MeetechoAudioFeed leaves the room
[01:40:51] Scott Schmit restarts stream
[01:41:21] <Lorenzo Miniero> ops no you're right, I have no audio anymore as well
[01:41:28] ggm joins the room
[01:41:32] <Alex M> anybody has audio?
[01:41:35] <Lorenzo Miniero> we're fixing this at the mixer, sorry about that
[01:41:35] <EKR> yes, I do
[01:41:47] <ggm> jf you don't have DNSSEC what is the F-ing point of DANE? how can you trust any of the certinfo?
[01:41:55] <ggm> so I cant even begin to understand how it works without dnssec.
[01:42:12] <PHB> @ggm you may do DNSSEC to a trusted resolver and then have a secure channel to that
[01:42:15] <ggm> in which case, if the language around dnssec is NON NORMATIVE then .. again.. whats the point.
[01:42:15] <PaulWouters> ggm: "there is a theoretical corner case that would help a person when the attacker only attacks tls, not dns"
[01:42:28] <PaulWouters> ggm: after long discussions, the use-cases document got that added.
[01:42:40] <Scott Schmit> got sound back
[01:42:44] <PHB> @ggm for example say the US decides to cut .cu and .ps from the net
[01:42:44] <Lorenzo Miniero> the audio is back
[01:42:51] <PaulWouters> IMHO, that was dumb then. and since the use-cases punted to the protocol, i want this draft to say "must use dnssec"
[01:43:06] <ggm> path to dns should be secured, dns contents should be signed path
[01:43:19] Suz joins the room
[01:43:37] MeetechoAudio2 joins the room
[01:43:43] <PaulWouters> yes, imho TLSA without dnssec should be ignored.
[01:43:49] <Scott Schmit> sound quality is very bad
[01:43:49] Rick leaves the room
[01:43:59] <Scott Schmit> I can't even tell what that hum was for
[01:44:01] <Paul Hoffman> What kind of bad, Scott?
[01:44:07] <Lorenzo Miniero> yes, we're working on this sorry...
[01:44:13] <Scott Schmit> a lot of thumping, just stopped
[01:44:14] <EKR> so if you get TLSA without DNSSEC and it says that the TLS cert is borked, you ignore that? Seems unwise
[01:44:20] <Alex M> repeating hum
[01:44:20] <Scott Schmit> I hear air handlers
[01:44:31] <Scott Schmit> thumping again
[01:44:37] <Andrew Sullivan> I think not ignoring TLSA without DNSSEC qualifies you as a moron, but it doesn't need to be in the text
[01:44:40] <Alex M> "let's add a paragraph about this" - text will be provided.
[01:44:47] <PaulWouters> i cannot tell if that means the TLS is broke. I only know something is broke, cert or dns. i dont know which
[01:44:52] <Andrew Sullivan> except in sec cons'rs
[01:44:56] <EKR> Andrew, do you have an actual argument or just name calling?
[01:45:16] <EKR> Since "Fail safe" seems like a pretty reasonable design choice
[01:45:25] <Scott Schmit> sound cut again
[01:45:30] <Paul Hoffman> Could y'all wait until the last slide?
[01:45:37] <PHB> Actually there are two separate concerns, the first is whether the DNS zone with the TLSA info is DNSSEC signed (clearly it should)
[01:45:55] <Scott Schmit> that sounds better
[01:46:01] <EKR> Paul: so you know something is broke but you want to proceed anyway? out-standing!
[01:46:04] <PHB> The second and separate concern is what the client uses to validate DNS information.
[01:46:07] <Paul Hoffman> Scott: send mail to mtd@ietf.org
[01:46:25] <Scott Schmit> for?
[01:46:37] <Paul Hoffman> The sound problems.
[01:46:42] <Alex M> slide: "issue #10"
[01:46:45] <PaulWouters> ekr: you can say "if we are sure dns OR cert is broken, abort...
[01:46:47] weiyinxing joins the room
[01:47:10] <PaulWouters> but then you abort on dns without dnssec.
[01:47:13] <PaulWouters> which can be spoofed
[01:47:34] Karen O'Donoghue joins the room
[01:47:51] <EKR> yes, I recognize that, but that seems like a DoS attack primarily, which an attacker can generate by sending a bogus A record
[01:48:24] <Andrew Sullivan> @ekr: surely not
[01:48:39] <PaulWouters> ekr: telling people to trust a public key with no protection whatsoever is just unclean crypto waving
[01:48:42] <stpeter> is Jim Schaad in the chatroom?
[01:48:42] <EKR> mic: the TA thing seems designed to supplant the existing trust anchors
[01:48:49] Rick joins the room
[01:48:54] <ggm> so.. if they'd stuck to selfsigns this wouldn't arise?
[01:48:56] Satoru Kanno joins the room
[01:49:02] <ggm> ie, this is a consequence of re-introducing a chain into things?
[01:49:07] <Andrew Sullivan> if you fail to get a validatable record, it's not "just missing", it's "bad, stop now". DNSSEC-enabled decision making is 3 value logic
[01:49:19] <EKR> what steve just read is a different conversation
[01:49:20] <Andrew Sullivan> "valid", "provable nonsecured", "bogus"
[01:49:30] <ggm> "unknown"
[01:49:35] <sftcd> @ekr: oops:-)
[01:49:36] <ggm> "conflicted"
[01:49:48] <ggm> "maybe, but depends which way you look at it"
[01:49:55] Bjoern A. Zeeb leaves the room
[01:49:56] <EKR> mic: my point here is that the TA things seems designed to override the trust anchor list, so revocation seems fine to ignore here.
[01:50:00] <EKR> mic: no, no, no.
[01:50:00] ondrej.sury joins the room
[01:50:02] <PHB> mic: If a cert has an OCSP validation point declared then clients have to check it, DANE or no DANE,
[01:50:10] <EKR> mic: the stuff I wrote prefaced with "mic:" is about htis.
[01:50:10] ray joins the room
[01:50:24] <EKR> mic: yes=
[01:50:39] <EKR> mic: look, this issue is about how you behave if a cert on the added TA list is revoked, right?
[01:50:39] Rick leaves the room
[01:50:52] <jimsch1> PHB- if it is a TA then it is not validated and the OCSP will not be checked
[01:50:55] <EKR> mic: so if DANE says the TA is OK, then why aren't we trusting DANE?
[01:51:14] <PHB> @jim, if it has an OCSP point then it isn't a TA
[01:52:04] <PaulWouters> oh i know... why dont have we have a method for not having two conflicted auth types [sarcasm]
[01:52:06] <jimsch1> Not necessarily - I can make any certificate be the data that setsup a TA - independent of what is acutally in the certificate
[01:52:43] <PaulWouters> mic: DANE cannot fix PKIX hierarchies. DANE should not attempt to address PKIX validation issues
[01:52:47] weiyinxing leaves the room
[01:52:57] <stpeter> jimsch1: at http://tools.ietf.org/wg/appsawg/agenda?item=agenda82.html we are on draft-kucherawy-greylisting-bcp, probably we will get to the WG previews in 5-10 minutes
[01:53:00] <EKR> To return to the side conversation: I agree that if you get information from DANE w/o DNSSEC that says that a key you otherwise would not trust is valid, then you should ignore it. Contrariwise, if you get information from DANE W/o DNSSEC that says that a key you owuld otherwise trust is not valid, then one ought to listen to it.
[01:53:08] <EKR> It's not symmetrical
[01:54:10] <EKR> mic: the semantics here is that DANE is saying "This intermediate CA is a trust anchor". So, why do you care if some irrelevant third party happens not to like it :)
[01:54:35] jimsch1 leaves the room
[01:54:56] <PHB> PHB: MIC Do we really want to give the Iranian Revolutionary Guard a way to break revocation of the intermediate cert in a DigiNotar type situation
[01:56:04] <PaulWouters> phb: you are arguing for dane tlsa records giving exclusivity?
[01:56:11] <Scott Schmit> mic: the flip side is that they could revoke something attested to by dane
[01:56:27] Shoichi Sakane joins the room
[01:57:01] <PHB> Paul, no because the IRG will control the DNSSEC anchor for the DNS root visible in Iran (and they control distribution of Windows there)
[01:57:09] <PaulWouters> humm for more clarifying text
[01:57:38] <EKR> PHB: but then cant the IRG just use a type 2 assertion to authorize some totally different key
[01:58:07] Hugo Salgado joins the room
[01:58:08] <Andrew Sullivan> It strikes me that there've been a lot of hums for clarifying text but not so many mails to the list with that text.
[01:58:14] <Scott Schmit> PHB: but then the root anchor key won't match what the clients expect?
[01:58:20] <Andrew Sullivan> I suggest perhaps people might send some text
[01:58:21] <PaulWouters> ekr: not if we just pin the EEcert... and if using that, why not bare key cert_type :/
[01:58:36] <EKR> ekr: by pinning you mean HSTS?
[01:58:56] <EKR> If we're using HSTS-style pinning, then frankly, the value of DANE in general goes way down.
[01:58:57] <PaulWouters> no not using CA's. just EEcert. (I think that's type 3 ?)
[01:58:58] pawal leaves the room
[01:59:16] <EKR> Wait, are you assuming the attacker controls the DNS or not?
[01:59:28] bje leaves the room
[01:59:29] pawal joins the room
[01:59:30] <PaulWouters> hsts requires leap of faith :/
[01:59:37] jimsch1 joins the room
[01:59:46] <EKR> Yes, of course it does.
[01:59:57] weiyinxing joins the room
[01:59:59] <PaulWouters> dane does not
[01:59:59] <EKR> Again, I'm not clear on the threat model you're assuming
[02:00:10] <Meetecho Scribe> Slide 8: Issue #36: Only requiring DNSSEC where i
[02:00:13] <PHB> Paul HSTS is secure after first contact, there are ways to improve on that
[02:00:18] <EKR> Well, except for the leap of faith involved in assuming that anbody can use DNSSEC.
[02:00:20] <Paul Hoffman> OK, all you remote people who were arguing about this before: here it comes.
[02:00:31] <EKR> Paul: I knew this was coming, but....
[02:00:32] <PaulWouters> phb: if you are under attack, you never get to port 443, you never get to see hsts
[02:01:04] <PaulWouters> ekr: have you tried dnssec-trigger yet? It's getting pretty good, even in the most bastarised hotspots
[02:01:28] <Meetecho Scribe> Slide 9: DANE Decision Tree
[02:01:42] <EKR> let me know when it ships with chrome
[02:03:04] <PaulWouters> mic: richard it was different from what you suggested. There is one corner case where there might be a situation where it could possible give some extra information. It's not worth the confusion :P This slide PROVES it is not worth it
[02:04:37] <PHB> MIC: I think that it is reasonable to state that anyone publishing DNSSEC 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.
[02:05:10] <Alex M> do you mean DANErecords?
[02:05:20] <PHB> yes, sorry
[02:05:23] <Alex M> kk
[02:05:38] <PaulWouters> phb: correct
[02:05:43] <EKR> mic: what's 'indeterminate'?
[02:06:05] <PaulWouters> phb: such a resolver ideally would not pass unprotected TLSA records...
[02:06:15] <Scott Schmit> EKR: iirc, it's "isolated root for which you don't have a ta"
[02:06:22] <PaulWouters> ekr: it means "no dnssec aware client"
[02:06:22] <EKR> ah
[02:06:24] <EKR> neer mind mic
[02:06:25] <Scott Schmit> s/root/tree/
[02:07:04] Karen O'Donoghue leaves the room
[02:07:10] weiyinxing leaves the room
[02:07:22] Karen O'Donoghue joins the room
[02:07:27] <Alex M> Phil, i agree to that.
[02:07:44] <PaulWouters> mic: unsigned dnssec tlsa record is the same as non-dnssec aware client. The state for both is "indeterminate" and not "insecure"
[02:08:00] <ondrej.sury> Isn't that the last mile problem again (the tunnel to secure trusted resolver)?
[02:08:18] <PHB> PaulW - ideally, but the trusted resolver may also be doing things such as black-holing known malware sites.
[02:08:52] <PHB> so the trusted resolver is trusted to keep the client safe, not process the records as the domain owner intends
[02:08:59] <PaulWouters> phb: and then it is a last-mile issue again.
[02:09:12] <EKR> mic: 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.
[02:09:21] <ondrej.sury> ok, so trusted != DNSSEC-validating?
[02:09:31] <EKR> mic: since any attacker who can inject an invalid no-match record can inject an invalid A record
[02:09:38] <PHB> ondej, precisely.
[02:09:45] <PHB> trusted = keeps me safe
[02:09:57] <PHB> trusted != connects me to the malware sites
[02:10:14] <EKR> mic: this is different from accepting a cert that you would otherwise not because of unsecure DANE information.
[02:10:15] <PaulWouters> ekr: fake A record does not matter? because its the cert info you will be looking at?
[02:10:28] <EKR> paul, no, they blackhole.
[02:10:35] <EKR> this is a DoS attack
[02:10:43] <Alex M> ondrej, want to reflect that yourself, since you answered it?
[02:10:54] <PaulWouters> ekr: then you say: if you dont sign, there is no point in TLSA, and unsigned TLSA's should be dropped
[02:11:03] <EKR> no, that's not what I said.
[02:11:37] <Alex M> 4 people lining at the mic..
[02:11:40] <EKR> again, your theory seems to be that I get an unsigned TLSA that would tell me NOT to use a given cert, and I'm going to ignore that. Why would you do that?
[02:11:56] <ondrej.sury> alex: I am still processing the PHB's sentence with "trusted" resolver...
[02:12:08] ykjung83 joins the room
[02:12:09] <PaulWouters> mic: we have HSTS for that
[02:12:23] ykjung83 leaves the room
[02:12:41] <yoav.nir> I think the significance of a non-DNSSEC TLSA record is way too subtle for implementation by people who are not right now in the room. Yes, there is some value in non-DNSSEC cert-lock, but not enough to justify such subtlety. Subtlety leads to security bugs. We should just say that TLSA requires DNSSEC
[02:13:04] <PaulWouters> yoav: exactly.
[02:13:11] <PHB> Who said anything about cert-lock?
[02:13:29] <PHB> Just turn on TLS and don't bother to tell the user anything
[02:14:06] <PaulWouters> without dnssec there is no provenly insecure
[02:14:18] <yoav.nir> PHB: they didn't, but I don't see a non-DNSSEC TLSA record having any value otherwise.
[02:15:01] <PaulWouters> how do people feel about DNSKEY records without RRSIG?
[02:15:01] <PHB> Just increasing the amount of encrypted traffic is a big win
[02:15:02] <PaulWouters> :P
[02:15:24] <PHB> Very hard to MITM every tunnel out of Iran
[02:16:11] <PHB> If only the dissident traffic is encrypted it is much easier to spot dissidents
[02:16:28] <PaulWouters> mic: so people dont even agree on what the corner is where we could use non-dnssec TLSA?
[02:16:47] jaap joins the room
[02:17:23] =JeffH Alex is in line, currently about 3d, to relate jabber room "mic:" requests.....
[02:17:47] Rick joins the room
[02:18:15] yoav.nir leaves the room
[02:18:53] =JeffH leaves the room
[02:19:29] =JeffH joins the room
[02:19:39] jaap leaves the room
[02:19:56] yoav.nir joins the room
[02:20:15] <EKR> mic: I'm talking about the consuming side
[02:22:03] German Hernandez joins the room
[02:22:04] <ondrej.sury> PHB: Just to clarify - your position is to not require DNSSEC?
[02:22:11] <PHB> mic: This all depends on whether you are doing positive or negative trust. If you are telling people 'trust this key' then you need DNSSEC. If you are telling them 'only trust keys under X' then you do not need DNSSEC.
[02:22:25] <PaulWouters> hear hear
[02:22:28] <Olaf Kolkman (adium)> +1
[02:22:33] <PHB> ondrej, no, I said need DNSSEC on the publishing the zone.
[02:22:36] <Scott Schmit> +1
[02:22:36] <EKR> I can live with that.
[02:22:42] Tony Hansen joins the room
[02:22:52] <PHB> ondrej, clients can validate according to any mechanism they trust
[02:23:07] <Scott Schmit> so maybe we change it to MUST sign
[02:23:22] <PaulWouters> mic: so Warren and Richard could not even agree on what the corner is where we could use non-dnssec TLSA? It's soo small it should really not be considered at all
[02:23:55] naptee leaves the room
[02:23:56] Rick leaves the room
[02:24:34] japi joins the room
[02:24:35] <ondrej.sury> for all: Is PHB's possitive vs negative clear enough for consumer side? (for providing side - it's MUST DNSSEC-sign)
[02:24:59] <ondrej.sury> or do you want to also add constraint on consuming side - MUST DNSSEC-validate ?
[02:25:38] <yoav.nir> PHB: that' s what I meant by subtle. The difference is not obvious enough for the marginal utility of a non-secure "only trust certificates from x" TLSA record.
[02:26:42] <ggm> if you have two+ mechanisms to find trust and they don't agree, either you only accept positives, and ignore even active rejects, or, you have voting, or you have uncertainty: if you accept rejects, then the order you find things alters what happens
[02:26:51] <ggm> this is a problem dane can't solve if it accepts more than 1 mechanism
[02:27:09] japi leaves the room
[02:27:19] <ggm> oh, I suppose you can do all, and accept any reject and then its the DoS thing
[02:27:19] jaap joins the room
[02:27:25] <PHB> yoav, I think DANE should stick to only distributing keys. The negative trust stuff should be multi-model and be capable of going over HTTP headers, data driven updates, and sometimes DNS
[02:27:28] wilmer joins the room
[02:27:28] <ggm> and, if you reject all rejects if any accept is set, then its the iranian guard problem
[02:27:37] weiyinxing joins the room
[02:27:49] <ggm> so its least-worst choices time.
[02:27:59] <ggm> if you avoid dos, you can be hosed by mitm attacker
[02:28:08] <ggm> if you hunt for all potential mitm, you can be dos by somebody
[02:30:43] naptee joins the room
[02:30:49] <PHB> ggm don't forget that blocking twitter with DoS is a huge win for the IRG. Which is why I have changed my strategy on this completely
[02:31:02] blah joins the room
[02:31:10] blah leaves the room
[02:31:32] Eric Osterweil joins the room
[02:32:06] ray leaves the room
[02:32:18] <ggm> but thats the fundamentals right? either you have to poll all sources and vote/weight/decide, or you have to accept uncertainty/risks of being phreaked, and there are no good simple ways out, if you accept multiple trusts over your connection: if they conflict you have to chose
[02:33:00] <PaulWouters> RRSIG(TSLA)
[02:33:02] <PaulWouters> :/
[02:33:07] <yoav.nir> A record that says "only use certificates from DigiNotar" effectively denies service to any site using some other CA certificate. I would now want to accept this without it being signed
[02:33:12] <PHB> ggm, which is why I now have people in the trust decision loop.
[02:33:22] Paul Hoffman leaves the room
[02:33:41] <EKR> yoav: but, again, any attacker who can insert that record can insert an A record to 127.0.0.1
[02:33:43] <PaulWouters> yoav: s/now/not
[02:34:11] <PaulWouters> ekr: some attackers want to mislead TLS, not DoS
[02:34:27] <Meetecho Scribe> Presentation stopped
[02:34:31] <EKR> how does this make misleading TLS any easier?
[02:34:39] <Meetecho Scribe> Slide 1: The Future of DANE?
[02:34:42] <EKR> You keep confusing the negative and positive cases.
[02:34:43] <Alex M> new slide deck "The future of DANE".
[02:35:00] <Alex M> "post-DANE protocol work".
[02:35:02] Paul Hoffman joins the room
[02:35:27] <Meetecho Scribe> Slide 2: Operational Draft?
[02:35:45] <Alex M> i find that my T-Shirt, even though it's about DNS, fits DANE quite well ;)
[02:36:06] Karen O'Donoghue leaves the room: Replaced by new connection
[02:36:09] Karen O'Donoghue joins the room
[02:36:15] <yoav.nir> EKR: Maybe they can, but that doesn't mean we want to carve them another hole.
[02:36:33] <EKR> What do you mean another hole? It's the same hole.
[02:37:24] <Meetecho Scribe> Slide 3: What else?
[02:37:48] <Meetecho Scribe> Slide 4: Go into hiatus?
[02:38:26] <yoav.nir> All servers have A records. No servers have TLSA records (for now). Messing with the A record will be detected quickly. Inserting a TLSA record will take longer for the website owner to figure out.
[02:38:41] <Meetecho Scribe> Slide 3: What else?
[02:38:46] <PHB> Mic: I argued for consideration of other protocols in the charter because I wanted to avoid a protocol stovepiped so that it would only ever work for TLS. Since that has now been achieved and since I see nobody stating interest in deploying code for IPSEC or S/MIME I can't see an argument for the WG working on them.
[02:39:02] <PaulWouters> mic: update from me http://tools.ietf.org/html/draft-wouters-tls-oob-pubkey-01 moves from TLS extension to new cert_type of 'bare public key'
[02:39:19] <PaulWouters> mic: please discuss how you love this in the TLS WG :)
[02:39:28] <Alex M> ok, queuing at pos #3
[02:41:19] rick joins the room
[02:41:49] <Sean Turner> well I'd like to see S/MIME done
[02:42:10] <Sean Turner> not sure whether I like Paul's proposed solution
[02:42:30] <PaulWouters> phb: there is already IPSECKEY
[02:42:43] <Meetecho Scribe> Slide 5: AOB?
[02:42:51] <richard.barnes> PaulWouters: +1, don't really see why we need to do anything for IPsec here
[02:42:53] <PHB> @Paul, yes, but no deployment experience
[02:42:55] Mikael joins the room
[02:43:09] <PaulWouters> as in "stop ping ponging me between the two groups" :P
[02:43:11] <PHB> @Paul if people were going to work on deployment of IPSEC based on DANE, fine
[02:43:12] Chris Griffiths joins the room
[02:43:28] <EKR> mic: I just sent a set of comments to the mailing list about S 4.x being pretty unclear.
[02:43:31] <PHB> @Paul otherwise its just another draft going nowhere.
[02:43:32] <Scott Schmit> as many times as we've changed it so far... I'm dubious
[02:43:33] <EKR> mic: is there some proposal to clarify that?
[02:44:07] <richard.barnes> oh, and that was me
[02:44:09] Marco Davids joins the room
[02:44:10] <richard.barnes> (at the mic)
[02:44:12] <=JeffH> ekr: what is "that" ?
[02:44:27] <EKR> mic: clarify S 4
[02:44:28] <richard.barnes> EKR: Yeah, yeah, we'll do it
[02:44:35] <Alex M> 7me acks
[02:44:56] <EKR> Barnes: there is also the issue of where it levys a requirement on TLS. What was the resolution on that?
[02:45:55] <richard.barnes> EKR: see audio stream
[02:46:01] <richard.barnes> how does it levy a requirement on TLS?
[02:46:08] <EKR> mic: I'm also concerned about this bit where it requires that a specific TLS alert be sent. I sent extensive comments about that a while ago…
[02:46:20] Marco Davids leaves the room
[02:46:27] Marco Davids joins the room
[02:46:41] <richard.barnes> ah, yeah, that. yeah i think that can be changed
[02:47:34] <EKR> mic: it's not just a matter of which error code, I think it's more complicated than that.
[02:48:47] <EKR> mic: I did provide quite extensive comments
[02:48:55] Olaf Kolkman (adium) leaves the room
[02:49:09] <richard.barnes> EKR: Open an issue :)
[02:49:19] <EKR> Sure, I can open an issue
[02:49:59] Karen O'Donoghue leaves the room
[02:50:04] Eric Osterweil leaves the room
[02:50:19] semery leaves the room
[02:50:24] russmundy@jabber.org leaves the room
[02:50:30] PHB leaves the room
[02:50:30] Francisco Arias leaves the room
[02:50:32] jimsch1 leaves the room
[02:50:41] yoav.nir leaves the room
[02:50:42] antoin leaves the room
[02:50:44] German Hernandez leaves the room
[02:50:48] pawal leaves the room
[02:50:51] mlepinski leaves the room
[02:50:54] Alex M leaves the room
[02:50:55] Frederico Neves leaves the room
[02:51:01] <PaulWouters> thanks jabber mic interface!!
[02:51:05] ogud leaves the room
[02:51:05] sftcd leaves the room
[02:51:05] Sean Turner leaves the room
[02:51:52] Hugo Salgado leaves the room
[02:52:39] richard.barnes leaves the room
[02:52:45] Suz leaves the room
[02:52:50] <Meetecho Scribe> the recordings of this session will be available at http://ietf82.conf.meetecho.com/index.php/Recorded_Sessions
[02:53:07] <Meetecho Scribe> bye
[02:53:24] Lorenzo Miniero leaves the room
[02:53:47] MeetechoAudio2 leaves the room
[02:54:26] guangqing leaves the room
[02:54:41] Marco Davids leaves the room
[02:54:50] jaap leaves the room
[02:55:38] <Meetecho Scribe> Presentation stopped
[02:55:46] shiomin joins the room
[02:56:00] Meetecho Scribe leaves the room
[02:56:02] Frederico Neves joins the room
[02:56:15] Scott Schmit leaves the room
[02:56:25] Yuri Nawata leaves the room
[02:56:28] ggm leaves the room
[02:56:44] Andrew Sullivan leaves the room
[02:56:57] Mikael leaves the room
[02:57:16] PaulWouters leaves the room
[02:57:27] Olaf Kolkman (adium) joins the room
[02:57:39] Frederico Neves leaves the room
[03:02:00] Olaf Kolkman (adium) leaves the room
[03:02:44] pawal joins the room
[03:03:59] ggm joins the room
[03:04:13] ggm leaves the room
[03:05:35] Melinda leaves the room
[03:05:47] Chris Griffiths leaves the room
[03:08:05] shiomin leaves the room
[03:08:12] sftcd joins the room
[03:08:12] Paul Hoffman leaves the room
[03:08:35] Shoichi Sakane leaves the room
[03:08:56] Shoichi Sakane joins the room
[03:08:57] shiomin joins the room
[03:09:47] ggm joins the room
[03:12:03] ondrej.sury leaves the room
[03:12:59] sali leaves the room
[03:14:05] shiomin leaves the room
[03:16:24] Marco Davids joins the room
[03:19:05] Shoichi Sakane leaves the room
[03:20:05] Karen O'Donoghue joins the room
[03:20:47] =JeffH leaves the room
[03:21:23] sftcd leaves the room
[03:23:03] Marco Davids leaves the room
[03:23:51] Karen O'Donoghue leaves the room: Replaced by new connection
[03:23:55] Karen O'Donoghue joins the room
[03:29:39] fujiwara leaves the room
[03:30:01] Karen O'Donoghue leaves the room
[03:30:35] Satoru Kanno leaves the room
[03:31:57] naptee leaves the room
[03:35:05] naptee joins the room
[03:35:19] Karen O'Donoghue joins the room
[03:35:29] naptee leaves the room
[03:37:21] Tony Hansen leaves the room
[03:38:38] Sean Turner joins the room
[03:39:44] ggm leaves the room
[03:41:05] Sean Turner leaves the room
[03:42:01] weiyinxing leaves the room
[03:42:15] richard.barnes joins the room
[03:42:45] richard.barnes leaves the room
[03:48:41] wilmer leaves the room
[03:55:16] Phillip Hallam Baker leaves the room
[03:55:20] rick leaves the room
[04:01:42] Sean Turner joins the room
[04:02:36] Sean Turner leaves the room
[04:12:28] ogud joins the room
[04:15:52] stpeter leaves the room: Disconnected: connection closed
[04:27:36] Karen O'Donoghue leaves the room
[04:27:49] ogud leaves the room
[04:35:56] Paul Hoffman joins the room
[04:42:22] Sean Turner joins the room
[04:44:57] pawal leaves the room
[04:46:29] Satoru Kanno joins the room
[04:48:12] Sean Turner leaves the room
[04:49:03] Marco Davids joins the room
[04:59:13] Satoru Kanno leaves the room
[05:01:32] richard.barnes joins the room
[05:01:45] richard.barnes leaves the room
[05:02:47] Shoichi Sakane joins the room
[05:03:05] Paul Hoffman leaves the room
[05:04:51] stpeter joins the room
[05:05:08] stpeter leaves the room
[05:06:06] Shoichi Sakane leaves the room
[05:06:53] Shoichi Sakane joins the room
[05:10:58] Melinda joins the room
[05:11:22] Melinda leaves the room
[05:20:06] Shoichi Sakane leaves the room
[05:20:51] Marco Davids leaves the room
[05:29:25] russmundy@jabber.org joins the room
[05:41:06] russmundy@jabber.org leaves the room
[05:54:35] EKR leaves the room
[05:55:23] EKR joins the room
[11:49:52] EKR leaves the room
[13:43:49] naptee joins the room
[13:46:34] naptee leaves the room
[16:26:54] EKR joins the room
[19:17:05] EKR leaves the room