IETF
httpbis
httpbis@jabber.ietf.org
Tuesday, July 17, 2018< ^ >
mcmanus has set the subject to: https://datatracker.ietf.org/meeting/100/materials/agenda-100-httpbis/ and slides https://datatracker.ietf.org/meeting/100/session/httpbis
Room Configuration
Room Occupants

GMT+0
[17:50:10] jyasskin joins the room
[17:51:23] jyasskin leaves the room
[18:58:42] nygren joins the room
[19:20:21] Yoshiro Yoneya joins the room
[19:29:51] nygren leaves the room
[19:39:24] Meetecho joins the room
[19:44:33] wWcDEEqm joins the room
[19:45:06] PENG QIAN joins the room
[19:45:07] Yoav Weiss joins the room
[19:45:07] Julian Reschke joins the room
[19:45:08] Lucas Pardue joins the room
[19:45:08] Lorenzo Miniero joins the room
[19:45:09] Dmitri Tikhonov joins the room
[19:45:09] Lutz Jacob joins the room
[19:45:10] Klaus Hartke joins the room
[19:45:10] Richard Bradbury joins the room
[19:47:17] Peter van Dijk joins the room
[19:48:19] Julian Reschke waves
[19:48:34] <Lucas Pardue> (Y)
[19:48:46] Martin Thomson joins the room
[19:48:59] Martin Thomson has set the subject to: https://datatracker.ietf.org/meeting/100/materials/agenda-102-httpbis/ and slides https://datatracker.ietf.org/meeting/102/session/httpbis
[19:49:34] Mike West joins the room
[19:50:35] nygren joins the room
[19:50:38] Katharine Daly joins the room
[19:50:41] frodek joins the room
[19:51:08] Aman Sharma joins the room
[19:51:43] PENG QIAN leaves the room
[19:52:49] <Lucas Pardue> ok by me
[19:53:10] Maxim Georgiev joins the room
[19:53:57] craigt joins the room
[19:54:02] ted.h joins the room
[19:54:17] Rolf E. Sonneveld joins the room
[19:55:45] 99rst joins the room
[19:56:00] wseltzer@jabber.org joins the room
[19:56:15] dk joins the room
[19:58:57] Roy Fielding joins the room
[19:59:20] g.e.montenegro joins the room
[20:01:50] Peter DeVries joins the room
[20:02:34] g.e.montenegro leaves the room
[20:03:06] <Julian Reschke> mic: we have a few core issues where we still discuss whether it should go into core or bcp56bis
[20:03:13] <Julian Reschke> mic: so agree with martin
[20:03:49] Peter DeVries leaves the room
[20:03:51] Peter DeVries joins the room
[20:04:17] g.e.montenegro joins the room
[20:04:55] afrind joins the room
[20:07:28] Peter DeVries leaves the room
[20:08:38] Louis Steinberg joins the room
[20:09:54] blassey joins the room
[20:09:54] ekr joins the room
[20:10:34] ekaterina joins the room
[20:12:37] Luca Niccolini joins the room
[20:14:44] Yoshiro Yoneya joins the room
[20:22:06] Dapeng Liu joins the room
[20:22:28] dk leaves the room
[20:22:54] dk joins the room
[20:23:32] dk leaves the room
[20:23:55] Jeffrey Yasskin joins the room
[20:24:17] ted.h leaves the room
[20:24:25] ted.h joins the room
[20:25:28] Yoshiro Yoneya leaves the room
[20:26:34] daniel mccarney joins the room
[20:27:02] ekaterina leaves the room
[20:28:15] afrind leaves the room: Stream reset by peer
[20:28:16] afrind joins the room
[20:31:06] <craigt> ...could they be required to come from the same trust path? e.g. same root/inter...
[20:31:55] <craigt> that would contain misuse to the sameissuer/policy?
[20:32:57] <Jeffrey Yasskin> @craigt: The biggest risk is from a stolen private key, which the trust path doesn't help with.
[20:33:00] ted.h leaves the room
[20:33:38] <Jeffrey Yasskin> (I tend to think that CT defends decently against misissued certs, although others could disagree.)
[20:34:02] <craigt> so then everything just said surrounding hashing against private key is also not useful?
[20:34:13] Louis Steinberg leaves the room
[20:34:53] afrind leaves the room: Stream closed by us: Replaced by new connection (conflict)
[20:34:53] afrind joins the room
[20:35:34] <Martin Thomson> my proposal: scope by issuer and let the CA manage the set of tags
[20:36:16] <Martin Thomson> I think that RIchard's proposal is even better
[20:36:25] <ekr> What is Richard’s proposal?
[20:37:19] <Martin Thomson> to include a domain name as the tag and require that the CA verify that the person requesting the certificate be authorized for that name in addition to the names in the cert
[20:37:56] <Martin Thomson> cdn.example might be what a cdn uses across all the certificates it gets, for instance
[20:38:10] <Jeffrey Yasskin> In which case, compromise of the tag's private key is a bigger deal, but maybe we trust CDNs to protect their keys better than random sites.
[20:38:10] ted.h joins the room
[20:41:42] <Martin Thomson> it makes compromise of the authorization harder- the attack requires that the attacker convince the CA that they own cdn.example
[20:42:14] daniel mccarney leaves the room
[20:42:38] <Julian Reschke> mic: also depends on what characters would be allowed in identifiers
[20:43:01] <Julian Reschke> (comma)
[20:43:28] ekr leaves the room
[20:45:19] Aman Sharma leaves the room
[20:46:24] Maxim Georgiev leaves the room
[20:47:48] =JeffH joins the room
[20:47:56] <Mike West> Working on it.
[20:50:34] ekr joins the room
[20:51:00] JoeHallCDT joins the room
[20:52:14] ted.h leaves the room
[20:52:54] Mike West leaves the room
[20:53:21] <Lucas Pardue> :(
[20:53:40] Yoshiro Yoneya joins the room
[20:53:56] ekr leaves the room
[21:01:19] Louis Steinberg joins the room
[21:01:43] ekr joins the room
[21:04:14] ilari.liusvaara joins the room
[21:04:26] ekr leaves the room
[21:07:48] ekr joins the room
[21:08:58] Yoshiro Yoneya leaves the room
[21:11:22] ekr leaves the room
[21:11:32] <craigt> aren't address literals still painful; is that an example case we should be using?
[21:12:24] <craigt> I had to remove my literals in alt-svc for nat64 nets
[21:13:33] Jeffrey Yasskin leaves the room
[21:15:06] Yoshiro Yoneya joins the room
[21:15:41] <JoeHallCDT> hot off the presses: US Senators Wyden and Rubio send a letter to Google and Amazon about domain fronting:
[21:15:41] <JoeHallCDT> https://www.wyden.senate.gov/imo/media/doc/Wyden%20Rubio%20Letter%20to%20Amazon%20+%20Alphabet%20re%20Domain%20Fronting%20Ban.pdf
[21:16:20] Jeffrey Yasskin joins the room
[21:17:54] Louis Steinberg leaves the room
[21:21:27] <nygren > I'm not convinced address literals is a good practice for ALTSVC dns records vs just using a name in the same bailiwick and sending the A/AAAA records as additionals.
[21:21:54] Marcus Dansarie joins the room
[21:22:48] Ned Freed joins the room
[21:22:49] <craigt> nygren : I reviewd the drafts and they're not used as examples...It's just the presentations...
[21:24:24] <Yoav Weiss> can one hum remotely? :)
[21:24:29] <JoeHallCDT> yes
[21:24:31] ekr joins the room
[21:24:41] <Lucas Pardue> hum for altsvc dns
[21:24:42] <JoeHallCDT> first hum: if you are interested in continuing discussion hum
[21:24:45] <nygren > yes, just put "hum" here.
[21:24:49] <Yoav Weiss> hum
[21:24:49] <JoeHallCDT> sni hum now
[21:24:50] <Yoav Weiss> hum
[21:26:19] <ekr> I don’t think that what Ben suggested about IPs works because there is going to be a lot of traffic to that IP which contains the server name in the clear, either in the clear SNI or TLS 1.2 certs
[21:26:27] <Lutz Jacob> hum for alt svc sni
[21:26:51] <ekr> So any passive inspector gets a fairly clear binding between the IP and the domain name
[21:27:29] Lutz Jacob leaves the room
[21:28:35] Dmitri Tikhonov leaves the room
[21:28:50] ted.h joins the room
[21:29:00] ekr leaves the room
[21:29:44] ekaterina joins the room
[21:29:53] Yoshiro Yoneya leaves the room
[21:30:43] <Roy Fielding> Broken configs is not a justification for new header fields that do the exact same thing, because they will eventually be configured brokenly as well.
[21:30:53] <99rst> +1
[21:31:04] <Peter van Dijk> which list is 'was posted on the list'?
[21:32:18] <Julian Reschke> +1
[21:33:46] <Roy Fielding> Via uses pseudonyms to address the privacy concern, already, and introducing another field that does the same thing in a less general way is lunacy.
[21:35:36] ekr joins the room
[21:36:01] <Roy Fielding> So, don't allow your customers to strip the Via header field inside the CDN
[21:38:27] <Julian Reschke> mic: I don't get why it's less likely that somebody strips the new header field (as opposed to Via)
[21:38:37] <Roy Fielding> [mic] Via already works. All you need to do is define a cdn-specific pseudonym and don't allow those to be removed by CDNs
[21:40:37] Marcus Dansarie leaves the room
[21:44:10] Ned Freed leaves the room
[21:47:35] Peter van Dijk leaves the room
[21:49:29] mnot joins the room
[21:53:28] Yoshiro Yoneya leaves the room
[21:55:53] <JoeHallCDT> man does not like cates
[21:59:07] afrind leaves the room: Stream reset by peer
[22:00:11] JoeHallCDT leaves the room
[22:02:55] afrind joins the room
[22:03:21] John Leddy joins the room
[22:03:26] <nygren > seems like this might belong more in QUIC than HTTPBIS if anything, especially due to the challenges around coupling quic-in-quic
[22:04:48] <Lucas Pardue> that's useful feedback, It would be useful to figure out opinion on trying to make things backwards compatible to HTTP/1.1 or if this can ride the wave of protocol evolution
[22:05:16] mnot shakes head
[22:05:35] Julian Reschke leaves the room
[22:05:37] Julian Reschke joins the room
[22:05:46] ekaterina leaves the room
[22:07:54] =JeffH leaves the room
[22:12:22] afrind leaves the room: Stream reset by peer
[22:14:44] afrind joins the room
[22:15:28] ekr leaves the room
[22:16:22] <Lucas Pardue> rfc 750 section 6.5.2 says An endpoint MUST NOT send a       PUSH_PROMISE frame if it receives this parameter set to a value of 0. Did the slides say that teh experiment still processed pushes even when disabled?
[22:16:54] <craigt> nothing in the room: ask when it gets to mic line
[22:16:56] <Martin Thomson> Lucas Pardue: Yeah, that's what he said
[22:17:18] <Martin Thomson> I imagine that what happened was that they wrote a patch to send the setting without adding code to reject PUSH_PROMISE
[22:18:00] <craigt> martin is (as usual) correct
[22:18:14] <craigt> slide 4
[22:18:22] <Lucas Pardue> but its a PROTOCOL_ERROR to do that, what implementations are ignoring the setting?
[22:18:53] <Martin Thomson> Brad claimed that implementations were correctly respecting the setting
[22:19:01] <Martin Thomson> they saw no PUSH_PROMISE frames if push was disabled
[22:19:25] Rolf E. Sonneveld leaves the room
[22:19:41] <Lucas Pardue> ack
[22:19:52] afrind leaves the room: Stream reset by peer
[22:20:10] g.e.montenegro leaves the room
[22:21:07] <Martin Thomson> it sounds like the methods that akamai were using were better than the push usage in the general population
[22:21:16] <Martin Thomson> though still a long way from ideal
[22:22:10] mnot leaves the room
[22:22:47] JoeHallCDT joins the room
[22:23:04] Lorenzo Miniero leaves the room
[22:23:14] JoeHallCDT leaves the room: Replaced by new connection
[22:23:14] JoeHallCDT joins the room
[22:23:28] wseltzer@jabber.org leaves the room
[22:23:43] JoeHallCDT leaves the room
[22:24:18] afrind joins the room
[22:24:47] <Yoav Weiss> one point which may result in the difference in data is that Akamai's data is first-view-only and Chrome's data includes repeat views
[22:25:20] <Yoav Weiss> and we *know* that repeat views need cache digests to be effective
[22:26:13] nygren leaves the room
[22:26:13] Martin Thomson leaves the room
[22:26:15] afrind leaves the room: Stream reset by peer
[22:26:15] blassey leaves the room: Disconnected: closed
[22:26:16] Katharine Daly leaves the room
[22:26:18] <Lucas Pardue> thanks for the data on push
[22:26:25] Yoav Weiss leaves the room
[22:27:15] Julian Reschke leaves the room
[22:27:17] Dapeng Liu leaves the room
[22:27:17] Roy Fielding leaves the room
[22:27:17] Klaus Hartke leaves the room
[22:27:17] Jeffrey Yasskin leaves the room
[22:27:17] John Leddy leaves the room
[22:27:17] Richard Bradbury leaves the room
[22:27:17] Lucas Pardue leaves the room
[22:27:17] Luca Niccolini leaves the room
[22:31:54] craigt leaves the room
[22:33:20] ted.h leaves the room
[22:33:28] frodek leaves the room
[22:35:12] mnot joins the room
[22:37:23] Meetecho leaves the room
[22:39:46] craigt joins the room
[22:43:17] ilari.liusvaara leaves the room
[22:44:40] afrind joins the room
[22:51:48] craigt leaves the room: Disconnected: Replaced by new connection
[22:51:48] craigt joins the room
[22:56:10] wWcDEEqm leaves the room
[22:58:58] mnot leaves the room
[22:59:03] craigt leaves the room
[22:59:05] craigt joins the room
[23:00:00] wseltzer joins the room
[23:00:28] wseltzer leaves the room
[23:04:20] afrind leaves the room: Stream reset by peer
[23:04:54] craigt leaves the room
[23:08:24] wseltzer joins the room
[23:12:28] wseltzer leaves the room
[23:13:52] blassey joins the room
[23:30:59] wseltzer@jabber.org joins the room
[23:32:48] blassey leaves the room
[23:39:28] wseltzer@jabber.org leaves the room
Powered by ejabberd - robust, scalable and extensible XMPP server Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!