Re: [Acme] Issue: Allow ports other than 443

2015-11-23 Thread Douglas Calvert 
On Mon, Nov 23, 2015 at 12:52 PM, Martin Thomson 
wrote:

> The problem is that it the ACME server needs some sort of assurance
> that the client controls the server.  Showing control over the server
> on port 443 is probably the best signal possible.
>
> Showing control over a server on ports < 1024 might be OK.  Some
> operating systems require additional privileges to serve on those
> ports.  That said, it's not universal, though I'm not sure whether it
> matters for those cases where <1024 is available without access
> controls.
>



How does showing control over port 443 convey more information than showing
control over port 22, 80, 487, 1023?
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Issue: Allow ports other than 443

2015-11-23 Thread Martin Thomson 
On 23 November 2015 at 10:09, Douglas Calvert
 wrote:
> How does showing control over port 443 convey more information than showing
> control over port 22, 80, 487, 1023?

Basic information theory:
p(control over 443) < p(control over any port under 1024) < p(control
over arbitrary port)

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Issue: Allow ports other than 443

2015-11-23 Thread Randy Bush 
which is easier, going through kink on 443 or getting the IT security
team to punch a hole for ?

randy

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Issue: Allow ports other than 443

2015-11-23 Thread Peter Eckersley 
+1 on both Rich's request and the IANA suggestion. 

I think something that would help for this purpose would be an
Internet-wide zmap scan of some plausible ports, to ensure there isn't
anything in widespread use on them that could be a relevant attack
surface for the challenge protocols.

Anyone interested in volunteering to do some scans?

On Mon, Nov 23, 2015 at 09:52:07AM -0800, Martin Thomson wrote:
> Could we ask IANA for a reserved system port (<1024)?  Then it would
> be possible for an ACME client to operate without disturbing running
> services.
> 
> On 23 November 2015 at 08:55, Russ Housley  wrote:
> > Allowing the Web server to continue running on 443 while validation takes 
> > place on another port seems like a straightforward resolution to the issue 
> > that is raised.
> >
> > Russ
> >
> >
> > On Nov 21, 2015, at 1:03 PM, Salz, Rich wrote:
> >
> >> Please see here for the background: 
> >> https://github.com/ietf-wg-acme/acme/issues/4
> >>
> >> But discuss this on the mailing list.
> >
> > ___
> > Acme mailing list
> > Acme@ietf.org
> > https://www.ietf.org/mailman/listinfo/acme
> 
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
> 

-- 
Peter Eckersleyp...@eff.org
Chief Computer Scientist  Tel  +1 415 436 9333 x131
Electronic Frontier FoundationFax  +1 415 436 9993

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Issue: Allow ports other than 443

2015-11-23 Thread Randy Bush 
>> which is easier, going through kink on 443 or getting the IT security
>> team to punch a hole for ?
> Would it help if you could choose the option that sucked least for
> your particular situation?  That was what I was thinking.

yes, it would help

i admit to thinking of it as turning off a magic feature that wants to
get you in trouble with IT security.  we're talking about the kind of
folk who scan all internal address space and whack you if you have an
ssh port that allows password based access (i actually appreciate this
one).

randy

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Issue: Allow ports other than 443

2015-11-23 Thread Russ Housley 
Allowing the Web server to continue running on 443 while validation takes place 
on another port seems like a straightforward resolution to the issue that is 
raised.

Russ


On Nov 21, 2015, at 1:03 PM, Salz, Rich wrote:

> Please see here for the background: 
> https://github.com/ietf-wg-acme/acme/issues/4
> 
> But discuss this on the mailing list.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme