Re: [TLS] access_administratively_disabled v2

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

Re: [TLS] access_administratively_disabled v2

On Fri, Jan 5, 2018 at 3:39 AM, Mateusz Jończyk 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 cappor

Re: [TLS] access_administratively_disabled v2

-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

Re: [TLS] access_administratively_disabled v2

On Thu, Jan 4, 2018 at 7:22 AM, Mateusz Jończyk wrote: > W dniu 04.01.2018 o 16:00, Salz, Rich pisze: > > > >>Yes, at least in corporate environments, parental control solutions, > etc. > > This will give a more understandable message to the user. > > > > > > But as others have pointed ou

Re: [TLS] access_administratively_disabled v2

On 04/01/18 14:22, Eric Rescorla wrote: > I am not in favor of this change at this time. Same here. > > I suspect I'm not in favor of the mechanism, but i'm definitely not in > favor of > adding a placeholder alert for some mechanism which isn't specified. I'm fairly sure I'm against attempti

Re: [TLS] access_administratively_disabled v2

W dniu 04.01.2018 o 16:00, Salz, Rich pisze: > >>Yes, at least in corporate environments, parental control solutions, etc. > This will give a more understandable message to the user. > > > But as others have pointed out, the alert is not signed by the target origin. > So anyone along the pa

Re: [TLS] access_administratively_disabled v2

>Yes, at least in corporate environments, parental control solutions, etc. This will give a more understandable message to the user. But as others have pointed out, the alert is not signed by the target origin. So anyone along the path can inject this alert. So browsers cannot trust

Re: [TLS] access_administratively_disabled v2

On Thu, Jan 4, 2018 at 6:43 AM, Mateusz Jończyk wrote: > W dniu 04.01.2018 o 15:22, Eric Rescorla pisze: > > > > > > On Thu, Jan 4, 2018 at 2:46 AM, Mateusz Jończyk > > wrote: > > > > W dniu 03.01.2018 o 18:05, Benjamin Kaduk pisze: > > > On 01/03/2018 10:17 AM,

Re: [TLS] access_administratively_disabled v2

W dniu 04.01.2018 o 15:22, Eric Rescorla pisze: > > > On Thu, Jan 4, 2018 at 2:46 AM, Mateusz Jończyk > wrote: > > W dniu 03.01.2018 o 18:05, Benjamin Kaduk pisze: > > On 01/03/2018 10:17 AM, Mateusz Jończyk wrote: > >> Judging from TLS1.3's problems with m

Re: [TLS] access_administratively_disabled v2

On Thu, Jan 4, 2018 at 2:46 AM, Mateusz Jończyk wrote: > W dniu 03.01.2018 o 18:05, Benjamin Kaduk pisze: > > On 01/03/2018 10:17 AM, Mateusz Jończyk wrote: > >> Judging from TLS1.3's problems with middleboxes, content filtering > isn't so > >> rare, especially in the corporate world. > >> > >> T

Re: [TLS] access_administratively_disabled v2

W dniu 04.01.2018 o 14:32, Salz, Rich pisze: > ➢ https://github.com/tlswg/tls13-spec/pull/1134 > … > This will make censorship more transparent. > > Only if the censor agrees to use that alert to indicate what they are doing. > Do you really think that will happen? > Yes, at least in

Re: [TLS] access_administratively_disabled v2

➢ https://github.com/tlswg/tls13-spec/pull/1134 … This will make censorship more transparent. Only if the censor agrees to use that alert to indicate what they are doing. Do you really think that will happen? ___ TLS mailing list TLS@ietf.

Re: [TLS] access_administratively_disabled v2

W dniu 04.01.2018 o 11:46, Mateusz Jończyk pisze: > W dniu 03.01.2018 o 18:05, Benjamin Kaduk pisze: >> On 01/03/2018 10:17 AM, Mateusz Jończyk wrote: >>> Judging from TLS1.3's problems with middleboxes, content filtering isn't so >>> rare, especially in the corporate world. >>> >>> The provider of

Re: [TLS] access_administratively_disabled v2

W dniu 03.01.2018 o 18:05, Benjamin Kaduk pisze: > On 01/03/2018 10:17 AM, Mateusz Jończyk wrote: >> Judging from TLS1.3's problems with middleboxes, content filtering isn't so >> rare, especially in the corporate world. >> >> The provider of filtering services (for example OpenDNS) / middlebox >>

Re: [TLS] access_administratively_disabled v2

On 01/03/2018 10:17 AM, Mateusz Jończyk wrote: > Judging from TLS1.3's problems with middleboxes, content filtering isn't so > rare, especially in the corporate world. > > The provider of filtering services (for example OpenDNS) / middlebox > manufacturer would have to recognize if the client suppo

Re: [TLS] access_administratively_disabled v2

W dniu 03.01.2018 o 17:08, Russ Housley pisze: > Mateusz: > > How do you see IANA controlling which parties get certificates for the > access_administratively_disabled.net domain? IANA is just an example, there could be some other provider controlling the access_administratively_disabled.net dom

Re: [TLS] access_administratively_disabled v2

W dniu 03.01.2018 o 17:31, Eric Rescorla pisze: > > > On Wed, Jan 3, 2018 at 8:17 AM, Mateusz Jończyk > wrote: > > W dniu 03.01.2018 o 16:28, Eric Rescorla pisze: > > Well, this seems like the first arm, in which you change the browser, > so the > > questi

Re: [TLS] access_administratively_disabled v2

On Wed, Jan 3, 2018 at 8:17 AM, Mateusz Jończyk wrote: > W dniu 03.01.2018 o 16:28, Eric Rescorla pisze: > > > > > > On Wed, Jan 3, 2018 at 6:45 AM, Mateusz Jończyk > > wrote: > > > > W dniu 03.01.2018 o 14:19, Eric Rescorla pisze: > > > I have several comments:

Re: [TLS] access_administratively_disabled v2

W dniu 03.01.2018 o 16:28, Eric Rescorla pisze: > > > On Wed, Jan 3, 2018 at 6:45 AM, Mateusz Jończyk > wrote: > > W dniu 03.01.2018 o 14:19, Eric Rescorla pisze: > > I have several comments: > > > > - This is almost entirely out of scope for TLS, so yo

Re: [TLS] access_administratively_disabled v2

Mateusz: How do you see IANA controlling which parties get certificates for the access_administratively_disabled.net domain? Russ P.S. If I recall RFC 1034 and 1035 correctly, domain name labels may contain only letters, digits, and hyphen. Underscore is not allowed. > On Jan 3, 2018, at 7

Re: [TLS] access_administratively_disabled v2

On Wed, Jan 3, 2018 at 6:45 AM, Mateusz Jończyk wrote: > W dniu 03.01.2018 o 14:19, Eric Rescorla pisze: > > I have several comments: > > > > - This is almost entirely out of scope for TLS, so you should start with > > CAPPORT. If they're interested, then we can discuss the code point > assignmen

Re: [TLS] access_administratively_disabled v2

W dniu 03.01.2018 o 14:19, Eric Rescorla pisze: > I have several comments: > > - This is almost entirely out of scope for TLS, so you should start with > CAPPORT. If they're interested, then we can discuss the code point assignment > in > TLS. > > - You point #2 would effectively require either

Re: [TLS] access_administratively_disabled v2

I have several comments: - This is almost entirely out of scope for TLS, so you should start with CAPPORT. If they're interested, then we can discuss the code point assignment in TLS. - You point #2 would effectively require either changes to the browser or CA issuance policies (the BRs would pro

[TLS] access_administratively_disabled v2

Hello, Based on Your feedback (for which I am grateful) I have designed a new version of the access_administratively_disabled mechanism. 1. One new AlertDescription value should be specified: access_administratively_disabled. 2. The information why the webpage is blocked is specified at the URL h