source: wg_materials/ietf88/minutes.txt @ 2507

Last change on this file since 2507 was 2490, checked in by mnot@…, 7 years ago

line-wrap minutes

File size: 28.5 KB
Line 
1# HTTPbis Working Group Minutes
2
3IETF 88, Vancouver
4
5
6## Monday Session
7
8### HTTP/1.x
9
10#### draft -24 change summary [Julian Reschke]
11
12
13#### IETF LC summary
14
15Julian says, that the issues received were mostly editorial issues. All those
16issues received were addressed.
17
18Julian notes that editorial feedback from APPSDIR and SECDIR, plus IANA
19feedback; no individual issues raised. Unless new issues come up, we are ready
20to move on in the process.
21
22Barry notes that they did a short IETF LC, so that they would have comments for
23the meeting. The IESG will get plenty of time, to avoid hasty and unfortunate
24reviews. Mid-December telechat targeted. After that, RFCs! And life will be
25good.
26
27Mark confirms for Barry that there are no document references which would cause
28an RFC editor blockage.
29
30Mark also approved of Barry's bowtie
31
32
33#### LC issue discussion / overview
34
35(too many hashes already)
36
37##### #507 SHOULD vs ought to on integer parsing
38
39Julian recorded this as a design issue because this hadn't be considered.
40
41Roy is OK with MUST on the content-length, that's a framing issue. p5 is
42different because it is an optional feature and if this fails, the thing breaks.
43
44Barry is concerned that even for an optional feature, this needs to be defined
45so that it can work. He is also concerned about this turning into a security
46problem (integer overflow, etc...)
47
48Mark: describes a cached 206 and the potential consequences of overflow in that
49case. Agreement that this might cause corruption.
50
51Roy: OK with MUST
52
53Conclusion: Make both MUST.
54
55##### #519 conneg + proactive and reactive
56
57Roy: Henry has studied the use of 300 and 406 status codes and found that they
58aren't used. This doesn't mean that reactive conneg isn't used. Roy thinks that
59Henry hasn't read and understood the argument, and is instead arguing from the
60TAG. Roy doesn't see anything that he can fix.
61
62Mark: Henry may be suffering a misaprehenshion that reactive == 300, when that
63is made clear elsewhere in the spec.
64
65Conclusion: close, no fix.
66
67##### #432 cacheability of status codes
68
692^31 for max-age currently, why not 2^31-1. Do we leave this as-is and have
70this special case (2^31 exactly), or do we reduce the limit, or do we leave the
71max off.
72
73Barry suggests that once you explain it, you can do anything.
74
75Roy: this is so arbitrary. We don't know why.
76
77Stuart Cheshire: it's MAX_INT but probably a mistake
78
79Roy: is't not a mistake.
80
81PHB: this is NaN for integers, maybe
82
83Speculation ends.
84
85Stuart: change it
86
87Mark: changes cause interop problems
88
89Conclusion: we'll explain, but leave unchanged.
90
91##### On 2119 language
92
93Mark doesn't want to rathole on this, but notes that HTTP is using its own
94dialect and using it consistently.
95
96Julian notes that the fact that this is the issue that is raised most often, so
97the spec must be pretty good.
98
99##### -25 drafts
100
101As soon as possible. Then IESG comments. Then maybe another iteration. Plan is
102to reach the RSE in January.
103
104((what was the 2147483648 issue??))
105
106
107#### Issue #512, APPSIDR review
108
109There is a 2147483648 (2**31) maximum for the delta-second value. APPSDIR
110wondered why this wasn't 2**31 - 1. As this is a historical value (apparently
111for creating a kind of NaN value for integers), decision is to keep it (to
112prevent breaking existing implementation), but add a note about it.
113
114### HTTP/2.x
115
116#### Seattle Interim meeting summary
117
118https://github.com/http2/http2-spec/wiki/Implementations
119
120#### Draft changes and open questions [Martin Thomson]
121
122#### Issue 1: Upgrade Mechanism
123
124Mark talks about Alt-Svc, Upgrade
125(https://tools.ietf.org/html/draft-nottingham-httpbis-alt-svc-00)
126
127Mike Bishop: whether we do this or not, it's not something for the spec. Talks
128about Upgrade and the feature not well known where the server can advertise
129support for HTTP/2.0 (as well as responding to client requests to upgrade).
130
131Mark got the impression that there were lots of corner cases with Upgrade.
132
133Mike: The performance problem is actually worse if you need to create a new
134connection.
135
136Mark: Caching the information avoids that problem.
137
138Mike: That's possible in other cases.
139
140Stuart: Modular design requires separation. Performance often requires that
141those barriers are broken.
142
143Mark: Breaking the strong tie between locator and server is desirable,
144particularly because the HTTP/2.0 connection could be long lived and parking
145connections long term can present a problem for servers who need to offload
146clients.
147
148Dan Druta: concerned about lack of transparency.
149
150Will Chan: the client is able to choose
151
152Ted Hardie: there are a lot of potential corner cases here, and despite a
153desire to avoid corner cases, it might be that you haven't avoided those. Maybe
154we can talk about alternative services that are delivered at the same host.
155That makes a lot of the problems go away. Separating same-host and
156different-host might reduce the complexity inherent in the solution.
157
158Mark: just a small thing, security considerations.
159
160Ted: distinction is important between certificate of www.example.com and
161certificate that is valid for www.example.com
162
163Mark: Still thinks that the connection characteristics will require that later
164thing.
165
166Ted: HTTP/2.0 only, which might require new URI scheme
167
168Mark: you had me up until you said "new URI scheme"
169
170Gabriel M: Agrees with Ted, the CDN issues are not specific to HTTP/2.0.
171Concerned about putting risk on our current schedule. For just the in-the-clear
172upgrade, this doesn't buy anything over the existing (i.e., Upgrade) solution
173in the draft.
174
175Mark: issues with upgrade: blocking while upgrade goes
176
177Ted: two ports on the same host is not something that we worry about, it's the
178different host scenarios that cause concerns.
179
180Gabriel: Origin issues
181
182Gabriel: maybe this is another option for dealing with discovery of HTTP/2.0,
183so that you can avoid Upgrade
184
185Will: Channelling jpinner: this isn't in major deployments yet, but would like
186to restrict this to stuff that people use
187
188Will: maybe something more like ALternate-Protocol (no host shift) is
189interesting.
190
191Will + Patrick McManus: Chrome and Firefox aren't interested in HTTP/2.0 in the
192clear.
193
194Rob Trace: Microsoft is interested in HTTP/2.0 in the clear.
195
196Mark: we're not ripping Upgrade, though we may if it turns out to be poorly
197implemented
198
199Mark: question is whether we want to bring alt-svc (or a reduced form) into the
200spec in order to gain experience with it
201
202Patrick: There are some problems in the draft; Patrick offers to help with the
203draft
204
205Patrick: There are a ton of corner cases in Upgrade. Two objections are: it's
206not going to work, and it's not going to be secure.
207
208Eliot Lear: Questions relate to the caching of the response, in particularm
209when you start going HTTP/2.0 directly on some port, what happens when you move
210location.
211
212Mark: if you detect a network change, then clear your cache
213
214Julian: Theory on why clients do not implement Upgrade: on other clients it
215requires writing both HTTP/1.1 and HTTP/2.0 both, which for testing clients is
216a big burden.
217
218Roberto: this affects both HTTP specs, and it makes the most sense as a
219standalone. Maybe you want to downgrade from HTTP/2.0 to HTTP/1.1
220
221Mark: preparing for an adoption hum
222
223Ted: maybe revise before continuing,
224
225Mark: proposes that he and Patrick revise the doc based on the discussion and
226the editors will add a reference to the spec for that.
227
228Mark: call for input from implementers to determine if it is implementable and
229addresses the issues
230
231#### Issue 270: Priority Levelling
232
233Talked about this lots. Might have to delay this one.
234
235Martin: propose that we move this faster
236
237Will: wanted to collect data that provides justification for the complexity;
238unable to do this because SPDY/4 is vapourware
239
240Mark: we need to get this soon, maybe we ship without a fix
241
242Roberto: maybe an educated guess at what is best is better than nothing
243
244#### Issue 95: Frame Type Extensibility
245
246Martin: Issues around negotiation of extensions
247
248Roberto: we want to be able to experiment, but we don't know about what those
249experiments might look like
250
251#### Issue 292: Cookie Crumbing
252
253Mike: James Snell had a proposal around this
254
255Mark: cookies were always special fro the outset, but we never documented it
256
257Mark: some people didn't want to do this, but he wasn't convinced by those
258arguments
259
260Roberto: doesn't like NULL being treated specially
261
262Mike: intermediaries might reorder
263
264Martin: we can require that intermediaries preserve order
265
266Roberto: it's easy, you decompress, then compress, but ensure that you compress
267in order
268
269Julian: why?
270
271Mark: nulls are being used to concatenate headers into a single header
272
273Roberto: nulls were one way to preserve order, double toggle ensures that you
274can always control the order that headers are emitted by the decompressor
275
276Roberto: if we do nulls, that shouldn't be a compressor problem
277
278Roberto: we aren't likely to get any more data on this, so we should decide
279
280Mark: AD?
281
282Barry: are you assuming that cookies will be used the same way in HTTP/2.0 as
283one [yes, transition]
284
285Mark: maybe we should have a chat with Adam Barth
286
287#### Issue 266: Strings in the compressor should be huffman encoded
288
289302 to #304
290
291Roberto: I added Huffman, but it's not negotiated and the way we do that is ALPN
292
293Mark: why does this need to be negotiated?
294
295Roberto: negotiation saves you from complexity
296
297Martin: plunge the knife in and we can see if the patient squeals too loudly
298
299Conclusion: plunge the knife in
300
301#### Issue 216: Alternate Reference Sets
302
303Herve':
304
305Roberto: simple and better than the original proposal and it seems to
306accomplish the goal
307
308Mark: let's do it
309
310
311## Tuesday Session
312
313### ALPN review [Stephan Friedl and Andrei Popov]
314
315Stephen Friedl presenting
316
317WG member are encouraged to review and provide feedback.
318
319Wan-Teh Chang: This won't work with session resumption.
320
321Stephen Friedl: It will not work unless you renegotiate.
322
323EKR: You can't change the cert and ALPN codepoints, but you can resume.
324
325Michael Tuexun: Is there a reason you don't provide this for a general
326mechanism?
327
328SF: You need to register the name.
329
330MT: I want some binary data in there, is there a reason you did it this way?
331
332SF: We did it because the port number is not reasonable to have different
333
334Roberto Peon: This is there to negotiate the protocol, of anything else would
335be very strange.
336
337Mike Bishop: There is another extension that can be used for passing arbitrary
338application data, but I cannot recall the RFC number
339
340(RFC 4680)
341
342Sean Turner: If we're going to make it expert review, should it be only
343security or only apps or some combination?
344
345Yoav Nir: Expert review should be in security because it can be used for other
346protocols.
347
348Eliot Lear: When my mother offered chocolate or vanilla, I always took both.
349
350Mark Nottingham: I was concerned about how registration works, but I think
351we're ok there now.
352
353### HPACK review [Roberto Peon]
354
355Actions by the Security folk to review and analyze. Mark and Stephen to discuss
356how to get adequate review, now that the documents have settled down.
357
358EKR: Is it correct that the attack is effectively a brute force attack if you
359can't guess the secret. Are you saying that is weaker now?
360
361Roberto Peon: I'm saying that was weaker when you are using a stream compressor.
362
363EKR: The minute you guess the entire thing you're done.
364
365EKR: You are assuming the secret is a high-entropy value.
366
367Stephen Farrel: Do we know someone good at analyzing it?
368
369RP: There are a few people have looked into it. It was not about HPACK, but on
370the general use of Huffman.
371
372Stephen Farrell: What is the timeframe that an analysis is useful?
373
374RP: It's always easy to compress nothing.
375
376NM: For the WG, we wanted to finish this up by next year, and we're on track.
377We are getting implementation experience. If we get this done by middle of next
378year, and it explodes, then we'll have problems. But this is something we can
379get fixed with HTTP/2.1 or its successor. This protocol needs to be easier to
380version.
381
382Stephen Farrel: So we really want analysis within the next six months.
383
384Yoav Nir: This table needs to be in both the client and server, and needs to be
385rather large. It's possible that the table might not be optimal in the future.
386
387RP: We could just go with plaintext encoding, or we use another table or
388version the protocol. We know that it's possible to transmit a new table, but
389we're not sure it's really worhtwhile right now.
390
391EKR: On the threat model, most of the chosen plaintext attacks have exploited
392some functionality of protocol to repeated induce response. As you suggest,
393cookies could use arbitrary entropy. What we need to be observant about is
394other forms of data that are lower entropy that you can get clients to send
395repeatedly, like credit cards, passwords, and PINs.
396
397RP: I agree the smaller the thing the easier it is. If I have to guess a PIN,
398then I think their security model is already broken.
399
400EKR: We are changing the security model somewhat.
401
402NM: I think it's worth explain our proposal on cookie crumbs.
403
404RP: We're looking at breaking cookies, but it's not clear this is making things
405easier or harder. If the encoder is naive and puts a small secret on its own,
406then you've reduced the total secrecy.
407
408Jim Rosekind: IFirst interesting to note that the uncompressed case calls for
409the client to ask repeatedly, and some servers will get pissed off about that.
410
411JR: Second thought is about using the static table. If the result took a data
412set, and you run this numerous times and analyse the space you actually need to
413explore.
414
415RP: That was something the paper I talked about earlier, one could pare down
416the state space based on the bits on the wire. It was a very small reduction --
417it was still exponential.
418
419Stephen Farrel:  I'm wondering if the headers would be impacted by this.
420RP: One of the things about having a compressor like this is people might use
421larger secrets, because the cost is less.
422
423Paul Hoffman: I think you'll need to solicit for those reviews outside of just
424security.
425
426Stephen Farrel: Between us we should try to find some way of getting review.
427
428Lucy Lynch: There are a lot of people around that have experience in this, but
429not exactly in the same problem space.
430
431Jim Rosekind: when you look at this pseudo random cookies that actually use a
432pattern. Using a greater amount of entropy can reduce the benefit from huffman
433encoding.
434
435RP: With all due respect, you're wrong (-: This is generally base64 encoding,
436so it's already reduced.
437
438JR: You're right that is using a reduced input set, but the tables might not
439favor some of the inputs.
440
441YN: I thought one of the goals is to change to use binary encodings.
442
443RP: We can't quite do that because of interop problems with 1.1
444
445RP: Right now, the Huffman tables are different for requests and responses. The
446differences are noticable, and we've have talked about using a third table for
447cookies, but we haven't seen a good benefit there. We haven't actually seen the
448compressiong being larger so far.
449
450JR: It is much more plausible if you're using ASCII characters in unif ways,
451but once you bring in the english language it gets easier.
452
453RP: I agree but we haven't tried that yet for complexity reasons. We haven't
454made an issue for that yet.
455
456Martin Thomson: There's plenty of places that such things show up, not just
457cookies.
458
459RP: Part of the problem for attackers is you don't know where the secret is.
460
461### Encryption and HTTP/2 + Opportunistic Encryption
462
463 Mark Nottingham presenting
464
465** NOTE: slides are _NOT_ on the materials page**
466
467Ted Hardie: One of the big questiosn from yesterday was why would anyone want
468an HTTP/2 connection that was plaintext. If we can go from two states to two by
469eliminating the cleartext then we're in a better place.
470
471#### Alternate Proposal for Discovery
472
473Paul Hoffman presenting
474
475Use DNS to determine if the server for http: likely has a TLS equivalent,
476instead of using HTTP headers. The two are not necssarily orthogonal. This is a
477mechanism difference, not a conceptual difference.
478
479Phil Haram-Baker: In my proposal, you can find the information in DNS because
480that's what DNS is for. The guidance could be used for multiple services.
481
482MN: And that's why we described this in two separate layers. One is what to do,
483the other is how to figure out if you can.
484
485RP: We experimented with something like this a long time ago, and I'm not
486interested in hearing about the mechanisms, but I'm much more interested in
487knowing if this increases our overal security. I'm not sure this actually
488increases the aggregate security. This third level might actually decrease
489security because it confuses users. It might make people thing that
490opportunistic encryption is good enough when it actually isn't. I used to think
491this was a good idea.
492
493William Chan: I talked to various people on the Chrome team, and there some
494concerned about the relaxed mode. We're more interested in doing authentication
495always, even for HTTP: I am quite excited for encryptiong HTTP URIs.
496
497NM: I would love to have the authentication. If we can good get good
498deployment, then it's great. From a se
499
500EL: Concerned this introduces a new form of MitM. If yu have this header, that
501now says you can use relaxed, a MITM can insert the header or replace a 301
502with a header, and the server thinks it has an encrypted tab but is really
503sending data through the MITM.
504
505EL: Why would the attacker not just proxy HTTP, and I'm just saying this is
506another avenue. I'm also not sure we understand the consequences of adding a
507new primative about saying "don't bother to verify the certificate" and
508confusion about unathenticated encryption versus authenticated encryption.
509
510Salvatore ??: I am worried we are putting to many things together, and changing
511things on the fly. It might be too much to manage.
512
513NM: I think this is been kind of implicit in everything we do, because we might
514be switching to a new connection protocol.
515
516YN: I think there is value protecting against passive attacks. Active attacks
517are 10x more expensive. I don't see much point in having authentication for
518HTTP because we have HTTPS. Having encryptiong wihtout encryption has some
519value, as long as user-agents don't say you've got protection.
520
521Larry Masinter: I was thinking about cases where encryption might introduce
522excessive overhead, and one is delivery of video. There is value in encrypting
523the headers, though.
524
525MN: This is a negotiation -- the client can request it, and the server can
526offer it.
527
528RP: It is incorrect to say there is not benefit to encrypting video. It is
529useful for the content provider and for the distributer.
530
531Tim Bray: I tell most people to just use TLS. For you information, the
532arguments against encryption are becoming less and less convincing. I think we
533should keep pushing the rock uphill because we're starting to win.
534
535MN: One of the conclusions we have is whether server authentication needs to be
536lumped in. Does that mean we push everyone to just use HTTPS, or is there still
537benefit to HTTP.
538
539Rohan Mahy: A lot of concerns are about what the user experience. To me it's
540clear -- if you are doing HTTPS, then here's the list of things to get the
541green locked icon. if it's HTTP, then there's no immediate indication. You just
542do it, and not tell enybody about it in the default case.
543
544NM: By the way, that's what's in the draft.
545
546Alissa Cooper: We should think of this as a gift to users (-:
547
548Ted Hardie: I like the idea of not giving the browesr a signal of opportunisitc
549encryption. But users are not the only side in this. There are classes of
550software that might provide a false sense of security. We can get a benefit,
551but it might cost us some authenticated encryption, and that is a serious
552problem. I think we should just do HTTP/2.o is always authenticated encryption.
553If we can't get to server authentication always, then make it hard or hidden to
554do opportunistic.
555
556Brian Dixon: From the perspective of opportunistic, it should be acceptable to
557use self-signed, but still require authentication. This might lower the bar,
558but this might still be of benefit.
559
560Patrick McMannus: People don't always have all the information about what the
561protection there is if we rely on HTTPS only, so having encryption always is a
562good thing. I think it's better to require authenticated, since we really just
563get one chance. But if all we can really do is HTTP-relaxed, then it's still
564moving the bar forward.
565
566??: Most browsrs give you a place to enter certain configuration options on a
567per-host basis. While I don't think we should expose this to users, but I think
568there is benefit.
569
570Johan ??: I'm a little skeptical of doing encryption at this level. Especialy
571as it plays with DNS.
572
573Richard Barnes: Unauthenticated encryption is the new plaintext. This means
574that the worst case is that you are protected from passive attacks. We should
575shoot for authenticated encryption. If our goal is to increase the number of
576places that authentication and integrity protection is increased, I'm not sure
577these goals get us there. If we require authentication, it means people need to
578get the proper credentials at scale, but we're not there right now.
579
580Christian Huitema: I am skeptical about the amount of protection you really
581get. I am concerned about the case where we first send the request in
582cleartext, with all of the potential traffic analisys information exposed, is
583not providing any benefit. We should think about the security considerations
584about this, and maybe have other ways of determining this information, or
585require another trip in order.
586
587NM: We did talk about this in Seattle, and if people are going to do this for
588security purposes, then you would block this data. Such as sending a very
589minimal amount of infomration in an exloratory request or use DNS.
590
591RP: I want to point out why people don't deploy HTTPS. It's not because of the
592cost of getting certs, but because HTTPS is significantly slower. People doing
593commerce are very interested in performance, and are unlikely to deploy unless
594HTTP2/ with TLS is as fast or faster. Our experimentation at Google has shown
595that HTTPS is as fast or faster for a large number of cases.
596
597RP: < note taker missed it >
598
599Stephen Friedl: I agree with Roberto. I don't trust locks on my browsers, and
600heaven forbid I explain to laymen. The only way to do this is HTTPS (with
601authentication) only. No more HTTP. And we should be rigorous about it. I am in
602the camp to push everything to HTTPS except for the small set of cases where it
603doesn't make sense. For ALPN, we should be more formal of how to register the
604types.
605
606Rob Trace: I would like to have a secure web, but there is a long list of
607corner cases where it's applicable to have HTTP plaintext. It's hard to claim
608this is a security feature, since you still have to treat the content in and
609out as insecure.
610
611EKR: Is HTTP/2-over-TLS only still on the table?
612
613MN: It appears that the position of HTTP/2. over only TLS is too extreme.
614
615EKR: Doing nothing is stupid. What I think we're arguing about is whether
616having the relaxed version lowers the bar too much. I think determining how
617many would do the right thing, or at least do opportunistic is tricky and we
618don't know. I think opportunistic TLS is worth doing.
619
620MN: People have expressed concern about confusing people about the security
621state, and I don't think that will be the case. Server admins will open a
622browser and look for the indicators. If there are none, then they don't think
623they have any protection. As for commernce, I'm not sure that's an important
624thing anymore. What's important is what happens out-of-the-box. If any
625encryption requires doing more than installing the software then people won't
626be doing it most times.
627
628EL: One of the thigns I was thinking about was to do the discovery inline
629instead of a referall mechanisms. I think having all the security and HTTP
630people helps informs the discussion for perpass. A few people made some
631economic assertions, these are interesting questions for researchers to look
632into. Also, the IRTF meeting is discussing how to get researchers and those
633willing to pay for it together.
634
635PHB: The original goal for HTTPS was to have the same level of trust for people
636buying things online as buying things in a store. So not turning on the lock if
637you haven't authenticated is good. Deploying opportunistic TLS increases the
638work attacks have to do which is good. But for the other attacks, where someone
639could downgrade someone from HTTP/2 to HTTP/1.1. Do you really want to
640re-encrypt YouTube vidoes each time?
641
642AUDIENCE: YES
643
644PHB: Once you get past that, you are really talking about doing strong crypto
645or crappy crypto. You could probably collapse the work factors to one or two
646choices.
647
648Keith Moore: The decision this WG is making has a long term effect. I think we
649need to look beyond the current threat or the past threats. Right now active
650attacks are harder than passive attacks. But if a passive attack is feasible,
651then an active attack is also feasible. I'm not sure there's a benefit to do
652opportunistic because you can be downgraded, unless you can absolutely prevent
653it.
654
655TH: What Keith said, but also this is an estimation problem (as EKR pointed
656out). We are taking the current state and adding opportunistic encryption,
657which prevents FireSheep. Does adding opportunistic reduce the number of times
658people get good certs?
659
660EKR: If we provide the unauth mechanism, [EKR line noise]
661
662TH: If we ask "should HTTP/2.0 be TLS-only?" we might come to a different
663conclusion.
664
665RP: My definition of commerce might be very different of yours. Pintrest
666doesn't actually sell anything, but they still add value. Commerce doesn't
667always mean adding things to a cart and checking out. Pintrest doesn't have a
668competitor right now, but latency matters. Second, it is far easier to add
669authentication later than to remove unauthentication later. If we weaken it by
670adding this third thing it will be hard to fix.
671
672??: Trying to protect against just the passive attack is silly. One thing is
673very clear is that if I have a HTTP URI, I want to try to use it in a secure
674way. If I use it in a secure way, I want to really be secure.
675
676MN: If we did do opportunistic, do you want to see mitigation of downgrade
677attack. [Yes]
678
679Stephen Farrel: I think there's value in trying to mitigate the passive attack,
680so I think the do nothing option is really stupid. Trying to insist on HTTPS
681everywhere is not feasible or scalable. I think the third option is the right
682approach.
683
684MN: I think we have an opportunity to improve performance with HTTP/2
685
686Will Chan: One barrier I've heard is about mixed content. Even though I'm a big
687fan of telling people to just use HTTPS, but I need third-party ads and what do
688I do? While I want to got HTTPS only, I think there's still a lot of benefit
689because it reduces the barrier of entry.
690
691EKR: I think you should consider option 0, and you consider TLS for HTTP/2
692always. I think we should do something, and having some option for the server
693to indicate it only wants to do the authenticated mode. Is it ok to have mixed
694content? We need to consider the policies that are involved in these cases.
695
696PHB: I think a lot of the argument is over a choice that doesn't exist. One is
697whether you have authenticated cert or not, since the IETF doesn't strongly
698define what authenticated really means. The only choice that can be made is
699whether the client can be allowed to turn off its root criteria.
700
701Roy Fielding: I don't think you can require HTTP/2 to be encrypted always,
702given all the places that HTTP servers are deployed. I could get behind that if
703you use HTTP you use a secure transport protocol, ether it's TLS or SSH or
704something. I don't think it's a technical argument, but there is a social
705argument that you can and probably should make.
706
707#### What does the WG Want?
708
709Mark Bishop: Just want to be clear, that for 2 and 3 that there's an option to
710go better, but no requirement.
711
712LM: One considerations is if users would be presented with information about
713those connections. Which of these include those dialogs/information? And what
714is the performance impact?
715
716Dixon: To clarify server auth, it should include both CA-based and DANE-based.
717
718Rohan Mahy: I don't know what #3 means with the word somehow, especially in a
719technical context.
720
721Gabriel Montenago: Remember what the desired final state is to increase the use
722of valid TLS. Where is that in these choices? I think plaintext has an
723important place in the world.
724
725Barry Leiba: You should be looking for who cannot live with some of these.
726
7270) Don't know (yet)
728
729[strong humms for can't live with]
730
7311) Do nothing - hope that hTTPS gets more adoption
732
733[strong humms for can't live with]
734
7352) Opportunistic encryption w/o server authentication for HTTP URIs - just for
736passive attacks
737
738[ less strong for can't live with ]
739
7403) Opportunistic encryption with server authentication AND downgrade protection
741(somehow) for HTTP URIs; no requirement upon HTTP/2.0 when not available
742
743[ weakest for can't live with ]
744
7454) Requre secure underlying protocol for HTTP/2.0 (at least in web browsing)
746
747[ weaker for can't live with ]
Note: See TracBrowser for help on using the repository browser.