Re: [OAUTH-WG] MTLS vs. DPOP

[Brian Campbell <[e-mail]>]

Practically speaking there's the MTLS draft, which has been sent to the
IESG for publication, has commercial and opensource implementations as well
as production deployments, and is referenced by other prospective standards
and profiles. It's not uncommon to receive off list inquires about the
document status from people involved in those things asking when it will be
"finished". Which is to say that there's a good amount of interest from the
community at large in seeing the MTLS document go to RFC. And it's
relatively close to doing so (as these things go anyway). The DPoP
document, on the other hand, is currently an individual draft submission.
And while it has generated some good interest and discussion, it is only an
individual draft submission and carries the same authority as any other
individual draft submission (see
https://tools.ietf.org/html/draft-abr-twitter-reply-00 for example). I
believe that the MTLS draft should continue on the it's course. And am
interested in seeing where we can take the DPoP work and if the WG wants to
take it on.

Your point about the "PR" perspective is taken. And I probably shouldn't
even bring these up but that whole situation is exacerbated by the
expired/dormant WG documents like draft-ietf-oauth-token-binding and
draft-ietf-oauth-signed-http-request. Some organizations out there touting
their support for RFC 7800 as a complete solution in the
pop/sender-constrained space aren't helping matters either. So while I
think I hear what you are saying, I don't personally see much of anything
reasonable or actionable that can done about it.




On Tue, May 7, 2019 at 9:45 AM Vittorio Bertocci <Vittorio=
[e-mail]> wrote:

> To clarify, I wasn’t suggesting we drop one or the other. Both have their
> merit and use cases, and both should be developed all the way to standard
> IMO. But from some preliminary exploration, it seems unlikely that services
> will adopt both at the same time. From the “pr” perspective, having a clear
> _default_ answer to the question “how do I add sender constraint
> capabilities to my service?” would greatly enhance the chances of getting
> something out in the real world quickly, make it possible to interop and
> iron out wrinkles, etc etc-
> For the general developer populace, at this point “sender constraint”
> remains something vaguely exotic and often decisions made on that (like the
> ones on the implicit deprecation) are poorly received. Even the ones who
> had exposure had been somewhat “burned” by how token binding is going, and
> we are in need for something easy to grok and actionable to rekindle
> interest IMO. The sooner we can get the concept mainstream the better.
>
> On Tue, May 7, 2019 at 07:13 George Fletcher <gffletch=
> [e-mail]> wrote:
>
>> I don't see them the same at all. With MTLS, the token is bound to the
>> transport layer (and the key used to establish that encrypted connection).
>> With DPOP, the token is bound to the private key known to the client.
>>
>> To compromise an MTLS bound token the attacker has to compromise the
>> private key. To compromise a DPOP bound token, depending on what HTTP
>> request elements are signed, and whether the DPOP is managed as
>> one-time-use etc, there are additional attacks. (Ducks head and waits for
>> all the real security experts to prove me wrong:)
>>
>> The deployment models are also different. With MTLS bound tokens the
>> clients don't really have to know about the binding because it is
>> established at the AS and the deployment of the service manages the cert
>> used for the MTLS connection. This is simpler for client development
>> (provided the environment is already set up for MTLS everywhere).
>>
>> I'd strong encourage us to continue supporting both methods.
>>
>> On 5/7/19 4:25 AM, Hannes Tschofenig wrote:
>>
>> Hi all,
>>
>> ?
>>
>> In the OAuth conference call today Vittorio mentioned that some folks are
>> wondering whether DPOP is essentially a superset of MTLS and whether it
>> makes sense to only proceed with one solution rather potentially two.
>>
>> ?
>>
>> I was wondering whether others in the group have a few about this aspect?
>>
>> ?
>>
>> Ciao
>>
>> Hannes
>>
>> ?
>> IMPORTANT NOTICE: The contents of this email and any attachments are
>> confidential and may also be privileged. If you are not the intended
>> recipient, please notify the sender immediately and do not disclose the
>> contents to any other person, use it for any purpose, or store or copy the
>> information in any medium. Thank you.
>>
>> _______________________________________________
>> OAuth mailing [e-mail]://www.ietf.org/mailman/listinfo/oauth <https://www..ietf.org/mailman/listinfo/oauth>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._