Dear authors
Please find a few, mostly high-level comments/discussions. I am sorry if
they all sound very critical. I really only have one fundamental
scope issue, which is that i care about end-to-end-encryption
much broader and much more indirect than your Internet RFC8990
end-user scope currently seems to be. The rest of feedback is
all on execution/text.
Having said this: I do think it would be great if we
had a document to provide information / definitions about
end-to-end security. The fact that this was seemingly not done
by core security experts so far may also be an indication of what
a daunting exercise this may be. So don't be too dismayed for all
the critical feedback from me an others.
--
Q: Who should read this document, for what purpose and what are for each possible audience type actionable outcomes after having read the document ?
Don't answer here. Write that into the start of the introduction please. Remove your research person head, put on a sales person head for the document in the intro.
> Instead the end- to-end principle, which is well established [RFC3724] in internet standards and introduces nuance, is described in the following sub- section.
Convoluted. Suggest to rephrase.
> it is now widely accepted that the communication system itself begins and ends with the user [RFC8890].
That is a misinterpetation of RFC8990. Just because RFC8890 promotes
the idea of building the Internet for end-users does not mean all use of
the Internet is for end-users.
It is also by implication severely limiting the scope of the document:
just because the Internet is well-known does not mean that any communication
system (or more specifically TCP/IP networks) are part of the Internet.
End-to-end-encryption is as valuable for (global) M2M communications as for
End-users. If you do not want to bother, then please change title and
scope of document to the much more constrained scope of end-to-end-encryption
for Internet End-Users (according to rfc8890).
[standard Toerless rant 001]
I always like to show an iceberg where the 10% on the surface is the
Internet, and the 90% below water are all private networks, M2M
communications and the like - so i would certainly like to see that we
do not always continue to ignore these 90% of our work/protocol applied there.
Of course, i do understand how these 90% have never been the core scope of many of
this documents authors, but we already live on a planet where these
90% include (global) TCP/IP networks for power/energy, financial-markets, oil/gas exploration,
control of train, plane/airport, streets, waterway transportation, defense/military
automated systems, industrial/farming production automation and so on.
All this 90% of TCP/IP use are subject to state-actor level attacks
that can cripple civilization orders of magnitude faster and broader than any
of the current in-scope "10%" Internet for-end-user applications unless
strong end-to-end security (amongst other factors) is used.
Not to speak of all the private/commercial perpass/illegal activities and crimes
that you never learn about because it most often happens without publicity. I always
have to think about users that lost money for 3 decades because banks continued
to be getting away claiming the theft was not through failures in their systems
security (through obscurity) but through end-users-fault. Aka: we need to
provide better/easier end-to-end security for all those clueless but powerful
and life-impacting industries - and educate them better about it. Check out
research/industry literature for security breaches in IoT systems for example.
[/rant]
> Imagine people (through an application's user interface, or user agent) as components in a subsystem's design.
So People = User ? Maybe say so ?
Which subsystem , explain ?
> An important distinction to this in end-to-end encrypted systems might be configuration channels, such as the use of public key infrastructure where a third party is often used in the authentication phase to enhance the larger system's trust model. Responsible use of public key infrastructure is required in such cases, such that the end-to- end encrypted system does not admit third parties under the user's identity.
What is the distinction ?
En-passant mentioning PKI does not help here. Suggest to move to
separate section/chapter and be more elaborate/precise about
the problem that e.g.: whenever PKI is used, and not self-built
by the communicating end-users, that there is an extremely complex
step of vetting the privacy and confidentiality of the end-to-end
encrypted communications of the end-users against the entities
running the PKI.
Aka: end-to-end-encryption effectively can have models with or
without trusted third parties. Whenever you use a PKI that is
not wholly instantiated/run by one of the communicating end-users,
you are talking about a trusted third party.
> User agent and user cannot be equated
What is a user agent ? reference or define.
> 2.2 End-to-end principle
I find that whole section a great start for some "internet-history"
document, but i have no idea how it would be helpful insted of hurtful
for this document.
Lets imagine an alternative reality where Europe would have won
the TCP/IP vs. ISO/OSI wars in the 1990th, and we would have instead of
the TCP/IP Internet only a global X.25 network - which is actually the only global network
i think we had for "the public" before the Internet.
[ hey, it is october, so we are all under obligation to tell horror stories until Halloween, right ? ]
So no end-to-end principle for the global network and transport layer in this alternative reality.
How would the value and need for end-to-end encryption be any different
in this alternative reality ? I am sure if it would have had to
evolve in exactly the same fashion and for the same benefits.
In fact i think if this document has to have any value on itself
beside the end-to-end principle documents we already have, then it is to
achieve exactly the opposite to what 2.2 reads:
Establish end-to-end-encryption as a whole independent valuable/required
property from the TCP/IP end-to-end principle.
For this goal IMHO it would be more valuable to show / explain examples
which exactly are NOT relying on the TCP/IP end-to-end principle.
Obviously not the Halloween story from avove but something that exists.
For example in CDN(I), we often have end-to-end (Origin to User) encryption
of the payload segments so even the most overpriced hollywood content can be monetized.
But the actual hop-by-hop communications via the Internet and via intermediates such as
web-caches and other CDN functions is neither following end-to-end principles,
but strives from all type of middle-actors. This communications does not need
to be encrypted hop-by-hop or segment-to-segment, but whether or not additional
encryption is used there depends again on business considerations
of those segment operators. Most complex in CDNI of course. And yes, today
every transport you see is likely TLS, but thats not end-to-end TLS in the
meaning i think you are trying to define. Or else we would be at a definition
of end-to-end encryption solely for transport protocols aross IP/IPv6.
Aka: I'd remove 2.2 or better argue for end-to-end encryption as
wholly independent of the TCP/IP end-to-end principle.
> 2.4. Concise definition of end-to-end security
I would start with a picture showing some potentially complex
end-user-system, a complex networkb between them, a line for the
end-to-end encryption and some out-of-band systems such as PKI and
then explain with reference to that picture how end-to-end encryption
protects against observation and modification attachs from within the
network, but not for attachs and the end-user-system or the
out-of-band system. At least as a start, and then go from there and see how
much useful refinemenet/detail can be added.
> Deniability
I think that term should be made more specific, eg. "Originator Deniability".
otherwise it is as useless/vague as "Trust". For example, in other systems, such as
disk encryption (TrueCrypt etc.) "plausible deniability" is a term to
even deny the existance of encrypted data. And should have probavbly be called
now (in comparison) "plausible Existance Deniability". Same of course in steganographic
encryption mechanisms.
> 4.2. Providers are trustworthy
Please add a section about "verifyability" and discuss. Aka: The most trustworthy
systems are those that can independently be verified. But then of course you have
to trust the third art doing the verification as well. And how well that
did not work even for the most core of end-to-end-end encryption (OpenSSL)
with public domain software should be seen as one of the core challenges of
end-to-end encryption.
The other aspect of course is that trustworthyness in the absolute terms
you describe it is today an illusion. If you or your communication partners
are on a list of interested persons of the largest state-level actors,
the chances of your end-systems to be attacked to break the end-to-end-encryption
or worse just goes up exponentially. I can imagine how the authors would
fear to make any such statements, but likewise will the usefulness of this
document suffer if it does not. At least think how to rewrite/tone-down this
section so it does not appear to be too naive (which unfortunately this
section does to me right now).
Of course, "providers" such as software/operating system vendors at least
in the USA are typically doing their best to make their systems trustworthy, but
because of Edward Snowden and others, we also have a pretty good idea about the
degree of attacks possible. And Canary letters also do not exist for fun.
The main issue btw. is the attack surface size IMHO. If you have router
operating system or user endpoint software with in excess of 100 million
lines of code and only insufficiant internal isolations, then it is
by all mens and purpose practically impossible to make such a system
trustworthy against state-level attacks.
Again: Thanks for the work, would be great if you would not give up
but continue to improve this document!
Cheers
Toerless
I don't think you can or at least SHOULD NOT use rfc2119 language in this document
On Tue, Oct 11, 2022 at 05:01:03PM +1300, Brian E Carpenter wrote:
> Hi,
>
> I assume this draft has been discussed widely in the Security Area, to
> have reached last call, but I don't follow discussions there, so I'm
> sorry if my comments are repetitive.
>
> > These dimensions taken as a whole comprise a generally comprehensible picture of consensus at the IETF as to what is end-to-end encryption,
>
> I'm not sure that we have any real consensus about this. I guess this
> last call will tell us.
>
> > Instead the end-to-end principle, which is well established [RFC3724] in
> > internet standards
>
> I think, if you follow the breadcrumbs from that RFC, the conclusion
> is more that the original e2e principle has been dubious for many years.
> RFC8799 (not an IETF document) suggests that the notion of an Internet
> that supports the e2e principle as a universal is now history. It really
> isn't "established in Internet standards"; I would argue that there are
> standards and BCPs that militate against it, and that there are many
> deployment mechanisms in use that explicitly don't adhere to it (CDNs
> being the most blatant example). When you think you are connecting
> to www.ietf.org, you aren't.
>
> > Encryption is fundamental to the end-to-end principle.
>
> That simply isn't true. The e2e principle was propounded when "security
> considerations are not discussed in this memo" occurred in most RFCs
> and line-speed cryptography was a pipe dream.
>
> Certainly the e2e principle would, I think, always have considered
> encryption/decryption to be among the "required end-to-end functions
> [that] can only be performed correctly by the end-systems themselves"
> [Saltzer, et al]. But that's the opposite statement: The e2e principle
> is fundamental to encrypted communication.
>
> > Example snippet:
>
> Is this a quotation, or what? Incidentally, the [komlo] reference is 404.
>
> > Earlier in this document end-to-end encryption was defined using formal
> > definitions assumed by internet protocol implementations.
>
> I can't find the earlier text that does this, can we have a more precise
> cross-reference?
>
> > the reader can be confident that current deployments of end-to-end encrypted technologies in the IETF indicate the cutting edge of their developments,
>
> That reader would have more confidence in the IETF than I do ;-).
>
> Section 3.2 and all of section 4 seem very aspirational to me but not
> in the least surprising, and they don't tell me what I should do
> differently in my next protocol design. What should be changed in
> RFC3552 (BCP72)? What should the Security Area be doing differently?
>
> Regards
> Brian Carpenter
>
> On 11-Oct-22 10:21, The IESG wrote:
> >
> > The IESG has received a request from an individual submitter to consider the
> > following document: - 'Definition of End-to-end Encryption'
> > <draft-knodel-e2ee-definition-07.txt> as Informational RFC
> >
> > The IESG plans to make a decision in the next few weeks, and solicits final
> > comments on this action. Please send substantive comments to the
> > last-call@xxxxxxxx mailing lists by 2022-11-14. Exceptionally, comments may
> > be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning
> > of the Subject line to allow automated sorting.
> >
> > Abstract
> >
> >
> > End-to-end encryption is an application of cryptography mechanisms
> > and properties in communication systems between endpoints. End-to-
> > end encrypted systems are exceptional in providing both security and
> > privacy properties through confidentiality, integrity and
> > authenticity features for users. Improvements to end-to-end
> > encryption strive to maximize the user's security and privacy while
> > balancing usability and availability. Users of end-to-end encrypted
> > communications expect trustworthy providers of secure implementations
> > to respect and protect them.
> >
> >
> >
> >
> > The file can be obtained via
> > https://datatracker.ietf.org/doc/draft-knodel-e2ee-definition/
> >
> >
> >
> > No IPR declarations have been submitted directly on this I-D.
> >
> >
> >
> >
> >
> > _______________________________________________
> > IETF-Announce mailing list
> > IETF-Announce@xxxxxxxx
> > https://www.ietf.org/mailman/listinfo/ietf-announce
>
> --
> last-call mailing list
> last-call@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/last-call
--
---
tte@xxxxxxxxx
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
