for me this thread is running a bit wild: if we don't believe that
implementers get incoming header removal right, why do we believe the same
implementers get randomizing and/or HMAC signing right
setting headers on a trusted leg between proxies and origin servers has
been a best practice for decad
I agree wholeheartedly that an HMAC or even signature is preferable.
With HMAC vs signature having their relative pros / cons, in terms of
computation and key distribution. If a standard for that is created, and
I am a web application developer, I'll be able to handle the header
checks in the appli
On 31 Oct 2019, at 18:55, Richard Backman, Annabelle
wrote:
>
>
> Relying on a fixed, random header name for security, even as a “defense in
> depth” measure, is dangerous. In order for this mechanism to be effective,
> the header name must be random (in the cryptographic sense) and must be
Hello OAuth people
Before I tune up the Reciprocal OAuth document per feedback, I'm checking
to see who is interested in the specification, and who is considering
deploying.
Alexa had the requirement originally, but I no longer work there, and I
have not seen any input from them.
Latest draft ..
Hello WG,
Just a quick note to let folks know that -03 of the DPoP draft was
published earlier today. The usual various document links are in the
forwarded message below and the relevant snippet from the doc history with
a summary of the changes is included here for convenience.
Hopefully folks w
* Relying on a fixed, random header name for security, even as a “defense
in depth” measure, is dangerous.
Thank you. +1
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Thanks for this note. According to the abstract the advertising is
intended for "request headers for proactive content negotiation"
(Accept-*), which should exclude all other types of header. I looked at
the Security Considerations and wrote to the author with the suggestion
to note that implementa
How about requiring reverse proxies to automatically scrub all inbound HTTP
headers that start with "Sec-"?
https://tools.ietf.org/html/draft-ietf-httpbis-client-hints-07
Making a header value “secret” will not protect anything.
___
OAuth mailing list
O
+10
On Thu, Oct 31, 2019 at 12:26 PM Vladimir Dzhuvinov
wrote:
> This is a good story.
>
> How about requiring reverse proxies to automatically scrub all inbound
> HTTP headers that start with "Sec-"?
>
> If a sec header has the format "Sec-[NAME]-[random-chars]" we get:
>
> * The "Sec-" prefix
This is a good story.
How about requiring reverse proxies to automatically scrub all inbound
HTTP headers that start with "Sec-"?
If a sec header has the format "Sec-[NAME]-[random-chars]" we get:
* The "Sec-" prefix will cause new compliant reserve proxies to
automatically scrub the inbound HT
> On 30. Oct 2019, at 15:15, Neil Madden wrote:
>
> On 30 Oct 2019, at 14:05, Torsten Lodderstedt wrote:
>>> On 30. Oct 2019, at 14:56, Neil Madden wrote:
>>>
>>> On 30 Oct 2019, at 13:24, Justin Richer wrote:
All of these problems can be solved, and I think solved better, by
>>
the way I see this is that stripping and setting the headers must be part
of the implementation of the protocol itself, it should not be something
left to a non-atomic piece of configuration by an administrator; I
implemented it like this in the Apache implementation of Brian's TTRP spec
[1] and ha
> All in all, I am in favor of this being defined in one standard way,
> in addition to secure communication between proxies and backends being
> standardized — but this latter bit really seems like a separate problem.
>
> — Justin
-1 for devising a well known header
+1 for a simple way to authe
13 matches
Mail list logo
