MIME-Version: 1.0
References: <EB7DEE42-8EC4-4347-BA10-0EBF90CBF398@heapingbits.net>
In-Reply-To: <EB7DEE42-8EC4-4347-BA10-0EBF90CBF398@heapingbits.net>
From: Ben Schwartz <bemasc@google.com>
Date: Sun, 22 Mar 2020 17:49:45 -0400
Message-ID:
 <CAHbrMsDdxtPeyZhrCFDAq4kr3iXN=1Uc0c03_NZy1_iSw4cPLw@mail.gmail.com>
To: Christopher Wood <caw@heapingbits.net>
Cc: "TLS@ietf.org" <tls@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature";
 micalg=sha-256; boundary="000000000000f4a96605a1787f7b"
Archived-At:
 <https://mailarchive.ietf.org/arch/msg/tls/P8reGqBcYdJVVTHeIlY4pwYJwaA>
Subject: Re: [TLS] Dropping "do not stick out" from ECHO
Precedence: list

--000000000000f4a96605a1787f7b
Content-Type: multipart/alternative; boundary="000000000000ea411705a1787f7d"

--000000000000ea411705a1787f7d
Content-Type: text/plain; charset="UTF-8"

It might be helpful to have a more precise definition of "do not stick out".

Considering a passive intermediary on the network path who cannot see the
DNS path, I can think of a few different "not stick out" properties we
might want:

1. The intermediary cannot identify clients that support ECHO.
2. The intermediary cannot identify servers that support ECHO.
2a. ... based on the connection contents alone.
3. The intermediary cannot tell whether ECHO was actually used.
3a ... based on the connection contents alone.

ECHO currently does not have Property 1.
Property 2 seems unlikely to be achievable in practice.  By publishing an
ECHOConfig, the server reveals its support for ECHO to everyone.  Chris
also noted a way to probe directly for confirmation.
Property 2a seems to be the topic at hand.
Property 3/3a relies on GREASE.  Like Property 2, Property 3 is (normally)
easily broken by an intermediary with a database of published ECHOConfigs.
[*]

I'm OK with losing Property 2a.  However, Property 3a seems achievable and
potentially valuable.  Consider a network where most clients support ECHO
and use GREASE, but only a minority can actually fetch ECHOConfigs, e.g.
ECHOConfig fetching requires the user to change their DNS configuration.
An intermediary who wants to record all SNIs could block only the
connections that actually activate ECHO, forcing clients to revert their
DNS configuration change and reveal the SNI.  Limiting this blocking to
public names that the intermediary is aware of seems like a worthwhile
step, especially since these names can be rotated relatively rapidly
(~minutes).

Property 3a is compatible with a flag in the ServerHello, so long as the
flag says "ECHO in use" when actually GREASE is in use.  This could be
achieved by reporting "ECHO in use" whenever the SNI is not a Public Name
used by the server (assuming it is not an actual origin name), or adding a
"long term ID" field (at least 32 bits) to ECHOConfig that persists across
key rotations.

Perhaps a good approach would be a flag meaning "ECHO retry in use".
(Would it be safe to move "retry_keys" to the unencrypted extensions?)

--Ben Schwartz

P.S. Ideally, I still want Property 1.  I imagine it might be possible by
formatting the ECHO as 0-RTT data, as Christian Huitema and others have
discussed over the years.

[*] Actual ECHO ClientHellos to a server at some IP will have the Public
Name in the SNI field, whereas GREASE ClientHellos will have the origin
name there instead.  However, if the ECHOConfig Public Name is in fact a
valid origin, then (with sufficiently good GREASE) the intermediary is
unable to state with certainty whether any particular user visited that
domain, even if many users cannot actually fetch ECHOConfigs.  In the
extreme, a server could publish a slate of ECHOConfigs that name _all_ of
its domains as Public Names, so that seeing any of them in the SNI field is
not proof of anything.

On Sun, Mar 22, 2020 at 12:55 PM Christopher Wood <caw@heapingbits.net>
wrote:

> One of the original motivating requirements for ECHO (then ENSI) was "do
> not stick
> out" [1]. This complicates the current ECHO design, as clients must
> trial decrypt
> the first encrypted handshake message to determine whether a server used
> the inner
> or outer ClientHello for a given connection. It's also trivial to probe
> for ECHO
> support, e.g., by sending a bogus ECHO with the same key ID used in a
> target client
> connection and checking what comes back.
>
> I propose we remove this requirement and add an explicit signal in SH
> that says
> whether or not ECHO was negotiated. (This will require us to revisit
> GREASE.)
>
> What do others think?
>
> Thanks,
> Chris (no hat)
>
> [1]
> https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-09#section-3.4
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--000000000000ea411705a1787f7d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>It might be helpful to have a more precise definition=
 of &quot;do not stick out&quot;.</div><div><br></div><div>Considering a pa=
ssive intermediary on the network path who cannot see the DNS path, I can t=
hink of a few different &quot;not stick out&quot; properties we might want:=
</div><div><br></div><div>1. The intermediary cannot identify clients that =
support ECHO.<br></div><div>2. The intermediary cannot identify servers tha=
t support ECHO.</div><div>2a. ... based on the connection contents alone.</=
div><div>3. The intermediary cannot tell whether ECHO was actually used.<br=
></div><div>3a ... based on the connection contents alone.</div><div><br></=
div><div>ECHO currently does not have Property 1.=C2=A0</div><div>Property =
2 seems unlikely to be achievable in practice.=C2=A0 By publishing an ECHOC=
onfig, the server reveals its support for ECHO to=C2=A0everyone.=C2=A0 Chri=
s also noted a way to probe directly for confirmation.</div><div>Property 2=
a seems to be the topic at hand.</div><div>Property 3/3a relies on GREASE.=
=C2=A0 Like Property 2, Property 3 is (normally) easily broken by an interm=
ediary with a database of published ECHOConfigs. [*]</div><div><br></div><d=
iv>I&#39;m OK with losing Property 2a.=C2=A0 However, Property 3a seems ach=
ievable and potentially valuable.=C2=A0 Consider a network where most clien=
ts support ECHO and use GREASE, but only a minority can actually fetch ECHO=
Configs, e.g. ECHOConfig fetching requires the user to change their DNS con=
figuration.=C2=A0 An intermediary who wants to record all SNIs could block =
only the connections that actually activate ECHO, forcing clients to revert=
 their DNS configuration change and reveal the SNI.=C2=A0 Limiting this blo=
cking to public names that the intermediary is aware of seems like a worthw=
hile step, especially since these names can be rotated relatively rapidly (=
~minutes).=C2=A0</div><div><br></div><div>Property 3a is compatible with a =
flag in the ServerHello, so long as the flag says &quot;ECHO in use&quot; w=
hen actually GREASE is in use.=C2=A0 This could be achieved by reporting &q=
uot;ECHO in use&quot; whenever the SNI is not a Public Name used by the ser=
ver (assuming it is not an actual origin name), or adding a &quot;long term=
 ID&quot; field (at least 32 bits) to ECHOConfig that persists across key r=
otations.</div><div><br></div><div>Perhaps a good approach would be a flag =
meaning &quot;ECHO retry in use&quot;.=C2=A0 (Would it be safe to move &quo=
t;retry_keys&quot; to the unencrypted extensions?)</div><div><br></div><div=
>--Ben Schwartz</div><div><br></div><div>P.S. Ideally, I still want Propert=
y 1.=C2=A0 I imagine it might be possible by formatting the ECHO as 0-RTT d=
ata, as Christian Huitema and others have discussed over the years.</div><d=
iv></div><div></div><div><br></div><div>[*] Actual ECHO ClientHellos to a s=
erver at some IP will have the Public Name in the SNI field, whereas GREASE=
 ClientHellos will have the origin name there instead.=C2=A0 However, if th=
e ECHOConfig Public Name is in fact a valid origin, then (with sufficiently=
 good GREASE) the intermediary is unable to state with certainty whether an=
y particular user visited that domain, even if many users cannot actually f=
etch ECHOConfigs.=C2=A0 In the extreme, a server could publish a slate of E=
CHOConfigs that name _all_ of its domains as Public Names, so that seeing a=
ny of them in the SNI field is not proof of anything.</div><div><br></div><=
div dir=3D"ltr">On Sun, Mar 22, 2020 at 12:55 PM Christopher Wood &lt;<a hr=
ef=3D"mailto:caw@heapingbits.net">caw@heapingbits.net</a>&gt; wrote:<br></d=
iv><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex">One of the original motivating requirements for ECHO (then ENSI) was &=
quot;do <br>
not stick<br>
out&quot; [1]. This complicates the current ECHO design, as clients must <b=
r>
trial decrypt<br>
the first encrypted handshake message to determine whether a server used <b=
r>
the inner<br>
or outer ClientHello for a given connection. It&#39;s also trivial to probe=
 <br>
for ECHO<br>
support, e.g., by sending a bogus ECHO with the same key ID used in a <br>
target client<br>
connection and checking what comes back.<br>
<br>
I propose we remove this requirement and add an explicit signal in SH <br>
that says<br>
whether or not ECHO was negotiated. (This will require us to revisit <br>
GREASE.)<br>
<br>
What do others think?<br>
<br>
Thanks,<br>
Chris (no hat)<br>
<br>
[1] <br>
<a href=3D"https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-09#sec=
tion-3.4" rel=3D"noreferrer" target=3D"_blank">https://tools.ietf.org/html/=
draft-ietf-tls-sni-encryption-09#section-3.4</a><br>
<br>
_______________________________________________<br>
TLS mailing list<br>
<a href=3D"mailto:TLS@ietf.org" target=3D"_blank">TLS@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/tls" rel=3D"noreferrer" ta=
rget=3D"_blank">https://www.ietf.org/mailman/listinfo/tls</a><br>
</blockquote></div></div>

--000000000000ea411705a1787f7d--

--000000000000f4a96605a1787f7b
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIPBgYJKoZIhvcNAQcCoIIO9zCCDvMCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg
ggxpMIIEkjCCA3qgAwIBAgINAewckktV4F6Q7sAtGDANBgkqhkiG9w0BAQsFADBMMSAwHgYDVQQL
ExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMK
R2xvYmFsU2lnbjAeFw0xODA2MjAwMDAwMDBaFw0yODA2MjAwMDAwMDBaMEsxCzAJBgNVBAYTAkJF
MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSEwHwYDVQQDExhHbG9iYWxTaWduIFNNSU1FIENB
IDIwMTgwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCUeobu8FdB5oJg6Fz6SFf8YsPI
dNcq4rBSiSDAwqMNYbeTpRrINMBdWuPqVWaBX7WHYMsKQwCOvAF1b7rkD+ROo+CCTJo76EAY25Pp
jt7TYP/PxoLesLQ+Ld088+BeyZg9pQaf0VK4tn23fOCWbFWoM8hdnF86Mqn6xB6nLsxJcz4CUGJG
qAhC3iedFiCfZfsIp2RNyiUhzPAqalkrtD0bZQvCgi5aSNJseNyCysS1yA58OuxEyn2e9itZJE+O
sUeD8VFgz+nAYI5r/dmFEXu5d9npLvTTrSJjrEmw2/ynKn6r6ONueZnCfo6uLmP1SSglhI/SN7dy
L1rKUCU7R1MjAgMBAAGjggFyMIIBbjAOBgNVHQ8BAf8EBAMCAYYwJwYDVR0lBCAwHgYIKwYBBQUH
AwIGCCsGAQUFBwMEBggrBgEFBQcDCTASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBRMtwWJ
1lPNI0Ci6A94GuRtXEzs0jAfBgNVHSMEGDAWgBSP8Et/qC5FJK5NUPpjmove4t0bvDA+BggrBgEF
BQcBAQQyMDAwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwMi5nbG9iYWxzaWduLmNvbS9yb290cjMw
NgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LXIzLmNybDBn
BgNVHSAEYDBeMAsGCSsGAQQBoDIBKDAMBgorBgEEAaAyASgKMEEGCSsGAQQBoDIBXzA0MDIGCCsG
AQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG9w0B
AQsFAAOCAQEAwREs1zjtnFIIWorsx5XejqZtqaq5pomEvpjM98ebexngUmd7hju2FpYvDvzcnoGu
tjm0N3Sqj5vvwEgvDGB5CxDOBkDlmUT+ObRpKbP7eTafq0+BAhEd3z2tHFm3sKE15o9+KjY6O5bb
M30BLgvKlLbLrDDyh8xigCPZDwVI7JVuWMeemVmNca/fidKqOVg7a16ptQUyT5hszqpj18MwD9U0
KHRcR1CfVa+3yjK0ELDS+UvTufoB9wp2BoozsqD0yc2VOcZ7SzcwOzomSFfqv7Vdj88EznDbdy4s
fq6QvuNiUs8yW0Vb0foCVRNnSlb9T8//uJqQLHxrxy2j03cvtTCCA18wggJHoAMCAQICCwQAAAAA
ASFYUwiiMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIz
MRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5MDMxODEwMDAw
MFoXDTI5MDMxODEwMDAwMFowTDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzAR
BgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQDMJXaQeQZ4Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0EXyTLLkvhYIJG
4VKrDIFHcGzdZNHr9SyjD4I9DCuul9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+JJ5U4nwbXPsnL
JlkNc96wyOkmDoMVxu9bi9IEYMpJpij2aTv2y8gokeWdimFXN6x0FNx04Druci8unPvQu7/1PQDh
BjPogiuuU6Y6FnOM3UEOIDrAtKeh6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTvriBJ/K1AFUjR
AjFhGV64l++td7dkmnq/X8ET75ti+w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGjQjBAMA4GA1Ud
DwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5NUPpjmove4t0b
vDANBgkqhkiG9w0BAQsFAAOCAQEAS0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigHM8pr5nS5ugAt
rqQK0/Xx8Q+Kv3NnSoPHRHt44K9ubG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmUY/vcU2hnVj6D
uM81IcPJaP7O2sJTqsyQiunwXUaMld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V14qWtNPeTCek
TBtzc3b0F5nCH3oO4y0IrQocLP88q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcya5QBqJnnLDMf
Ojsl0oZAzjsshnjJYS8Uuu7bVW/fhO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/XzCCBGwwggNU
oAMCAQICEAGuEkclHdvQz4ddwMbsMFgwDQYJKoZIhvcNAQELBQAwSzELMAkGA1UEBhMCQkUxGTAX
BgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExITAfBgNVBAMTGEdsb2JhbFNpZ24gU01JTUUgQ0EgMjAx
ODAeFw0yMDAxMDcwODIyMjJaFw0yMDA3MDUwODIyMjJaMCIxIDAeBgkqhkiG9w0BCQEWEWJlbWFz
Y0Bnb29nbGUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwrwIVY3rOZp1Papu
Yl53bMQ2H713K9788lbE9itKEL7tJAJO7GqZGRbfxPUVRRDYPntAf+j0JZZOvf9Ye6uN12SNW+v1
V0o5YeXtXMpNOkprr0v0v7qc80yhbq8RIIiX4usDJwuDGbcL/VKnlCTDPRp+VWUB8rkaqObapi/F
BGiPWXBqiT36W5opr6eJjUHuGiqzmK/1lCXMZSn6n3wkkbnonFsF5G4kfie+n/DDNd1hlqd06bzB
rCnToS+BV/Y9BroXiOjVWJnMe/8Rce7zA8Dzr0kU+gacBArnMiDyCvUGjngbASU7VaIPJBc/zBzI
L5QoeUAfgEJcGvFIEJUUIwIDAQABo4IBczCCAW8wHAYDVR0RBBUwE4ERYmVtYXNjQGdvb2dsZS5j
b20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4E
FgQU+WKCBtTdknJDbiAjMsikOsbLHoAwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEF
BQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wUQYIKwYBBQUHAQEE
RTBDMEEGCCsGAQUFBzAChjVodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc3Nt
aW1lY2EyMDE4LmNydDAfBgNVHSMEGDAWgBRMtwWJ1lPNI0Ci6A94GuRtXEzs0jA/BgNVHR8EODA2
MDSgMqAwhi5odHRwOi8vY3JsLmdsb2JhbHNpZ24uY29tL2NhL2dzc21pbWVjYTIwMTguY3JsMA0G
CSqGSIb3DQEBCwUAA4IBAQA2eHjHcJ8kaiqDQGv7TdNEBFiDI8omlzpnnuQFciHkWhkfi3mQwuuZ
IQIHd+JNpV0TQ8TqMNAr4YSPWOjwTd3UNxm+qghV3KC9j/Ygq39OzUlqxWv2lFH8mGFpbview2GI
xZWXTCRbeod3ZevhC0lOUVVx4NCHe5yWSwjEpZHUilSnjyqN7ssC0eYQBylFOf2xVxu1JB8Xewgw
Vk/DeOzsapxxjiuw2UZsDZbtVJvEx/C34GkACLR4Lm0k6O5ujAiDBkyy2nklxLhmKb9fyiH51B3j
oRE8y99FJOCHoye9E/P2tK12x9w9ZeF07eWAdX3OkhTne1DitwLidojuyFm9MYICYTCCAl0CAQEw
XzBLMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEhMB8GA1UEAxMYR2xv
YmFsU2lnbiBTTUlNRSBDQSAyMDE4AhABrhJHJR3b0M+HXcDG7DBYMA0GCWCGSAFlAwQCAQUAoIHU
MC8GCSqGSIb3DQEJBDEiBCDFdWP7ZYcZtTVXhfiDe6Z1fIcf22PChZdYtPCP4+iypjAYBgkqhkiG
9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDAzMjIyMTQ5NThaMGkGCSqGSIb3
DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAE
ggEAcBUToQ6kUlemi7GzxzcZQtARcB37ZUPUxi/vf1tb75SEYPFMHNaPmgInF5+2vh1SAVrTwUXB
0syxt52HvKFPoNGGjeUZt02JE2j4veYWgJPG/4IaH6jbZ1IsXRLTU3RS9EVLZjEJcoPlKF4ExnZW
h7ozY05KDGuyBYKNL/IjUazivwWpgnYd5ABde+hFY3KZKqpTxx0WcXwYyS0XlKUJ0+/9YD1mh4FH
ur9/WAFxKaosdiGGSV5RtGkwBUCMPw+fZkfCfppkMG1Cjvo9M0RHMqPd4p/899b6qBGXmmfor1r7
3bNXcJWBC4dBi+MfNkXHtDk51KKiCDvm6LELaSqEjA==
--000000000000f4a96605a1787f7b--