Mateusz, It appears that the way forward is to document the mechanism you have in mind in an Internet-Draft. That I-D should include the mechanism as well as the new alert you want.* It is better that the alert be in a separate I-D (i.e., not in the TLS 1.3 specification) because including an alert in the TLS 1.3 draft that refers to a yet-to-be standardized mechanism is pretty much not going to work with the IETF publication process; we are near the finish line for TLS 1.3 and having a reference of this sort will no doubt add some delay possibly a lot of delay.**
The other issue here is that there is an existing WG chartered (capport) to work on this particular problem or some part of it; the TLS WG would be stepping on their toes if we picked up the work. For the two reasons listed above, I’m asking ekr to close the PR#1134. spt * Please do not include a value for the alert use "(TBD)". ** The reference would be a normative reference to another specification that was not at the same “maturity" level. The TLS 1.3 specification would have to wait while this new I-D gets to the same maturity - but there’s no guarantee that the I-D will in fact get to the same maturity level. > On Jan 4, 2018, at 17:29, Martin Thomson <[email protected]> wrote: > > On Fri, Jan 5, 2018 at 3:39 AM, Mateusz Jończyk <[email protected]> wrote: >> W dniu 04.01.2018 o 16:52, Stephen Farrell pisze: >>> I'm fairly sure I'm against attempting to handle captive portal issues at >>> the TLS layer. Any changes to TLS needed for captive portals ought really >>> garner consensus within the capport wg and then be discussed here. (It >>> looks from the archive of that wg that this topic hasn't even been raised >>> there despite a few people suggesting that, which is IMO another reason to >>> reject this proposal now.) >> >> Captive portals != filtering, these are AFAIK different problems and need >> mostly different solutions. I just integrated them under the same umbrella >> because they initially both used to seem to benefit from adding alert >> messages >> to TLS (but that idea is dead now). >> >> I am not certain whether adding captive_portal AlertDescription to TLS would >> be of benefit. It seems to me that possibly yes, but haven't reviewed this. > > Please take that discussion to the capport WG ([email protected]). > > However, it seems like you want to address filtering/censorship more > than you want to address the captive portal case. I can say that the > capport WG isn't interested in anything that might improve filtering > or censorship and are explicitly designing mechanisms that avoid doing > so. I won't say that you can't raise the issue, but you should be > aware that this topic has been discussed quite a bit already and > unless you have new information, I doubt you will change the > conclusions. > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
