Ignore:
Timestamp:
12/11/13 06:43:28 (7 years ago)
Author:
mnot@…
Message:

line-wrap minutes

File:
1 edited

Legend:

Unmodified
Added
Removed
  • wg_materials/ietf88/minutes.txt

    r2489 r2490  
    1313#### IETF LC summary
    1414
    15 Julian says, that the issues received were mostly editorial issues.  All those issues received were addressed.
    16 
    17 Julian  notes that editorial feedback from APPSDIR and SECDIR, plus IANA  feedback; no individual issues raised.  Unless new issues come up, we  are ready to move on in the process.
    18 
    19 Barry  notes that they did a short IETF LC, so that they would have comments  for the meeting.  The IESG will get plenty of time, to avoid hasty and  unfortunate reviews.  Mid-December telechat targeted. After that, RFCs!   And life will be good.
    20 
    21 Mark confirms for Barry that there are no document references which would cause an RFC editor blockage.
     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.
    2229
    2330Mark also approved of Barry's bowtie
     
    3239Julian recorded this as a design issue because this hadn't be considered.
    3340
    34 Roy is OK with MUST on the content-length, that's a framing issue.  p5 is different because it is an optional feature and if this fails, the thing breaks.
    35 
    36 Barry is concerned that even for an optional feature, this needs to be defined so that it can work.  He is also concerned about this turning into a security problem (integer overflow, etc...)
    37 
    38 Mark: describes a cached 206 and the potential consequences of overflow in that case.  Agreement that this might cause corruption.
     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.
    3950
    4051Roy: OK with MUST
     
    4455##### #519 conneg + proactive and reactive
    4556
    46 Roy: Henry has studied the use of 300 and 406 status codes and found that they aren't used.  This doesn't mean that reactive conneg isn't used.  Roy thinks that Henry hasn't read and understood the argument, and is instead arguing from the TAG.  Roy doesn't see anything that he can fix.
    47 
    48 Mark: Henry may be suffering a misaprehenshion that reactive == 300, when that is made clear elsewhere in the spec.
     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.
    4964
    5065Conclusion: close, no fix.
     
    5267##### #432 cacheability of status codes
    5368
    54 2^31 for max-age currently, why not 2^31-1.  Do we leave this as-is and have this special case (2^31 exactly), or do we reduce the limit, or do we leave the max off.
     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.
    5572
    5673Barry suggests that once you explain it, you can do anything.
    5774
    58 Roy: this is so arbitrary.  We don't know why.
     75Roy: this is so arbitrary. We don't know why.
    5976
    6077Stuart Cheshire: it's MAX_INT but probably a mistake
     
    7491##### On 2119 language
    7592
    76 Mark doesn't want to rathole on this, but notes that HTTP is using its own dialect and using it consistently.
    77 
    78 Julian notes that the fact that this is the issue that is raised most often, so the spec must be pretty good.
     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.
    7998
    8099##### -25 drafts
    81100
    82 As soon as possible.  Then IESG comments.  Then maybe another iteration.  Plan is to reach the RSE in January.
     101As soon as possible. Then IESG comments. Then maybe another iteration. Plan is
     102to reach the RSE in January.
    83103
    84104((what was the 2147483648 issue??))
    85 Issue #512, APPSIDR review
    86 There is a 2147483648 (2**31) maximum for the delta-second value. APPSDIR wondered why this wasn't 2**31 - 1. As this is a historical value (apparently for creating a kind of NaN value for integers), decision is to keep it (to prevent breaking existing implementation), but add a note about it.
    87 No, sorry, I missed that...Issue number?
     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.
    88113
    89114### HTTP/2.x
     
    97122#### Issue 1: Upgrade Mechanism
    98123
    99 Mark talks about Alt-Svc, Upgrade (https://tools.ietf.org/html/draft-nottingham-httpbis-alt-svc-00)
    100 
    101 Mike Bishop: whether we do this or not, it's not something for the spec.  Talks about Upgrade and the feature not well known where the server can advertise support for HTTP/2.0 (as well as responding to client requests to upgrade).
     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).
    102130
    103131Mark got the impression that there were lots of corner cases with Upgrade.
    104132
    105 Mike: The performance problem is actually worse if you need to create a new connection.
     133Mike: The performance problem is actually worse if you need to create a new
     134connection.
    106135
    107136Mark: Caching the information avoids that problem.
     
    109138Mike: That's possible in other cases.
    110139
    111 Stuart: Modular design requires separation.  Performance often requires that those barriers are broken.
    112 
    113 Mark: Breaking the strong tie between locator and server is desirable, particularly because the HTTP/2.0 connection could be long lived and parking connections long term can present a problem for servers who need to offload clients.
     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.
    114147
    115148Dan Druta: concerned about lack of transparency.
     
    117150Will Chan: the client is able to choose
    118151
    119 Ted Hardie: there are a lot of potential corner cases here, and despite a desire to avoid corner cases, it might be that you haven't avoided those.  Maybe we can talk about alternative services that are delivered at the same host.  That makes a lot of the problems go away.  Separating same-host and different-host might reduce the complexity inherent in the solution.
     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.
    120157
    121158Mark: just a small thing, security considerations.
    122159
    123 Ted: distinction is important between certificate of www.example.com and certificate that is valid for www.example.com
    124 
    125 Mark: Still thinks that the connection characteristics will require that later thing.
     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.
    126165
    127166Ted: HTTP/2.0 only, which might require new URI scheme
     
    129168Mark: you had me up until you said "new URI scheme"
    130169
    131 Gabriel M: Agrees with Ted, the CDN issues are not specific to HTTP/2.0.  Concerned about putting risk on our current schedule.  For just the in-the-clear upgrade, this doesn't buy anything over the existing (i.e., Upgrade) solution in the draft.
     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.
    132174
    133175Mark: issues with upgrade: blocking while upgrade goes
    134176
    135 Ted: two ports on the same host is not something that we worry about, it's the different host scenarios that cause concerns.
     177Ted: two ports on the same host is not something that we worry about, it's the
     178different host scenarios that cause concerns.
    136179
    137180Gabriel: Origin issues
    138181
    139 Gabriel: maybe this is another option for dealing with discovery of HTTP/2.0, so that you can avoid Upgrade
    140 
    141 Will: Channelling jpinner: this isn't in major deployments yet, but would like to restrict this to stuff that people use
    142 
    143 Will: maybe something more like ALternate-Protocol (no host shift) is interesting.
    144 
    145 Will + Patrick McManus: Chrome and Firefox aren't interested in HTTP/2.0 in the clear.
     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.
    146193
    147194Rob Trace: Microsoft is interested in HTTP/2.0 in the clear.
    148195
    149 Mark: we're not ripping Upgrade, though we may if it turns out to be poorly implemented
    150 
    151 Mark: question is whether we want to bring alt-svc (or a reduced form) into the spec in order to gain experience with it
    152 
    153 Patrick: There are some problems in the draft; Patrick offers to help with the draft
    154 
    155 Patrick: There are a ton of corner cases in Upgrade.  Two objections are: it's not going to work, and it's not going to be secure.
    156 
    157 Eliot Lear: Questions relate to the caching of the response, in particularm when you start going HTTP/2.0 directly on some port, what happens when you move location.
     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.
    158211
    159212Mark: if you detect a network change, then clear your cache
    160213
    161 Julian: Theory on why clients do not implement Upgrade: on other clients it requires writing both HTTP/1.1 and HTTP/2.0 both, which for testing clients is a big burden.
    162 
    163 Roberto: this affects both HTTP specs, and it makes the most sense as a standalone.  Maybe you want to downgrade from HTTP/2.0 to HTTP/1.1
     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
    164220
    165221Mark: preparing for an adoption hum
     
    167223Ted: maybe revise before continuing,
    168224
    169 Mark: proposes that he and Patrick revise the doc based on the discussion and the editors will add a reference to the spec for that.
    170 
    171 Mark: call for input from implementers to determine if it is implementable and addresses the issues
     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
    172230
    173231#### Issue 270: Priority Levelling
    174232
    175 Talked about this lots.  Might have to delay this one.
     233Talked about this lots. Might have to delay this one.
    176234
    177235Martin: propose that we move this faster
    178236
    179 Will: wanted to collect data that provides justification for the complexity; unable to do this because SPDY/4 is vapourware
     237Will: wanted to collect data that provides justification for the complexity;
     238unable to do this because SPDY/4 is vapourware
    180239
    181240Mark: we need to get this soon, maybe we ship without a fix
     
    187246Martin: Issues around negotiation of extensions
    188247
    189 Roberto: we want to be able to experiment, but we don't know about what those experiments might look like
     248Roberto: we want to be able to experiment, but we don't know about what those
     249experiments might look like
    190250
    191251#### Issue 292: Cookie Crumbing
     
    195255Mark: cookies were always special fro the outset, but we never documented it
    196256
    197 Mark: some people didn't want to do this, but he wasn't convinced by those arguments
     257Mark: some people didn't want to do this, but he wasn't convinced by those
     258arguments
    198259
    199260Roberto: doesn't like NULL being treated specially
     
    203264Martin: we can require that intermediaries preserve order
    204265
    205 Roberto: it's easy, you decompress, then compress, but ensure that you compress in order
     266Roberto: it's easy, you decompress, then compress, but ensure that you compress
     267in order
    206268
    207269Julian: why?
     
    209271Mark: nulls are being used to concatenate headers into a single header
    210272
    211 Roberto: nulls were one way to preserve order, double toggle ensures that you can always control the order that headers are emitted by the decompressor
     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
    212275
    213276Roberto: if we do nulls, that shouldn't be a compressor problem
     
    217280Mark: AD?
    218281
    219 Barry: are you assuming that cookies will be used the same way in HTTP/2.0 as one [yes, transition]
     282Barry: are you assuming that cookies will be used the same way in HTTP/2.0 as
     283one [yes, transition]
    220284
    221285Mark: maybe we should have a chat with Adam Barth
     
    229293Mark: why does this need to be negotiated?
    230294
    231 ROberto: negotiation saves you from complexity
     295Roberto: negotiation saves you from complexity
    232296
    233297Martin: plunge the knife in and we can see if the patient squeals too loudly
     
    237301#### Issue 216: Alternate Reference Sets
    238302
    239 Herve':
    240 
    241 Roberto: simple and better than the original proposal and it seems to accomplish the goal
     303Herve':
     304
     305Roberto: simple and better than the original proposal and it seems to
     306accomplish the goal
    242307
    243308Mark: let's do it
    244309
    245310
    246 
    247311## Tuesday Session
    248312
     
    259323EKR: You can't change the cert and ALPN codepoints, but you can resume.
    260324
    261 Michael Tuexun: Is there a reason you don't provide this for a general mechanism?
     325Michael Tuexun: Is there a reason you don't provide this for a general
     326mechanism?
    262327
    263328SF: You need to register the name.
     
    267332SF: We did it because the port number is not reasonable to have different
    268333
    269 Roberto Peon: This is there to negotiate the protocol, of anything else would be very strange.
    270 
    271 Mike Bishop: There is another extension that can be used for passing arbitrary application data, but I cannot recall the RFC number
     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
    272339
    273340(RFC 4680)
    274341
    275 Sean Turner: If we're going to make it expert review, should it be only security or only apps or some combination?
    276 
    277 Yoav Nir: Expert review should be in security because it can be used for other protocols.
     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.
    278347
    279348Eliot Lear: When my mother offered chocolate or vanilla, I always took both.
    280349
    281 Mark Nottingham: I was concerned about how registration works, but I think we're ok there now.
     350Mark Nottingham: I was concerned about how registration works, but I think
     351we're ok there now.
    282352
    283353### HPACK review [Roberto Peon]
    284354
    285 Actions by the Security folk to review and analyze.  Mark and Stephen to discuss how to get adequate review, now that the documents have settled down.
    286 
    287 EKR: Is it correct that the attack is effectively a brute force attack if you can't guess the secret.  Are you saying that is weaker now?
     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?
    288360
    289361Roberto Peon: I'm saying that was weaker when you are using a stream compressor.
     
    295367Stephen Farrel: Do we know someone good at analyzing it?
    296368
    297 RP: There are a few people have looked into it.  It was not about HPACK, but on the general use of Huffman.
     369RP: There are a few people have looked into it. It was not about HPACK, but on
     370the general use of Huffman.
    298371
    299372Stephen Farrell: What is the timeframe that an analysis is useful?
     
    301374RP: It's always easy to compress nothing.
    302375
    303 NM: For the WG, we wanted to finish this up by next year, and we're on track.  We are getting implementation experience.  If we get this done by middle of next year, and it explodes, then we'll have problems.  But this is something we can get fixed with HTTP/2.1 or its successor.  This protocol needs to be easier to version.
     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.
    304381
    305382Stephen Farrel: So we really want analysis within the next six months.
    306383
    307 Yoav Nir: This table needs to be in both the client and server, and needs to be rather large.  It's possible that the table might not be optimal in the future.
    308 
    309 RP: We could just go with plaintext encoding, or we use another table or version the protocol.  We know that it's possible to transmit a new table, but we're not sure it's really worhtwhile right now.
    310 
    311 EKR: On the threat model, most of the chosen plaintext attacks have exploited some functionality of protocol to repeated induce response.  As you suggest, cookies could use arbitrary entropy.  What we need to be observant about is other forms of data that are lower entropy that you can get clients to send repeatedly, like credit cards, passwords, and PINs.
    312 
    313 RP:  I agree the smaller the thing the easier it is.  If I have to guess a PIN, then I think their security model is already broken.
     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.
    314399
    315400EKR: We are changing the security model somewhat.
     
    317402NM: I think it's worth explain our proposal on cookie crumbs.
    318403
    319 RP: We're looking at breaking cookies, but it's not clear this is making things easier or harder.  If the encoder is naive and puts a small secret on its own, then you've reduced the total secrecy.
    320 
    321 Jim Rosekind: IFirst interesting to note that the uncompressed case calls for the client to ask repeatedly, and some servers will get pissed off about that.
    322 
    323 JR: Second thought is about using the static table. If the result took a data set, and you run this numerous times and analyse the space you actually need to explore.
    324 
    325 RP: That was something the paper I talked about earlier, one could pare down the state space based on the bits on the wire.  It was a very small reduction -- it was still exponential.
     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.
    326418
    327419Stephen Farrel:  I'm wondering if the headers would be impacted by this.
    328 
    329 RP: One of the things about having a compressor like this is people might use larger secrets, because the cost is less.
    330 
    331 Paul Hoffman: I think you'll need to solicit for those reviews outside of just security.
     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.
    332425
    333426Stephen Farrel: Between us we should try to find some way of getting review.
    334427
    335 Lucy Lynch:  There are a lot of people around that have experience in this, but not exactly in the same problem space.
    336 
    337 Jim Rosekind: when you look at this pseudo random cookies that actually use a pattern.  Using a greater amount of entropy can reduce the benefit from huffman encoding.
    338 
    339 RP: With all due respect, you're wrong (-:  This is generally base64 encoding, so it's already reduced.
    340 
    341 JR: You're right that is using a reduced input set, but the tables might not favor some of the inputs.
     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.
    342440
    343441YN: I thought one of the goals is to change to use binary encodings.
     
    345443RP: We can't quite do that because of interop problems with 1.1
    346444
    347 RP: Right now, the Huffman tables are different for requests and responses.  The differences are noticable, and we've have talked about using a third table for cookies, but we haven't seen a good benefit there.  We haven't actually seen the compressiong being larger so far.
    348 
    349 JR: It is much more plausible if you're using ASCII characters in unif ways, but once you bring in the english language it gets easier.
    350 
    351 RP: I agree but we haven't tried that yet for complexity reasons.  We haven't made an issue for that yet.
    352 
    353 Martin Thomson: There's plenty of places that such things show up, not just cookies.
     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.
    354458
    355459RP: Part of the problem for attackers is you don't know where the secret is.
     
    357461### Encryption and HTTP/2 + Opportunistic Encryption
    358462
    359 
    360463 Mark Nottingham presenting
    361  
     464
    362465** NOTE: slides are _NOT_ on the materials page**
    363466
    364 Ted Hardie: One of the big questiosn from yesterday was why would anyone want an HTTP/2 connection that was plaintext.  If we can go from two states to two by eliminating the cleartext then we're in a better place.
     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.
    365470
    366471#### Alternate Proposal for Discovery
     
    368473Paul Hoffman presenting
    369474
    370 Use DNS to determine if the server for http: likely has a TLS equivalent, instead of using HTTP headers.  The two are not necssarily orthogonal.  This is a mechanism difference, not a conceptual difference.
    371 
    372 Phil Haram-Baker: In my proposal, you can find the information in DNS because that's what DNS is for.  The guidance could be used for multiple services.
    373 
    374 MN: And that's why we described this in two separate layers.  One is what to do, the other is how to figure out if you can.
    375 
    376 RP: We experimented with something like this a long time ago, and I'm not interested in hearing about the mechanisms, but I'm much more interested in knowing if this increases our overal security.  I'm not sure this actually increases the aggregate security.  This third level might actually decrease security because it confuses users.  It might make people thing that opportunistic encryption is good enough when it actually isn't.  I used to think this was a good idea.
    377 
    378 William Chan: I talked to various people on the Chrome team, and there some concerned about the relaxed mode.  We're more interested in doing authentication always, even for HTTP:  I am quite excited for encryptiong HTTP URIs.
    379 
    380 NM: I would love to have the authentication.  If we can good get good deployment, then it's great.  From a se
    381 
    382 EL: Concerned this introduces a new form of MitM.  If yu have this header, that now says you can use relaxed, a MITM can insert the header or replace a 301 with a header, and the server thinks it has an encrypted tab but is really sending data through the MITM.
    383 
    384 EL: Why would the attacker not just proxy HTTP, and I'm just saying this is another avenue.  I'm also not sure we understand the consequences of adding a new primative about saying "don't bother to verify the certificate" and confusion about unathenticated encryption versus authenticated encryption.
    385 
    386 Salvatore ??: I am worried we are putting to many things together, and changing things on the fly.  It might be too much to manage.
    387 
    388 NM: I think this is been kind of implicit in everything we do, because we might be switching to a new connection protocol.
    389 
    390 YN: I think there is value protecting against passive attacks.  Active attacks are 10x more expensive.  I don't see much point in having authentication for HTTP because we have HTTPS.  Having encryptiong wihtout encryption has some value, as long as user-agents don't say you've got protection.
    391 
    392 Larry Masinter: I was thinking about cases where encryption might introduce excessive overhead, and one is delivery of video.  There is value in encrypting the headers, though.
    393 
    394 MN: This is a negotiation -- the client can request it, and the server can offer it.
    395 
    396 RP: It is incorrect to say there is not benefit to encrypting video.  It is useful for the content provider and for the distributer.
    397 
    398 Tim Bray: I tell most people to just use TLS.  For you information, the arguments against encryption are becoming less and less convincing.  I think we should keep pushing the rock uphill because we're starting to win.
    399 
    400 MN: One of the conclusions we have is whether server authentication needs to be lumped in.  Does that mean we push everyone to just use HTTPS, or is there still benefit to HTTP.
    401 
    402 Rohan Mahy: A lot of concerns are about what the user experience.  To me it's clear -- if you are doing HTTPS, then here's the list of things to get the green locked icon.  if it's HTTP, then there's no immediate indication.  You just do it, and not tell enybody about it in the default case.
     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.
    403543
    404544NM: By the way, that's what's in the draft.
     
    406546Alissa Cooper: We should think of this as a gift to users (-:
    407547
    408 Ted Hardie: I like the idea of not giving the browesr a signal of opportunisitc encryption.  But users are not the only side in this.  There are classes of software that might provide a false sense of security.  We can get a benefit, but it might cost us some authenticated encryption, and that is a serious problem.  I think we should just do HTTP/2.o is always authenticated encryption.  If we can't get to server authentication always, then make it hard or hidden to do opportunistic.
    409 
    410 Brian Dixon: From the perspective of opportunistic, it should be acceptable to use self-signed, but still require authentication.  This might lower the bar, but this might still be of benefit.
    411 
    412 Patrick McMannus: People don't always have all the information about what the protection there is if we rely on HTTPS only, so having encryption always is a good thing.  I think it's better to require authenticated, since we really just get one chance.  But if all we can really do is HTTP-relaxed, then it's still moving the bar forward.
    413 
    414 ??: Most browsrs give you a place to enter certain configuration options on a per-host basis.  While I don't think we should expose this to users, but I think there is benefit.
    415 
    416 Johan ??: I'm a little skeptical of doing encryption at this level.  Especialy as it plays with DNS.
    417 
    418 Richard Barnes: Unauthenticated encryption is the new plaintext.  This means that the worst case is that you are protected from passive attacks.  We should shoot for authenticated encryption.  If our goal is to increase the number of places that authentication and integrity protection is increased, I'm not sure these goals get us there.  If we require authentication, it means people need to get the proper credentials at scale, but we're not there right now.
    419 
    420 Christian Huitema: I am skeptical about the amount of protection you really get.  I am concerned about the case where we first send the request in cleartext, with all of the potential traffic analisys information exposed, is not providing any benefit.  We should think about the security considerations about this, and maybe have other ways of determining this information, or require another trip in order.
    421 
    422 NM: We did talk about this in Seattle, and if people are going to do this for security purposes, then you would block this data.  Such as sending a very minimal amount of infomration in an exloratory request or use DNS.
    423 
    424 RP:  I want to point out why people don't deploy HTTPS.  It's not because of the cost of getting certs, but because HTTPS is significantly slower.  People doing commerce are very interested in performance, and are unlikely to deploy unless HTTP2/ with TLS is as fast or faster. Our experimentation at Google has shown that HTTPS is as fast or faster for a large number of cases.
     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.
    425596
    426597RP: < note taker missed it >
    427598
    428 Stephen Friedl: I agree with Roberto.  I don't trust locks on my browsers, and heaven forbid I explain to laymen.  The only way to do this is HTTPS (with authentication) only.  No more HTTP.  And we should be rigorous about it.  I am in the camp to push everything to HTTPS except for the small set of cases where it doesn't make sense.  For ALPN, we should be more formal of how to register the types.
    429 
    430 Rob Trace: I would like to have a secure web, but there is a long list of corner cases where it's applicable to have HTTP plaintext.  It's hard to claim this is a security feature, since you still have to treat the content in and out as insecure.
     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.
    431610
    432611EKR: Is HTTP/2-over-TLS only still on the table?
     
    434613MN: It appears that the position of HTTP/2. over only TLS is too extreme.
    435614
    436 EKR: Doing nothing is stupid.  What I think we're arguing about is whether having the relaxed version lowers the bar too much.  I think determining how many would do the right thing, or at least do opportunistic is tricky and we don't know.  I think opportunistic TLS is worth doing.
    437 
    438 MN: People have expressed concern about confusing people about the security state, and I don't think that will be the case.  Server admins will open a browser and look for the indicators.  If there are none, then they don't think they have any protection.  As for commernce, I'm not sure that's an important thing anymore.  What's important is what happens out-of-the-box.  If any encryption requires doing more than installing the software then people won't be doing it most times.
    439 
    440 EL:  One of the thigns I was thinking about was to do the discovery inline instead of a referall mechanisms.  I think having all the security and HTTP people helps informs the discussion for perpass.  A few people made some economic assertions,  these are  interesting questions for researchers to look into.  Also, the IRTF meeting is discussing how to get researchers and those willing to pay for it together.
    441 
    442 PHB: The original goal for HTTPS was to have the same level of trust for people buying things online as buying things in a store.  So not turning on the lock if you haven't authenticated is good.  Deploying opportunistic TLS increases the work attacks have to do which is good.  But for the other attacks, where someone could downgrade someone from HTTP/2 to HTTP/1.1.  Do you really want to re-encrypt YouTube vidoes each time?
     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?
    443641
    444642AUDIENCE: YES
    445643
    446 PHB: Once you get past that, you are really talking about doing strong crypto or crappy crypto.  You could probably collapse the work factors to one or two choices.
    447 
    448 Keith Moore: The decision this WG is making has a long term effect.  I think we need to look beyond the current threat or the past threats.  Right now active attacks are harder than passive attacks.  But if a passive attack is feasible, then an active attack is also feasible.  I'm not sure there's a benefit to do opportunistic because you can be downgraded, unless you can absolutely prevent it.
    449 
    450 TH: What Keith said, but also this is an estimation problem (as EKR pointed out).  We are taking the current state and adding opportunistic encryption, which prevents FireSheep.  Does adding opportunistic reduce the number of times people get good certs?
     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?
    451659
    452660EKR: If we provide the unauth mechanism, [EKR line noise]
    453661
    454 TH: If we ask "should HTTP/2.0 be TLS-only?" we might come to a different conclusion.
    455 
    456 RP: My definition of commerce might be very different of yours.  Pintrest doesn't actually sell anything, but they still add value.  Commerce doesn't always mean adding things to a cart and checking out.  Pintrest doesn't have a competitor right now, but latency matters.  Second, it is far easier to add authentication later than to remove unauthentication later.  If we weaken it by adding this third thing it will be hard to fix.
    457 
    458 ??: Trying to protect against just the passive attack is silly.  One thing is very clear is that if I have a HTTP URI, I want to try to use it in a secure way.  If I use it in a secure way, I want to really be secure.
    459 
    460 MN: If we did do opportunistic, do you want to see mitigation of downgrade attack. [Yes]
    461 
    462 Stephen Farrel: I think there's value in trying to mitigate the passive attack, so I think the do nothing option is really stupid.  Trying to insist on HTTPS everywhere is not feasible or scalable.  I think the third option is the right approach.
     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.
    463683
    464684MN: I think we have an opportunity to improve performance with HTTP/2
    465685
    466 Will Chan: One barrier I've heard is about mixed content.  Even though I'm a big fan of telling people to just use HTTPS, but I need third-party ads and what do I do?  While I want to got HTTPS only, I think there's still a lot of benefit because it reduces the barrier of entry.
    467 
    468 EKR:  I think you should consider option 0, and you consider TLS for HTTP/2 always.  I think we should do something, and having some option for the server to indicate it only wants to do the authenticated mode.  Is it ok to have mixed content?  We need to consider the policies that are involved in these cases.
    469 
    470 PHB: I think a lot of the argument is over a choice that doesn't exist.  One is whether you have authenticated cert or not, since the IETF doesn't strongly define what authenticated really means.  The only choice that can be made is whether the client can be allowed to turn off its root criteria.
    471 
    472 Roy Fielding: I don't think you can require HTTP/2 to be encrypted always, given all the places that HTTP servers are deployed.  I could get behind that if you use HTTP you use a secure transport protocol, ether it's TLS or SSH or something.  I don't think it's a technical argument, but there is a social argument that you can and probably should make.
     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.
    473706
    474707#### What does the WG Want?
    475708
    476 Mark Bishop: Just want to be clear, that for 2 and 3 that there's an option to go better, but no requirement.
    477 
    478 LM: One considerations is if users would be presented with information about those connections. Which of these include those dialogs/information?  And what is the performance impact?
     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?
    479715
    480716Dixon: To clarify server auth, it should include both CA-based and DANE-based.
    481717
    482 Rohan Mahy: I don't know what #3 means with the word somehow, especially in a technical context.
    483 
    484 Gabriel Montenago: Remember what the desired final state is to increase the use of valid TLS.  Where is that in these choices?  I think plaintext has an important place in the world.
     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.
    485724
    486725Barry Leiba: You should be looking for who cannot live with some of these.
    487726
    488 0) Don't know (yet) 
     7270) Don't know (yet)
    489728
    490729[strong humms for can't live with]
     
    494733[strong humms for can't live with]
    495734
    496 2) Opportunistic encryption w/o server authentication for HTTP URIs - just for passive attacks
     7352) Opportunistic encryption w/o server authentication for HTTP URIs - just for
     736passive attacks
    497737
    498738[ less strong for can't live with ]
    499739
    500 3) Opportunistic encryption with server authentication AND downgrade protection (somehow) for HTTP URIs; no requirement upon HTTP/2.0 when not available
    501 
    502 [ weakest  for can't live with ]
     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 ]
    503744
    5047454) Requre secure underlying protocol for HTTP/2.0 (at least in web browsing)
Note: See TracChangeset for help on using the changeset viewer.