- From: Mike Bishop <Michael.Bishop@microsoft.com>
- Date: Fri, 15 Jan 2016 19:10:33 +0000
- To: Barry Leiba <barryleiba@computer.org>, Kari Hurtta <hurtta-ietf@elmme-mailer.org>
- CC: Mark Nottingham <mnot@mnot.net>, "Julian F. Reschke" <julian.reschke@gmx.de>, "draft-ietf-httpbis-alt-svc@ietf.org" <draft-ietf-httpbis-alt-svc@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
But on the other hand, a publisher who wanted to enable opportunistic could publish /.well-known/alternative-services easily enough. In that it closes the ability for one resource owner to claim authority over the entire machine, I like it. It seems like a reasonable middle ground between always requiring strong auth and leaving things totally open. A more effective middle ground than looking at port numbers, certainly. -----Original Message----- From: barryleiba@gmail.com [mailto:barryleiba@gmail.com] On Behalf Of Barry Leiba Sent: Friday, January 15, 2016 11:08 AM To: Kari Hurtta <hurtta-ietf@elmme-mailer.org> Cc: Mark Nottingham <mnot@mnot.net>; Mike Bishop <Michael.Bishop@microsoft.com>; Julian F. Reschke <julian.reschke@gmx.de>; draft-ietf-httpbis-alt-svc@ietf.org; HTTP Working Group <ietf-http-wg@w3.org>; Stephen Farrell <stephen.farrell@cs.tcd.ie> Subject: Re: (Possibly duplicate mail) Suggesting /.well-known/alternative-services as compromise | Re: AD review of draft-ietf-httpbis-alt-svc-10 > I think that this stops that attack if http client also checks > /.well-known/alternative-services when alternative service does not > provide strong auth. This of course adds additional delay before > alternative service is used but does not affect case where alternative > services is used for opportunistic security (I assume strong auth here > and therefore GET /.well-known/alternative-services is not needed). No, with opportunistic encryption you *don't* have strong auth -- that's part of what makes it opportunistic. Barry
Received on Friday, 15 January 2016 19:11:04 UTC