Pieter,
I'm satisfied with your explanations.
Thanks,
Paul
On 12/15/25 7:40 AM, Pieter Kasselman wrote:
Thanks for the thoughful feedback Paul, much appreciated,
comments/follow-up inline below:
On Fri, Dec 12, 2025 at 9:47 PM Paul Kyzivat
<[email protected]
<mailto:[email protected]>> wrote:
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<https://wiki.ietf.org/en/group/gen/GenArtFAQ
<https://wiki.ietf.org/en/group/gen/GenArtFAQ>>.
Document: draft-ietf-oauth-cross-device-security-13
Reviewer: Paul Kyzivat
Review Date: 2025-12-16
IETF LC End Date: 2025-12-16
IESG Telechat date: ?
Summary:
This draft is on the right track but has open issues, described in the
review.
Major issues: (1)
1) ISSUE: Confusing diagrams
Sect1ons 3.1.*, 3.2.1, 4.n.* contain flow diagrams that support the
text. I found the text to be clearer than the diagrams. Particularly, I
found the bidirectional arrows confusing; and also the looping arrows
(User Start Flow). If I read the text description first, and use the
diagram as support, then it seems ok. But, because the diagrams appear
before the text description, I first spent time trying to understand
the
diagrams, and being confused by them, before reading the description.
Also, as an example, in 3.1.1, step (C) involves two actions by
separate
actors: (C1) consumption device displays the QR code, and (C2) User
uses
the authentication device to scan the QR code. The diagram doesn't show
the user involvement in this step.
I won't try here to enumerate all such problems. I'll leave that for
you. But I'm willing to do a more detailed analysis if you wish.
I do think it is important for the reader to understand these, so I
think it is worth some effort to make these diagrams clearer.
Thanks for pointing this out. When you are steeped in a document, it is
easy to become blind to the diagrams or text.
The diagrams were meant to be "read" in conjunction with the text to
convey the flows and the subsequent exploits. They were derived from
pre-existing diagram and conventions in the original specification to
help readers familiar with those documents. I will review the diagrams,
focusing especially on the confusing elements you helpfully called out
(double arrows and looping arrows), and compare these with the original
diagrams in the referenced specifications to identify areas for
improvement. I opened an issue to track this and will prepare a PR
(https://github.com/oauth-wg/oauth-cross-device-security/issues/208
<https://github.com/oauth-wg/oauth-cross-device-security/issues/208>).
If there are additional suggestions, please add them there.
Nits/editorial comments: 3
1) NIT: Missing definitions: phishing & social engineering
The terms "phishing" and *social engineering* are used extensively in
this document. They are in common use, and most readers of this
document
can be expected to have some understanding of them. But they might not
all have the same definitions. I think it would be a good idea for you
to provide your own definitions, or cite some.
Defining phishing or soccial engineering is out of scope for this
document. Instead, I will add a reference to the NIST Computer Security
Resource Center glossary instead (see issue:
https://github.com/oauth-wg/oauth-cross-device-security/issues/207
<https://github.com/oauth-wg/oauth-cross-device-security/issues/207>)
2) NIT: Possible downrefs
IdNits reports several possible downrefs to normative non-RFC
documents:
[CIBA], [CAEP], [SSF], [W3CWebAuthn], [FIDOCTAP22], [IEEE802154]
These are probably fine. But I'm not sure that any of these need to be
*normative* references, as they are all used as examples. Consider
making them non-normative.
The few other things reported by IdNits are bogus.
The normative/non-normative split of references arose during shepherd
review. The references were made normative because they either reference
the actual protocols being exploited (CIBA), or describe technologies
and capabilities that act as mitigations or alternatives. For example,
if you want to replace device authorization code flows with the
authorization code flow using FIDO2/WebAuthn and have a cross device
capability, you have to use [FIDOCTAP22] (e.g.. FIDO2/WebAuthn SHOULD be
used for cross-device authentication scenarios whenever the devices are
capable of doing so and a suitable FIDO credential is not available on
the Consumption Device.)
3) Comment:
(I don't think this is an issue or a nit, but do want to make the
point.)
Throughout the document QR codes and PIN codes are discussed as roughly
equivalent. But QR codes carry much more potential risk, because
dereferencing the URL in a QR code can cause almost anything to happen,
without the user knowing. So a cross-device flow that is designed to
use
a QR code can have the effect of desensitizing the user to the
potential
risk of scanning a QR code that is received in the context of a fishing
attackg.
I'm not sure what, if anything, this document should do about this.
Perhaps there should be another document: QR Code Security Best
Practices.
I think the general treatment of QR code security is out of scope of
this document. I agree it may be a topic for a future document.
_______________________________________________
OAuth mailing list -- [email protected] <mailto:[email protected]>
To unsubscribe send an email to [email protected]
<mailto:[email protected]>
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
