Re: [Last-Call] Last Call: <draft-knodel-e2ee-definition-07.txt> (Definition of End-to-end Encryption) to Informational RFC

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 11 October 2022 04:01 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4118C152595; Mon, 10 Oct 2022 21:01:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4EubhEPN4Ah; Mon, 10 Oct 2022 21:01:10 -0700 (PDT)
Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01A94C14F693; Mon, 10 Oct 2022 21:01:09 -0700 (PDT)
Received: by mail-pj1-x1033.google.com with SMTP id b15so11434325pje.1; Mon, 10 Oct 2022 21:01:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=Af10YAm5GIFKcHGOqQdztPAuLHvKvtB2NZCr8irdljw=; b=dRbgVjlSutTzAGbjA/r+HrvKIZC3speR1LY7Ta7GWWhbwrvQ5HCrGPG7UtOV2BZ4z3 355VlEaBBDsmUpND7j0XSHc/9eD61M5Q4W3S8/2e3Pst9AP0GBDEyEvfT7RLver1Yz6R iEA/WF2GIz83fX3gzWIPkgQeOkyfMQUgtIcplx8JUOkTuZCRt6zrPvyzsjeA6KZrsQ34 Th3Jf/QExvAlqkCP/evw/P5ARjBQ+S6Qsg/02DbvyjDg/rUpJW7fgurKO9xOmeirxXzL nAp5VP1vItkC9B8DCbSsiEueCj2wOeMcPH86CgSXHvDUskJ0wM5AhdJrWKVPrM1DpbUz 7/cw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Af10YAm5GIFKcHGOqQdztPAuLHvKvtB2NZCr8irdljw=; b=qTY2kIWZOv/+lKh1GedXpXL31zO1R5ZpOKvckOlfqJU3yJK11cIAwZuRgJxyZNVpeJ GvJphzdW0mRzkfiqhZoPaz9G7waH3CjQlZg1BBWCVBQAze8/+Cmf1eje1qWz1rgvP8hF WGQaruSCIRs9SuWJVM6HBdFGi/SdXTFXD8+7Nb5vZTgXi5lFRB3yotYU9tMliqIUxHcS qC6uw2/t2Dubf6mvfNQxVWfwn0/DXyN4TS/AL2kjEYWr1j6iBkLo1XBk9yXCWmjTiN90 hUsOpOeENVgsYdzdG7PmmCEUDn4VZUylorKUAOiKagE2IAraGz8hosnBM1ElRfQnZuM6 3cnw==
X-Gm-Message-State: ACrzQf1tGeQB6HjTvSMwLZiAk5jT9rc+jG5IL+bYGBbUEDxo7sgfjly1 /x9wR5Zw+6JJCI5Vxn8l5g12Jurf5yFfpA==
X-Google-Smtp-Source: AMsMyM6bgHiJb7XblaRVyoxNYY1HY62SIST6dAagUq1mnedgIS27h19xhGwdIGTfDX5NuBf3rap0yw==
X-Received: by 2002:a17:902:d504:b0:178:b5bd:4319 with SMTP id b4-20020a170902d50400b00178b5bd4319mr22445847plg.33.1665460869369; Mon, 10 Oct 2022 21:01:09 -0700 (PDT)
Received: from ?IPV6:2406:e003:1124:9301:80b2:5c79:2266:e431? ([2406:e003:1124:9301:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id x6-20020a628606000000b005629b6a8b53sm8010708pfd.15.2022.10.10.21.01.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 10 Oct 2022 21:01:08 -0700 (PDT)
Message-ID: <cfff9577-9f3b-46c5-3d03-cfaafe3abebf@gmail.com>
Date: Tue, 11 Oct 2022 17:01:03 +1300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0
Content-Language: en-US
To: last-call@ietf.org
Cc: draft-knodel-e2ee-definition@ietf.org, paul.wouters@aiven.io
References: <166543691624.50302.455688238167114999@ietfa.amsl.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
In-Reply-To: <166543691624.50302.455688238167114999@ietfa.amsl.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/6g4jNbuJPegCGusTkXB1Up__aOA>
Subject: Re: [Last-Call] Last Call: <draft-knodel-e2ee-definition-07.txt> (Definition of End-to-end Encryption) to Informational RFC
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Oct 2022 04:01:14 -0000

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@ietf.org mailing lists by 2022-11-14. Exceptionally, comments may
> be sent to iesg@ietf.org 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@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce