IETF
dane@jabber.ietf.org
Friday, 29 July 2011< ^ >
Room Configuration

GMT+0
[03:21:11] Warren Kumari joins the room
[03:42:36] Warren Kumari leaves the room
[12:59:25] Warren Kumari joins the room
[13:01:50] Warren Kumari leaves the room: Replaced by new connection
[13:01:51] Warren Kumari joins the room
[13:54:16] Warren Kumari leaves the room
[13:57:30] Warren Kumari joins the room
[14:04:35] Warren Kumari leaves the room
[14:14:13] Warren Kumari joins the room
[14:18:52] Warren Kumari leaves the room
[14:43:32] Warren Kumari joins the room
[14:58:50] Warren Kumari leaves the room
[15:17:02] Warren Kumari joins the room
[15:17:42] Warren Kumari leaves the room
[15:56:18] Warren Kumari joins the room
[15:56:48] Warren Kumari leaves the room
[16:19:10] jakob joins the room
[16:40:09] Warren Kumari joins the room
[16:52:23] jakob leaves the room
[16:54:46] doug.otis joins the room
[16:56:54] paulwouters joins the room
[16:56:54] paulwouters leaves the room
[16:57:01] paulwouters joins the room
[16:57:14] steffi joins the room
[16:57:41] ondrej joins the room
[16:57:41] ondrej leaves the room
[16:57:42] ondrej joins the room
[16:57:57] wouter joins the room
[16:58:09] spturner joins the room
[16:58:30] David Cooper joins the room
[16:58:40] mlepinski joins the room
[16:58:49] Francisco Arias joins the room
[16:58:56] hardaker joins the room
[16:58:58] semery joins the room
[16:59:07] jakob joins the room
[16:59:32] <paulwouters> warren: it is close enough to 3pm to start
[16:59:34] <paulwouters> [laughter]
[16:59:55] fdupont joins the room
[17:00:01] SFTCD joins the room
[17:00:12] <paulwouters> note well..... read it
[17:00:27] <paulwouters> blue sheets. please use
[17:00:55] paulwouters leaves the room
[17:01:00] paulwouters joins the room
[17:01:07] <paulwouters> warren: agenda bashing.....
[17:01:11] <paulwouters> status update:
[17:01:27] <paulwouters> use case document, richard will speak about it
[17:01:39] <paulwouters> chair option: protocol is close to fully baked
[17:02:03] sschmit joins the room
[17:02:07] <paulwouters> warren apologises of being side tracked
[17:02:41] hbhotz joins the room
[17:02:54] paulwouters leaves the room
[17:03:12] jimsch1 joins the room
[17:03:26] paulwouters joins the room
[17:03:39] <paulwouters> Peter:
[17:03:44] <paulwouters> uhm richard
[17:03:53] <paulwouters> second WGLC was silent
[17:03:55] Benno Overeinder joins the room
[17:04:04] <paulwouters> IETF LC began july 5
[17:04:10] Hugo Kobayashi joins the room
[17:04:17] <paulwouters> version -05 is all editorial
[17:04:29] <paulwouters> quick review
[17:04:44] <paulwouters> 1 CA contraints
[17:05:10] <paulwouters> overall idea is giving information about certificates in the DNS
[17:05:21] <paulwouters> different types of advise
[17:05:27] <paulwouters> ca constraints
[17:05:31] mrex joins the room
[17:05:33] <paulwouters> guard against misissue
[17:06:05] <paulwouters> CA specified in the dane record must be in certification path
[17:06:20] <paulwouters> 2. service certificate constraints.
[17:06:29] <paulwouters> meaning constraining the certificate used
[17:06:34] =JeffH joins the room
[17:06:59] <paulwouters> also named "ca lock" and "cert lock" by ekr
[17:07:16] <paulwouters> 3. trust anchor assertion / domain issued certificates
[17:07:32] <paulwouters> "trust this CA for my domain"
[17:08:18] <paulwouters> 4. delegated services.
[17:08:37] <paulwouters> how do the above 3 map to an outsourcing service
[17:08:55] barryleiba joins the room
[17:09:14] <paulwouters> jim schaad suggested more detailed tet on delegated service sc enarios
[17:09:39] <paulwouters> question to WG: do we want this in the use cases document. or in the protocol document?
[17:10:01] <paulwouters> jim schaad:
[17:10:11] <paulwouters> I was assumping this in a operations document.
[17:10:36] Satoru Kanno joins the room
[17:10:36] <paulwouters> paul hoffman: put it in protocol document is not appropriate for operation things
[17:10:43] <paulwouters> paul we can come up with operationals document
[17:10:53] <paulwouters> we havent thought about it.
[17:11:10] jinmei joins the room
[17:11:11] <paulwouters> warren: it has been mentioned. we haven't picked it up
[17:11:37] <paulwouters> next item
[17:11:53] <paulwouters> dnssec serialization: a dane review
[17:11:57] <paulwouters> by paul hoffman
[17:12:17] <paulwouters> a more generic version of what was shown yesterday in TLS WG
[17:12:35] <paulwouters> this is not related to dane specifically. it is here because the discussion came up first on dane WL
[17:12:53] <paulwouters> there is no home yet for serialization, hence talking at TLS and here at dane
[17:13:24] <paulwouters> take dnssec information, stick them in a blob, someone who can verify does not have to get each record.
[17:13:33] <paulwouters> how will it look like
[17:13:41] <paulwouters> how can we get a blob into a security protocol
[17:13:49] <paulwouters> how might it proceed in IETF
[17:13:58] <paulwouters> paul did not write the idea. started with kaminsky and Langly
[17:14:24] <paulwouters> jeff hodges says: they have code
[17:14:33] PHB joins the room
[17:14:38] <paulwouters> paulh: code they have is not compatible iwth the draft
[17:14:52] <paulwouters> kaminsky pushed this. hence we're talking baout it now. idea is not new
[17:15:16] <paulwouters> dnssec blob is much faster to separate dns lookups
[17:15:23] <paulwouters> s/to/than
[17:15:42] <paulwouters> if you can get it within the protocol (like tls) then you dont even have to do a new conneciton
[17:15:56] <paulwouters> some clients cannot get dnssec via traditional dns. eg broken middleware boxes
[17:16:08] <paulwouters> getting the blob allows you to get the dnssec info
[17:16:09] rstory joins the room
[17:16:15] Francisco Arias leaves the room
[17:16:19] <paulwouters> validation is in the client
[17:16:24] <paulwouters> they dont need to be a resolver
[17:16:44] spturner leaves the room
[17:16:51] <paulwouters> steve kent bbn
[17:17:07] PHB leaves the room
[17:17:13] <paulwouters> if the client cannot get dnssec at all, they need the root and/or any updates to it
[17:17:22] <paulwouters> paulh: yes, they will need the trust anchor.
[17:17:32] <paulwouters> paulh: similar to CA trust anchor pile
[17:18:07] <mrex> A Server that uses DNSSEC to confirm his identity/authority should be in the very best position to obtain all the necessary DNSSEC records for its very own name -- serialize it and send it along in-band with a communication potocol
[17:19:01] <paulwouters> steve: client had a root, there is automated procedure for update. if you dont have reliable name, it might not be useful if it missed the root update
[17:19:05] <paulwouters> paulh: yes.
[17:19:07] <mrex> The client must have a current DNS root key, of course.
[17:19:39] <hardaker> mrex: if you want that relayed to the mic, let me know.
[17:19:40] <paulwouters> phil halam baker: there is an easier way...
[17:19:43] matthijs joins the room
[17:19:59] <paulwouters> it is already baked into browsers with trust ca's , update mechanisms, etc
[17:20:07] <paulwouters> paulh: stop think of it as general, like ssh, not tls
[17:20:19] <paulwouters> phb: this becomes a requirement.
[17:20:29] <mrex> We could try tunneling the last root key roll-over along with the serialized DNSSEC records for the server
[17:20:32] <paulwouters> phb: root rollover is only going to be one method. there will be others
[17:21:07] <paulwouters> phb: if you look for CAA....the dnssec rollover is not going to help you because of lacking history.......
[17:21:13] <paulwouters> speaker name missed]
[17:21:22] PHB joins the room
[17:21:24] <paulwouters> how do you maintain root key
[17:21:33] <rstory> erik someone..
[17:21:42] <paulwouters> a dnssec validator is now a browser. how can they maintain track of root rollover
[17:21:47] <hardaker> mrex: there is a protocol document in dnsext to do that sort of thing, actually, and likely would be tied to this in the future once it's done. But you probably knew that.
[17:21:53] <paulwouters> this is dane or dns WG issue
[17:22:10] <PHB> Nope: the browsers using this will simply hook into their trust anchor management system
[17:22:18] <mrex> (no, i didn't know)
[17:22:21] <paulwouters> browser should not replicate functionality
[17:22:28] <PHB> Nobody is going to be chaining their application up to the ICANN roll over direct
[17:22:33] <PHB> They would be fools to
[17:22:57] <paulwouters> where the validation happens is also a big deal
[17:23:03] Jim Galvin joins the room
[17:23:14] <paulwouters> paulh: exactly. we have one internet draft, skips over many of the topics we talked about.
[17:23:23] <paulwouters> paulh: we are not talking about that collection
[17:23:34] <paulwouters> ondrey: for dane we have something about securing the last hop later
[17:23:58] <mrex> there is no principal problem that a DANE client passes along the received serialized DNSSEC records to a DNSSEC resolver (instead of a lookup request) for verification
[17:24:14] <=JeffH> Eric Osterweil ??
[17:24:19] <paulwouters> serialising and capturing dnssec and freezing is, lends itself to staleness, and leads to vulnerabilities
[17:24:28] dhiva joins the room
[17:24:29] <paulwouters> paulh: is being addressed on the list. we are talking about it
[17:25:00] <=JeffH> Eric Osterweil -- yes
[17:25:04] <mrex> there is no staleness. The validity with respect to security(!) is governed by the RRSIG validity exclusively
[17:25:09] <paulwouters> back to slides.. paul talks.
[17:25:14] <paulwouters> what will the blob look like ?
[17:25:17] Karen O'Donoghue joins the room
[17:25:24] john.levine joins the room
[17:25:27] dhiva is now known as Dhiva.M
[17:25:27] <mrex> DNS TTL are only a convenience feature to control caching characteristics
[17:25:28] paulwouters leaves the room
[17:25:29] <PHB> I want to rais EKR's point about positive and negative trust assertions
[17:25:44] Dhiva.M leaves the room
[17:25:44] <PHB> Willing to wait, but want to raise it
[17:25:44] paulwouters joins the room
[17:25:44] matthijs leaves the room
[17:25:57] <paulwouters> draft adam wrote is just for the blob
[17:26:12] <paulwouters> we are not saying this is the blob. or the code is already a done deal.
[17:26:29] <paulwouters> this is not that important what teh shape of the blob is (yet)
[17:26:38] matthijs joins the room
[17:26:39] <paulwouters> getting the blob into the securty protocol to the client
[17:26:47] <paulwouters> paulh: these are the ones i have seen so faar
[17:26:53] <mrex> having the DNSSEC library implementors / vendors review he serialization proposal would be helpful
[17:26:56] <paulwouters> - new extenion
[17:26:59] <paulwouters> - new pkix extension
[17:27:07] <paulwouters> new pkix extension in superfluous cert
[17:27:11] <paulwouters> new ocsp extension in ocsp message
[17:27:16] <paulwouters> do another request (dns/HTTP)
[17:27:26] <mrex> since we will probably want them to offer APIs to process them
[17:27:36] <paulwouters> TLS and IPsec could use this
[17:27:48] <paulwouters> (this being an extensiuon to native protocol)
[17:28:03] <paulwouters> same for pkix type protocols by using a bloc in there
[17:28:23] <paulwouters> superfluous certificate (one that is not in a chain) could be used as carrier
[17:28:40] <paulwouters> ocsp could be used
[17:28:52] <mrex> exactly, TLS is _NOT_ one of the protocols that allows you to stuff arbitrary certs into the standard Certificate handshake message
[17:29:14] <paulwouters> do another request yourself outside the protocol. where you say "give me the blob" via dns or http.
[17:29:19] <paulwouters> you might get it from your dhcp server
[17:29:28] <paulwouters> it might not be in the protocol you are doing at the time
[17:29:34] leifj joins the room
[17:29:52] <paulwouters> there might be new ones. different ones. the idea is get the blob to the client. so the client can do the validation
[17:29:59] <paulwouters> btw: none of these have to be secure.
[17:30:05] <mrex> (but a TLS extension could negotiate to modify these semantics)
[17:30:06] <paulwouters> you might get invalid data.
[17:30:07] john.levine leaves the room
[17:30:22] <paulwouters> if the ietf wants to persue this, we want to standarise the blob
[17:30:36] <paulwouters> need to decide on mechanism in each security protocol
[17:30:43] <paulwouters> i believe they should be done separately
[17:30:49] john.levine joins the room
[17:31:01] <leifj> wait I saw OCSP - wasn't the point of this exercise to get rid of a runtime dependency on revocation?
[17:31:11] PHB leaves the room
[17:31:18] <paulwouters> leifj: want that mic'ed ?
[17:31:25] <leifj> naw I'll stand up
[17:31:27] <paulwouters> peter koch: I am confused.
[17:31:31] <paulwouters> (oh :)
[17:31:49] <mrex> the commercial CAs certainly want OCSP to continue being used (it is part of their value proposition)
[17:31:51] <paulwouters> peter: dnssec which is a mechanism to secure transport of dns.
[17:31:54] <paulwouters> paulh: is not
[17:32:05] <paulwouters> peter: it is not protecting the data.. does not give assurances about the data
[17:32:10] <paulwouters> paul: assurance about origin
[17:32:27] <paulwouters> peter: you are emulating in the blob the protection for teh data, had it been done via dns, would not have been changed.
[17:32:47] <paulwouters> peter: it will be operaitonal nightmare on timeouts, staleness,. TTL values. key rollovers ,etc
[17:32:54] Suzanne joins the room
[17:33:02] <paulwouters> taking a snapshot into a blob and have people use an old emulation
[17:33:08] <paulwouters> peter: its cool, but it is wrong
[17:33:25] <paulwouters> paul: when you serialise, you sould re-serialise at the shortest length of the minimum TTL
[17:33:36] <mrex> but tunneling serialized DNSSEC records within an OCSP extension would provide and easy independent upgrade path and could be abused to make OCSP look more attractive (deceive about its serious privcay and robustness issues when OCSP is performed by the RP)
[17:33:39] <paulwouters> paul: it will be as fresh as someone who had done it mechanically up and down
[17:33:43] <paulwouters> paul: speed is a reason to do this
[17:33:51] <paulwouters> single hop.
[17:34:09] <paulwouters> peter: is that a real world operation option
[17:34:11] <paulwouters> [many]: yes
[17:34:50] <paulwouters> paul: browser vendors said getting dnssec info in one shot is a use case
[17:35:03] <SFTCD> why is this coming before the WG documents?
[17:35:05] <paulwouters> peter: if you dont like dns with all its side effects, then maybe it is the wrong transport to use
[17:35:29] <paulwouters> warren: i see this as a transition mechanism. you poke the dns, and you get it back quickly and with dnssec protection
[17:35:45] <paulwouters> peter: I am not enthousist
[17:36:02] <paulwouters> phb: adams work was based on a survey. that 2% did not get through
[17:36:24] <paulwouters> if people are going to use anything. it has to work 100% on that client. or else they are going to switch. or get idiot boxes or they stop using it
[17:36:25] <mrex> the environments where non-access to the Internet DNS universe are the real problem (the buggy ones could get fixed eventually). There might be a non-marginal number of closed internal networks with private DNS universes that access the internet through HTTP CONNECT proxies exclusively
[17:36:52] <paulwouters> phb: if you get pickled information you only get positive trust. you do not get the restrictive assertions
[17:37:14] <paulwouters> paulh: assurtions are from elsewhere. dnssec just preotects those assertions
[17:37:33] <paulwouters> [discussion goes on. cut off]
[17:38:08] <paulwouters> phb: negative/positive assertions should be seperated.
[17:38:25] PHB joins the room
[17:38:28] <paulwouters> eric oysterwell[?]
[17:38:46] <leifj> in the interest of time I'm standing down from the mic
[17:38:47] <paulwouters> one shot idea. that is optimization issue. should look at correctness first
[17:38:58] naptee joins the room
[17:39:09] <barryleiba> That's "Huître-weil" in Québec.
[17:39:43] <paulwouters> if you want to press this elsewhere. how much new code does that take.... [examples]
[17:39:54] <paulwouters> warren: let's save this discussion for later
[17:40:40] <paulwouters> eric: meassurement of failure on dnssec data. if catering 1.5% causes an introduciton of an attack vector, that is not good
[17:40:53] <paulwouters> paulh: adam says, if there is that problem. we'd throw it off the table
[17:40:56] PHB leaves the room
[17:41:10] <paulwouters> warren: i asked paul to present this. it is related to dane and discussion on the list
[17:41:21] <paulwouters> phb: resolving alisaes and wildcards
[17:41:48] <paulwouters> problem #1: info that goes beyond simple map. things become complicated
[17:41:57] <paulwouters> name,qtype -> properties
[17:42:01] Jacky Yao11 (Health Yao) joins the room
[17:42:10] <paulwouters> nothing for "give me blue record with green decorations for domain X"
[17:42:26] <paulwouters> specific port and protocol questions have to go through hoops
[17:42:37] <paulwouters> solution: use prefix
[17:42:43] <paulwouters> then you have a new dns name
[17:42:51] <paulwouters> problem: it doesnot quite work
[17:43:08] <paulwouters> dns does not know that prefix is a subclass of this other name. sees it as a seperate delegation
[17:43:13] <paulwouters> wildcards break
[17:43:18] <paulwouters> aliases break
[17:43:24] <paulwouters> wildcard example
[17:43:31] <paulwouters> *.example.com DANE foo
[17:43:35] <paulwouters> will match all port numbers
[17:43:59] matthijs leaves the room
[17:44:00] <paulwouters> you cannot sign prefix.*.example.com
[17:44:15] <jakob> fwiw, "*.example.com DANE fooo" will match all port numbers for all protocols.
[17:44:47] <mrex> If an attacker succeeds at suppressing the DNSSEC serialized data, then that open _NO_NEW_ attack vector. Keep in mind, we do not have DANE now! The worst that can happen is that DANE negative assertions will not be available. This is _not_ a new vulnerability. Just a situation where DANE does not provide protection yet .
[17:44:50] josephyee joins the room
[17:44:52] matthijs joins the room
[17:45:06] <paulwouters> workarounds: no wildcards.
[17:45:22] <paulwouters> decoarate right hand side with prefix data
[17:45:23] <mrex> Possible Mitigations might be that the browser memorizes DANE info availability per server, similar as it might memorize EV-cert availability
[17:45:30] <paulwouters> Alias Consequences
[17:45:40] <paulwouters> www.example.ccom <http://www.example.ccom> CNAME example.com
[17:45:55] mkatagi joins the room
[17:45:59] <paulwouters> maps web service to example.com.
[17:46:23] g.e.montenegro joins the room
[17:46:25] <paulwouters> outsources services would require modifying dns records for those services. value of the alias has been lost
[17:46:36] <paulwouters> - dont use wildcards
[17:46:44] <paulwouters> - tell admin toe generate a CNAME for each prefix.
[17:46:53] <paulwouters> loses point of using prefix
[17:46:56] <mrex> the currently describe use of CNAMEs frightens me
[17:47:04] <paulwouters> solution:
[17:47:10] <mrex> to me it looks like a real security problem
[17:47:14] <paulwouters> resolver looks for prefix at canonical name
[17:47:27] <paulwouters> you want to talk to you pull an A/AAAA record
[17:47:45] <paulwouters> in parallel: dane record request
[17:47:47] mlepinski leaves the room
[17:47:55] <paulwouters> if name was canonical, all fine.
[17:47:56] <mrex> and it completely changes the security model from pre-DANE, where the reference name that the TLS client will check against is ALWAYS the original hostname
[17:48:19] <paulwouters> if you have an alias, dane is two round trips
[17:48:51] <paulwouters> [my own comment: maybe we should use a serialblob ]
[17:48:52] <paulwouters> :)
[17:49:00] <paulwouters> phb: optimization:
[17:49:07] <paulwouters> auth server can anticipate this need
[17:49:17] <paulwouters> if name record for _prefix.X fails
[17:49:23] <paulwouters> - look to see if X has a CNAME
[17:49:34] <paulwouters> - return _prefix for alias record as additional record
[17:49:46] <mrex> in the pre-dane area, when you outsource your web-server to a hosting service, you must authorize the hosting service to purchase SSL server certificates for your DNS name from commercial CAs.
[17:49:48] <paulwouters> then its a single round trip resolution in all cases
[17:49:55] mlepinski joins the room
[17:50:05] <paulwouters> open issue:
[17:50:09] <paulwouters> what to do in case we have
[17:50:17] <paulwouters> x.example.com CNAME y.example.com
[17:50:26] <paulwouters> _prefix.x.example.com DANE nblah
[17:50:35] <paulwouters> _prefix.y.example.com DANE blurgh
[17:50:39] <paulwouters> shoudlwe use record x or y
[17:50:47] <paulwouters> Next steps
[17:51:01] matthijs leaves the room
[17:51:05] <paulwouters> phb to do write up of scheme. add to draft if agreed this is solution
[17:51:13] <paulwouters> propose to dnsext as fix to SRC/UTI
[17:51:15] <mrex> if DANE tries to make this step magically disapper, it opens a gap in the security model (and one that is unexpected by the clients)
[17:51:20] <paulwouters> if approach is generic, can be made infrastructure
[17:51:27] <jakob> FOR MICROPHONE: DNS stub resolver libraries will (as of today) not expose if a resulting A/AAAA is at the end of a CNAME chain, or a "direct" response. IMHO, we should not design a solution that requires clients to use something more complex than plain old gethostbyname() / getaddrinfo() / getrrsetbyname(). CNAMEs are internal to the DNS resolution, not very useful as part of the answer.
[17:51:53] matthijs joins the room
[17:52:04] <sschmit> I've looked at the text
[17:52:12] <hardaker> Who's read the most recent?
[17:52:14] <hardaker> (which came out Monday)
[17:52:17] <hardaker> answer: roughly 2
[17:52:27] <hardaker> chiar: this is a generic problem
[17:52:41] <hardaker> not just a dane issue, and it's a really uesful thing to solve.
[17:52:49] <hardaker> probably once in dnsext and it seems like the correct solution.
[17:53:00] <hardaker> if that solution is formed, we can update this.
[17:53:23] <hardaker> (reading above jabber comment)
[17:53:36] Roque Gagliano joins the room
[17:53:49] <hardaker> phb: having implmenetd dane in C# recently, libraries have gethostbyname and nothing else.
[17:54:10] <hardaker> you can't write code in C# or whatever without using some library that gives you access to the records
[17:54:11] <=JeffH> what's the filename of "the latest" ?
[17:54:19] <hardaker> you have to go beyond existing api
[17:54:35] <hardaker> jeffh: probably -09
[17:54:35] <=JeffH> is Jakob "jakob schlyter" ?
[17:54:42] <paulwouters> jeffh:yes
[17:54:42] <jakob> yes.
[17:54:44] <sschmit> forget that, you have to get the TLSA record, which gethostbyname won't do
[17:54:54] <mrex> The current security model of DANE was that you have to verify the DNSSEC signature on the TLSA records
[17:55:04] <jakob> sschmit; getrrsetbyname() does.
[17:55:07] <hardaker> phb: what are we going to do in the mean time
[17:55:10] <leifj> jakob: say if you want mor channelling
[17:55:13] <hardaker> chair: it's in the -09 draft already.
[17:55:18] <=JeffH> ok, folks are referring to draft-ietf-dane-protocol-09 (appendix A)
[17:55:29] <hardaker> paul: did yo read the new draft
[17:55:34] <hardaker> phb: I haven't seen it.
[17:55:55] <mrex> now what about DNSSEC on the chain of CNAME records that the most recent proposal suggests to chase down first?
[17:56:06] <hardaker> phb: I said ahead of time I'd speak on it.
[17:56:22] <hardaker> phb: there is a cut off.
[17:56:27] <hardaker> chair: lets discuss on list then
[17:56:37] <hardaker> phb: rants on
[17:57:16] <hardaker> phb: throws mic on the floor. sorry to those that heard the loud bumps
[17:57:21] PHB joins the room
[17:57:37] <leifj> that was "fun"
[17:57:59] matthijs leaves the room
[17:58:00] <hardaker> going on to "on the wire security"
[17:58:01] <=JeffH> http://www.ietf.org/proceedings/81/slides/dane-3.pdf
[17:58:15] <=JeffH> Securing the Last Hop
Ondrej Sury
IETF 81,
[17:58:34] matthijs joins the room
[17:59:09] <paulwouters> can you trust the resolver or not
[17:59:09] <SFTCD> rfc3655 is obsoleted by 4033-4035 so it says
[17:59:26] <paulwouters> we all know there are problems with dhcp
[17:59:35] <paulwouters> third part is the APIs
[17:59:48] <mrex> the idea behind DANE is to obviate the CA and put the DNS Domain Admin in the position to confirm assertions about hosts in his zone (rather than have the CA ask or rely on the DNS Admin to do this and have the CA confirm that the DNS Admin wanted what the CA certified)
[17:59:56] <paulwouters> getaddrinfo() is just used for ip and port. not info on security or AD bit
[18:00:08] <paulwouters> questions for WG: is there a problem to solve ?
[18:00:14] <paulwouters> is this in the scope of dane?
[18:00:22] <paulwouters> or we do just say it needs fixing (elsewhere)
[18:00:34] <paulwouters> dnsext?
[18:00:37] <paulwouters> new working group?
[18:00:58] <paulwouters> wire security vs trust? is it 2 problems or 1
[18:00:58] <rstory> there is an existing draft for an updated api that includes dnssec information
[18:01:08] <paulwouters> list of options to secure things
[18:01:24] <paulwouters> rstory : want that channeled? got more info?
[18:01:50] <mrex> when you want to oursource your web-server, you either have to outsource your entire DNS Domain along with it, or you (as the DNS Admin) have to process the requests from the hosting service to add assertions to the DNS zone, similar how in traditional TLS a commercial CA has to process the requests from the hosting service to issue TLS server certificates
[18:01:52] <paulwouters> lars lieman, netnode [?]
[18:01:56] <rstory> http://www.ietf.org/id/draft-hayatnagarkar-dnsext-validator-api-08.txt
[18:02:10] <paulwouters> you are trying to dotch operation problems by creating hacks in the protocol
[18:02:23] <paulwouters> which mechanisms arent already designed and in place
[18:02:29] <paulwouters> we cannot get to the information in the network
[18:02:46] <paulwouters> an operator is preventing you to get the information. choose another one
[18:03:11] <paulwouters> ondrey: let me clarify. I am not trying to creating X and then address it
[18:03:13] PHB leaves the room
[18:03:23] <paulwouters> ondrey: i think we should address this somehow. there is a problem..
[18:03:39] <paulwouters> warren: not related to this. I want to apologise to phb.
[18:03:58] <paulwouters> wes hardaker
[18:04:10] <paulwouters> we have to (ati)luxury for being at the forefront of using dnssec
[18:04:14] <leifj> kudos to Warren
[18:04:15] <paulwouters> we are coming up on a huge number of issues
[18:04:27] <paulwouters> all these slides have nothing to do with dane. and are out of scope of the charter
[18:04:30] <paulwouters> where to tackle these
[18:04:38] <paulwouters> some are actively being worked on
[18:04:39] matthijs leaves the room
[18:04:51] <paulwouters> for the api issue there is a dnssec compliant api on the way
[18:04:56] matthijs joins the room
[18:04:58] spturner joins the room
[18:05:03] <paulwouters> suggestion for moving forward, we should really only work on the ones that are showstoppers for dane
[18:05:07] <paulwouters> a lot of these are not.
[18:05:16] <paulwouters> bad operation environemtn is nothing we can do about
[18:05:39] <paulwouters> i have a tool to check operational issues. and all networks have at least one red dot
[18:05:56] <paulwouters> we need to pick the ones that prevent us from writing a spec working for dane
[18:06:05] <paulwouters> lets get the protocol and acharter done first
[18:06:24] <paulwouters> phb speaking. I agree. if people are using this it has to be practical. and work in high degree of validity
[18:06:48] <paulwouters> we can connect people with dns over our proprietary system
[18:06:58] <paulwouters> we should extend that to an open standard
[18:07:10] <paulwouters> in my view, the pki part of this is easy. we have already done it 20 years ago
[18:07:32] <paulwouters> if all dane is offers 95% key certification. why would people use it
[18:07:43] <paulwouters> warren: we are working on many interesting things
[18:07:49] <paulwouters> some of it is not in our charter
[18:07:51] PHB joins the room
[18:07:56] Dhiva.M joins the room
[18:08:22] <paulwouters> warren: we should push to fix companies and operational issues
[18:08:27] <paulwouters> [speaker name missed]
[18:08:43] <paulwouters> reads up charter
[18:09:06] <paulwouters> there is a description, but no intention
[18:09:21] <paulwouters> warren: we dont want to push it all out. we're not inventing the next dnssec here
[18:09:24] <paulwouters> peter koch
[18:09:33] <mrex> the captive portals in many WLANs probably filter, fake-before-login and might break DNSSEC lookups
[18:09:51] PHB leaves the room
[18:10:03] <paulwouters> it is very tempting we as the ietf should stop with acting stuff to protocol that increases operational complexity to work around operational issues
[18:10:26] <paulwouters> that said, the last mile may be a problem. i am more concerned about the first mile (provisioning)
[18:10:35] <paulwouters> nothing of this is dane specific
[18:10:42] <paulwouters> paul hoffman
[18:10:59] <paulwouters> i wish i could agree with peter. we are the first WG,
[18:11:02] matthijs leaves the room
[18:11:08] <paulwouters> if things are delivered insecurely, we decrease the security of the user
[18:11:15] <paulwouters> we didnt have security before
[18:11:17] matthijs joins the room
[18:11:26] <paulwouters> now we have. if the attacker can change the record, it reduces security.
[18:11:33] barryleiba leaves the room
[18:11:35] <paulwouters> we have a responsibility to list it.
[18:12:10] <paulwouters> it might bloc kthe protocol document. it is not part of the protocol, but we should prob wait to push the protocol forward until we can describe when we can run the protocol
[18:12:14] spturner leaves the room
[18:12:19] <paulwouters> phb: disagree with peter
[18:12:29] <paulwouters> i do not believe in end to end security
[18:12:39] <paulwouters> endpoints are people or organisation, not machines
[18:12:53] <paulwouters> i should not get dns through any middle box that i do not trust
[18:13:11] <paulwouters> ondrey: do you disagree it is not work for this WG?
[18:13:24] <paulwouters> phb: what IS the goal for this WG?
[18:13:30] barryleiba joins the room
[18:13:36] <paulwouters> what is the degree of support this WG has established
[18:13:41] <mrex> strongly disagree: trusting hostnames is the fallacy, not doing DNS without security !!
[18:13:43] <paulwouters> randy bush: can we do something useful here ?
[18:13:54] PHB joins the room
[18:14:08] <paulwouters> paul hoffman: would you like security consideration section for a protocol. or as a seperate document
[18:14:14] <paulwouters> randy bush: I dont care
[18:14:41] <mrex> I thought the commercial CAs inventend EV-Certs exactly because they themselves do not believe that trusting DNS hostname is sensible
[18:15:07] <paulwouters> mrex: i thought it was because humans were not to be trusted beyond recognising a green bar
[18:15:21] <jakob> mrex; they invented EV 'cause their existing identity proofing was toast.
[18:15:23] <mrex> but maybe I'm completely mistaken and they are just doing it to rake in more money
[18:15:42] <barryleiba> mrex: Indeed, on the last.
[18:15:51] <paulwouters> paulh: we have a few words that say the transport should be secure
[18:15:59] <paulwouters> that it came from dnssec
[18:16:05] <jakob> In order to use one or more TLS certificate associations described in
this document obtained from the DNS, an application MUST assure that
the certificates were obtained using DNS protected by DNSSEC. TLSA
records must only be trusted if they were obtained from a trusted
source. This could be a localhost DNS resolver answer with the AD
bit set, an inline validating resolver library primed with the proper
trust anchors, or obtained from a remote nameserver to which one has
a secured channel of communication.
[18:16:25] <jakob> (that was a quite from the protocol draft)
[18:16:39] <barryleiba> Quite a quote.
[18:16:39] <paulwouters> paulh: do we want a section on the last hop? on the operation?
[18:16:55] <paulwouters> paulh: we are happyt to put it in, or have a new document. we dont wantto write it ourselves
[18:17:10] <paulwouters> paulh: i hear people want more not less, we did less on purpose
[18:17:19] <paulwouters> wes: seperate document so we can mark it historic
[18:17:23] matthijs leaves the room
[18:17:30] <paulwouters> next item
[18:17:33] <paulwouters> DANE future work
[18:17:42] fujiwara joins the room
[18:17:42] spturner joins the room
[18:17:43] <paulwouters> possible item list
[18:17:44] matthijs joins the room
[18:17:44] sandoche leaves the room
[18:18:26] <paulwouters> should we review IPSECKEY or redo with dane for ipsec
[18:18:32] <paulwouters> dane for smime
[18:19:05] <paulwouters> warren: what else, if anything should we do
[18:19:14] spturner leaves the room
[18:19:38] <mrex> dane for smime looks strange because I believe that neither expecting nor requireing every person to obtain a personal DNS domain is a worthwile or reasonable goal
[18:19:39] <paulwouters> warren: open issues are not major on protocol document
[18:19:45] spturner joins the room
[18:20:00] <paulwouters> warren: no face to face talk scheduled/needed for that.
[18:20:11] <paulwouters> ondrey: open issues were cname and last hop. we talked about those
[18:20:21] <jakob> mrex; DANE for S/MIME assumes that the entity handling your MX DNS can also assist in publishing your security goo.
[18:20:44] spturner leaves the room
[18:21:06] <hardaker> paulwouters: I want to wait till dane protocol is finished
[18:21:16] <mrex> no, DANE implies that your become your own CA-equivalent by becoming a DNSSEC domain admin.
[18:21:16] <hardaker> otherwise we'll just run into similar issues in the other places.
[18:21:36] Karen O'Donoghue leaves the room
[18:21:37] <hardaker> sean: Yes, I want why ou to look at the smime and other stuff. but there is nothingwrong with sleeping for 6 months first.
[18:21:50] <hardaker> chairs: fighting over open-mic
[18:22:05] PHB leaves the room
[18:22:05] barryleiba leaves the room
[18:22:07] <hardaker> chairs: done!
[18:22:13] jimsch1 leaves the room
[18:22:20] SFTCD leaves the room
[18:22:23] mlepinski leaves the room
[18:22:24] steffi leaves the room
[18:22:36] Warren Kumari leaves the room
[18:22:43] jakob leaves the room
[18:22:53] hbhotz leaves the room
[18:22:55] mrex leaves the room
[18:23:06] David Cooper leaves the room
[18:23:11] john.levine leaves the room
[18:23:21] jinmei leaves the room
[18:23:24] wouter leaves the room
[18:23:31] ondrej leaves the room
[18:23:37] mkatagi leaves the room
[18:23:42] Dhiva.M is now known as dhiva@es.net
[18:23:44] dhiva@es.net leaves the room
[18:24:12] =JeffH leaves the room
[18:24:22] naptee leaves the room
[18:25:56] sschmit leaves the room
[18:26:29] Satoru Kanno leaves the room
[18:26:39] matthijs leaves the room
[18:27:20] Suzanne leaves the room
[18:27:25] Hugo Kobayashi leaves the room
[18:28:09] jinmei joins the room
[18:28:12] paulwouters leaves the room
[18:29:47] jinmei leaves the room
[18:31:01] semery leaves the room
[18:31:53] g.e.montenegro leaves the room
[18:32:32] fdupont leaves the room: Computer went to sleep
[18:34:44] Jacky Yao11 (Health Yao) leaves the room
[18:39:46] rstory leaves the room
[18:41:02] Warren Kumari joins the room
[18:41:16] Roque Gagliano leaves the room
[18:42:19] leifj leaves the room
[18:42:26] Warren Kumari leaves the room
[18:42:50] hardaker leaves the room: Replaced by new connection
[18:42:51] hardaker joins the room
[18:48:12] Karen O'Donoghue joins the room
[18:55:15] Benno Overeinder leaves the room
[18:55:17] Benno Overeinder joins the room
[18:55:47] Benno Overeinder leaves the room
[19:05:39] Benno Overeinder joins the room
[19:12:21] Benno Overeinder leaves the room
[19:17:05] hardaker leaves the room
[19:28:17] Jacky Yao11 (Health Yao) joins the room
[19:28:58] Jacky Yao11 (Health Yao) leaves the room
[19:33:55] Warren Kumari joins the room
[19:46:36] Warren Kumari leaves the room
[19:47:31] Warren Kumari joins the room
[19:48:15] Benno Overeinder joins the room
[19:48:31] Benno Overeinder leaves the room
[20:23:29] doug.otis leaves the room
[20:37:33] Karen O'Donoghue leaves the room
[20:38:14] Warren Kumari leaves the room
[20:39:00] Jim Galvin leaves the room
[20:39:10] josephyee leaves the room
[20:55:46] Warren Kumari joins the room
[20:56:49] Warren Kumari leaves the room
[21:56:06] Warren Kumari joins the room
[22:02:47] Warren Kumari leaves the room
[23:19:43] hardaker joins the room
[23:47:32] hardaker leaves the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!