[Uri-review] Re: [saag] Re: Fwd: [IANA #1449893 ] Registration of URI scheme 'cttps'

--===============2993859883721910150==
Content-Type: multipart/alternative; boundary="000000000000b0aad406519f04ba"

--000000000000b0aad406519f04ba
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, May 12, 2026 at 7:06=E2=80=AFAM Salz, Rich <rsalz=3D
[email protected]> wrote:

> It=E2=80=99s a naive protocol and unlikely to get any uptake. An adversar=
y sitting
> along the network path can modify, or read, the initial messages and
> completely decrypt or modify the content. Thanks for posting!
>

I agree. It is severely underspecified. Even the acronym "cttps" is
expanded to both  "Crypto Transfer Protocol Secure" and "Ciphered Text
Transfer Protocol over SSL/Stream".

The request does not comply with RFC 7595 Section 3.1 which states:

    New schemes ought to have utility to the Internet community beyond that
available with already registered schemes.

As it provides no security against active attacks, it provides nothing that
https:// doesn't already supply.

The request does not comply with RFC 7595 Section 3.3 which states:

   a scheme definition itself MUST be clear as to how it is expected to
   function.  Schemes that are not intended to be used as locators
   SHOULD describe how the resource identified can be determined or
   accessed by software that obtains a URI of that scheme.

I believe the specification is completely unclear and unimplementable.

The requestion does not comply with RFC 7595 Section 3.4 which states:

   As part of the definition of how a URI identifies a resource, a
   scheme definition SHOULD define the applicable set of operations that
   can be performed on a resource using the URI as its identifier.

This is completely missing from the request.

Finally, RFC 7595 Section 3.7, "Clear Security and Privacy Considerations"
is clearly missing in its entirely,
and the scheme seems to be completely insecure against active attackers.


This provisional registration should be rejected by the Designated Experts.

Paul

--000000000000b0aad406519f04ba
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><div class=3D"gmail_quote gmail=
_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, May 12, 202=
6 at 7:06=E2=80=AFAM Salz, Rich &lt;rsalz=3D<a href=3D"mailto:40akamai.com@=
dmarc.ietf.org">[email protected]</a>&gt; wrote:<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex">



<div>
<div style=3D"direction:ltr;font-family:Aptos,Arial,Helvetica,sans-serif;fo=
nt-size:12pt;color:rgb(0,0,0)">
It=E2=80=99s a naive protocol and unlikely to get any uptake. An adversary =
sitting along the network path can modify, or read, the initial messages an=
d completely decrypt or modify the content. Thanks for posting!</div></div>=
</blockquote><div><br></div><div>I agree. It is severely underspecified. Ev=
en the acronym &quot;cttps&quot; is expanded to both=C2=A0 &quot;Crypto Tra=
nsfer Protocol Secure&quot; and &quot;Ciphered Text Transfer Protocol over =
SSL/Stream&quot;.=C2=A0</div><div><br></div><div>The request does not compl=
y with RFC 7595 Section 3.1 which states:</div><div><br></div><div>=C2=A0 =
=C2=A0 New schemes ought to have utility to the Internet community beyond t=
hat available with already registered schemes.</div><div><br></div>As it pr=
ovides no security against active attacks, it provides nothing that https:/=
/ doesn&#39;t already supply.</div><div class=3D"gmail_quote gmail_quote_co=
ntainer"><br></div><div class=3D"gmail_quote gmail_quote_container">The req=
uest does not comply with RFC 7595 Section 3.3 which states:</div><div clas=
s=3D"gmail_quote gmail_quote_container"><br></div><div class=3D"gmail_quote=
 gmail_quote_container">=C2=A0 =C2=A0a scheme definition itself MUST be cle=
ar as to how it is expected to<br>=C2=A0 =C2=A0function.=C2=A0 Schemes that=
 are not intended to be used as locators<br>=C2=A0 =C2=A0SHOULD describe ho=
w the resource identified can be determined or<br>=C2=A0 =C2=A0accessed by =
software that obtains a URI of that scheme.</div><div class=3D"gmail_quote =
gmail_quote_container"><br></div><div class=3D"gmail_quote gmail_quote_cont=
ainer">I believe the specification is completely unclear and unimplementabl=
e.</div><div class=3D"gmail_quote gmail_quote_container"><br></div><div cla=
ss=3D"gmail_quote gmail_quote_container">The requestion does not comply wit=
h RFC 7595 Section 3.4 which states:</div><div class=3D"gmail_quote gmail_q=
uote_container"><br></div><div class=3D"gmail_quote gmail_quote_container">=
=C2=A0 =C2=A0As part of the definition of how a URI identifies a resource, =
a<br>=C2=A0 =C2=A0scheme definition SHOULD define the applicable set of ope=
rations that<br>=C2=A0 =C2=A0can be performed on a resource using the URI a=
s its identifier. </div><div class=3D"gmail_quote gmail_quote_container"><b=
r></div><div class=3D"gmail_quote gmail_quote_container">This is completely=
 missing from the request.</div><div class=3D"gmail_quote gmail_quote_conta=
iner"><br></div><div class=3D"gmail_quote gmail_quote_container">Finally, R=
FC 7595 Section=C2=A03.7, &quot;Clear Security and Privacy Considerations&q=
uot; is clearly missing in its entirely,</div><div class=3D"gmail_quote gma=
il_quote_container">and the scheme seems to be completely insecure against =
active attackers.</div><div class=3D"gmail_quote gmail_quote_container"><br=
></div><div class=3D"gmail_quote gmail_quote_container"><br></div><div clas=
s=3D"gmail_quote gmail_quote_container">This provisional registration shoul=
d be rejected by the Designated Experts.</div><div class=3D"gmail_quote gma=
il_quote_container"><br></div><div class=3D"gmail_quote gmail_quote_contain=
er">Paul</div></div>

--000000000000b0aad406519f04ba--


--===============2993859883721910150==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KVXJpLXJldmll
dyBtYWlsaW5nIGxpc3QgLS0gdXJpLXJldmlld0BpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5k
IGFuIGVtYWlsIHRvIHVyaS1yZXZpZXctbGVhdmVAaWV0Zi5vcmcK

--===============2993859883721910150==--