Re: [TLS] Captive portals, "access administratively disabled" and alert messages

2018-01-02 Thread Lanlan Pan
Eric Rescorla 于2018年1月3日周三 上午5:57写道： > On Tue, Jan 2, 2018 at 1:40 PM, Mateusz Jończyk wrote: > >> CCing Ted Lemon as the author of previous >> proposition. >> >> W dniu 02.01.2018 o 21:20, Eric Rescorla pisze: >> > On Tue, Jan 2, 2018 at 12:08 PM, Mateusz Jończyk > > >

Re: [TLS] Captive portals, "access administratively disabled" and alert messages

2018-01-02 Thread Geoffrey Keating
Two problems with this proposal, that don't occur with the proposal the capport WG is working on, are: - What do you do if you get one of these alerts over multipath TCP? - What happens if some site far away on the Internet sends you one of these alerts? Perhaps because DNS was forged and hasn

Re: [TLS] Captive portals, "access administratively disabled" and alert messages

2018-01-02 Thread Ted Lemon
We had a conversation about this at a Boston IETF meetup last year; the consensus, with which I agree, is that simply adding TLS alerts isn't good enough, for (essentially) the reason you stated earlier: we have no way to know that the attacker here is a good guy. E.g., in the case of the Open

Re: [TLS] Captive portals, "access administratively disabled" and alert messages

2018-01-02 Thread Eric Rescorla
On Tue, Jan 2, 2018 at 1:40 PM, Mateusz Jończyk wrote: > CCing Ted Lemon as the author of previous > proposition. > > W dniu 02.01.2018 o 21:20, Eric Rescorla pisze: > > On Tue, Jan 2, 2018 at 12:08 PM, Mateusz Jończyk > > wrote: > > > > Then the browser should dis

Re: [TLS] Captive portals, "access administratively disabled" and alert messages

2018-01-02 Thread Martin Thomson
On Wed, Jan 3, 2018 at 7:18 AM, Stephen Farrell wrote: > [...] the capport wg - I'd guess folks > there are more aware of the full range of cases that may need > handling and of how to try interpose the portal web page stuff > before other applications see the n/w as active (or whatever it > is th

Re: [TLS] Captive portals, "access administratively disabled" and alert messages

2018-01-02 Thread Mateusz Jończyk
CCing Ted Lemon as the author of previous proposition. W dniu 02.01.2018 o 21:20, Eric Rescorla pisze: > On Tue, Jan 2, 2018 at 12:08 PM, Mateusz Jończyk > wrote: > > Then the browser should display a message inside the warning screen that > the > string canno

Re: [TLS] Captive portals, "access administratively disabled" and alert messages

2018-01-02 Thread Stephen Farrell
On 02/01/18 20:08, Mateusz Jończyk wrote: >> I'm not really enthusiastic about any of these ideas for any of the >> administratively prohibited >> use cases because the information being provided to the user is unverifiable. >> I.e., this >> just tells you that someone on the network didn't like

Re: [TLS] Captive portals, "access administratively disabled" and alert messages

2018-01-02 Thread Eric Rescorla
On Tue, Jan 2, 2018 at 12:08 PM, Mateusz Jończyk wrote: > Hello, > Thank You for reviewing my email. > > W dniu 02.01.2018 o 20:37, Eric Rescorla pisze: > > A similar idea was proposed a while back, albeit with simpler semantics: > > > > https://tools.ietf.org/html/draft-lemon-tls-blocking-aler

Re: [TLS] Captive portals, "access administratively disabled" and alert messages

2018-01-02 Thread Mateusz Jończyk
Hello, Thank You for reviewing my email. W dniu 02.01.2018 o 20:37, Eric Rescorla pisze: > A similar idea was proposed a while back, albeit with simpler semantics: > > https://tools.ietf.org/html/draft-lemon-tls-blocking-alert-00 > > Discussion here: > > https://www.ietf.org/mail-archive/we

Re: [TLS] Captive portals, "access administratively disabled" and alert messages

2018-01-02 Thread JW
Hi, My colleagues and I are currently pursuing a TLS extension to address a very similar scenario.  It is good to see we are not alone in this pursuit. We are still working out details at a somewhat high level but expect to have a draft out shortly.  Please feel free to contact me if you would li

Re: [TLS] Captive portals, "access administratively disabled" and alert messages

2018-01-02 Thread Eric Rescorla
A similar idea was proposed a while back, albeit with simpler semantics: https://tools.ietf.org/html/draft-lemon-tls-blocking-alert-00 Discussion here: https://www.ietf.org/mail-archive/web/tls/current/msg20264.html I'm not really enthusiastic about any of these ideas for any of the adminis

[TLS] Captive portals, "access administratively disabled" and alert messages

2018-01-02 Thread Mateusz Jończyk
Hello, OpenDNS by default blocks websites that are used for phishing and optionally other sites as configured by the deployer. It does this by DNS poisoning: it responds with a forged A or response that redirects to their server. An example website blocked by OpenDNS in this manner is https:/

Re: [TLS] Draft-22 and Post-Handshake Authentication

2018-01-02 Thread Eric Rescorla
Yes, that is correct On Tue, Jan 2, 2018 at 9:06 AM, Short, Todd wrote: > Question on Post-Handshake Authentication (PHA): > > PHA can occur multiple times over a connection. The description for the > "Handshake Context” is as follows (4.4): > >| ||

[TLS] Draft-22 and Post-Handshake Authentication

2018-01-02 Thread Short, Todd
Question on Post-Handshake Authentication (PHA): PHA can occur multiple times over a connection. The description for the "Handshake Context” is as follows (4.4): | || | | Post- | ClientHello ... client | client_applica