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 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 <martin.thomson@gmail.com> wrote:
> 
> On Fri, Jan 5, 2018 at 3:39 AM, Mateusz Jończyk <mat.jonczyk@o2.pl> 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 (captive-portals@ietf.org).
> 
> 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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls