-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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.
>
> I don't find the more-transparent-censorship argument offered convincing.
> If DNS-based censorship is offered as the motivation (as opposed to or in
> addition to captive portals) then I think that'd require chatting with the
> dnsop folks, who are already discussing DNS-RPZ.
Thanks for mentioning DNS-RPZ, I wasn't aware of it.
It isn't only about DNS-based filtering, but also about blocking access to
specific IPs:
iptables -t nat -A OUTPUT --destination sex.com \
--jump DNAT --to-destination banned-page-server.local
as well as filtering packets on the HTTPS layer without MITM (the dreaded
middleboxes).
> I'd guess, (but not sure as it's not my fav. idea;-), that might throw up a
> requirement that censorship might only be done for a few minutes while some
> previously unseen name was checked out, or a name might be censored for
> days or weeks, if it's newly registered and some censor considers that a
> threat.
I was thinking more about filtering for sex, obscenity and such. That was my
primary motivation when pushing for access_administratively_disabled.
> IOW, if any changes to TLS are warranted based on DNS-based censorship,
> then those are likely more complex than has been seen in this discussion,
> and also aren't things where this list has the right expertise AFAIK.
>
> S.
>
Greetings,
Mateusz Jończyk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: My public key: 0x2C64C488 on hkp://pool.sks-keyservers.net
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJaTlipAAoJELLT9LcsZMSIX9YIAKHh5kcWPzSUsn6I5kIVIIna
CRwvxFVL933e7h99mi7D4/mSifUsFCOAsna3YLMzBjsKgABNTivLyGU8iUuQu+B0
4tq0vxHRUnuVy4OmwJrvl2IT42rTXqUP6GAjhh1HLPoEAiDL5WlthQi7AaKkYiBu
baPGCKjNZaPTT0+B+/OCp9IZW84BkcW4rwzWweynLZgDQd74CIEb2SiWqA+SAPxs
OtzClEIjdnRSPhsTcwA7G1aBqStNQAhgP/O/K+FTuqK2+n6vJhwkQLGwo0B+SXlz
nBVBI2MTEqx6K7ngLE/7UEibqyPIIJZ/i9H11/EAk3pJ19+IGnuXgix1zM30vqA=
=GJXR
-----END PGP SIGNATURE-----
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
