[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Captive-portals] FW: [TLS] FW: New Version Notification for draft-zhou-tls-server-redirect-00.txt



On 10/20/15 8:19 PM, Zhouqian (Cathy) wrote:
> Hi Joel,
> Thanks. So should this work be done in capport?

If the question is, "Is a proposal to facilitate the interception of ssl
connection attempts (enabling a man in the middle attack) by
intermediate parties appropriate work for captive portals to undertake?"
My personal opinion is no.


> Best Regards,
> Cathy 
> 
> 
>> -----Original Message-----
>> From: joel jaeggli [mailto:[email protected]]
>> Sent: Wednesday, October 21, 2015 10:13 AM
>> To: Zhouqian (Cathy); [email protected]
>> Subject: Re: [Captive-portals] FW: [TLS] FW: New Version Notification for
>> draft-zhou-tls-server-redirect-00.txt
>>
>> On 10/20/15 6:14 PM, Zhouqian (Cathy) wrote:
>>> Dear all, I submitted a new document on https applications to TLS
>>> working group. And Benjamin Kaduk from the TLS wg thinks the work may
>>> be in the scope of capport. What do you think?
>>
>> In general I would view a signal from a middle box that it is attempting hijack an
>> outstanding but unfulfilled tls connection attempt as a direct attack on my
>> attempt a secure communication.
>>
>> I think the observation by Ben is correct, in the sense that the purpose of
>> capport as proposed is to render such attempts unnecessary, at least in the
>> cast of signalling the existence  of captive portals that need to be addressed
>> before communication should continue.
>>
>> thanks
>> joel
>>
>>> Best Regards, Cathy
>>>
>>>
>>>> -----Original Message----- From: Benjamin Kaduk
>>>> [mailto:[email protected]] Sent: Tuesday, October 20, 2015 11:34 PM
>>>> To: Zhouqian (Cathy); [email protected] Subject: Re: [TLS] FW: New Version
>>>> Notification for draft-zhou-tls-server-redirect-00.txt
>>>>
>>>> On 10/20/2015 01:38 AM, Zhouqian (Cathy) wrote:
>>>>> Dear all, This is a new document we have submitted on the TLS
>>>>> extension for server
>>>> redirect. It aims to solve the problems in some applications, e.g.,
>>>> HTTPS redirect.
>>>>> The "Hello Extensions" message is extended and a new TLS handshake
>>>>> packet
>>>> is defined to support this kind of applications.
>>>>> Your comments are welcome.
>>>>>
>>>>
>>>> I am not sure I understand the "overdue" use case, but the "web
>>>> authentication" use case sounds like an ordinary captive portal;
>>>> there's a proposed "capport" working group exclusively for handling
>>>> captive portals (https://datatracker.ietf.org/wg/capport/) which
>>>> might be worth visiting.  The "overdue" use case might also be
>>>> considered a captive portal, but I can't quite tell given the current
>>>> description.
>>>>
>>>> In any case, it is far from clear that HTTP-specific issues should be
>>>> handled at the TLS layer -- TLS is a generic secure channel protocol
>>>> used in many applications other than HTTPS.
>>>>
>>>> -Ben Kaduk
>>>
>>> _______________________________________________ Captive-portals
>>> mailing list [email protected]
>>> https://www.ietf.org/mailman/listinfo/captive-portals
>>>
>>
> 
> 


Attachment: signature.asc
Description: OpenPGP digital signature