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

Re: [Captive-portals] Joel Jaeggli's No Objection on charter-ietf-capport-00-03: (with COMMENT)



On Mon, Nov 9, 2015 at 4:34 PM, Joel Jaeggli <[email protected]> wrote:
> Joel Jaeggli has entered the following ballot position for
> charter-ietf-capport-00-03: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/charter-ietf-capport/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> The CAPPORT Working Group will define secure mechanisms and protocols to
> - allow endpoints to discover that they are in this sort of limited
>   environment,
>
> I'm not personally convinced that capport will necessarily be more
> successful then DHC in securing initial signaling which strongly implies
> to me that we should not constrain it in this way.
>

Sorry, sitting on a plane about to leave NRT, and haven't fully
decoded the above.

I don't think that CAPPORT *has* to define a way to allow endpoints to
discover the CP (it can use the DHC technique if it want) -- I just
didn't want it to be out of scope if we discover a better way to do
so...

At least, I was not intending to force CAPPORT to design thier own,
and don't think that the above means that it does.

Apologies, door closing...

W


> that said I think further along in process (vending a webpage) other
> security mechanisms come into play and that seems highly likely.
>
>



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf