From nobody Fri Mar 26 06:44:50 2021 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4E13A1F13 for ; Fri, 26 Mar 2021 06:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHmuzz4NqZB7 for ; Fri, 26 Mar 2021 06:44:46 -0700 (PDT) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1162E3A1F2A for ; Fri, 26 Mar 2021 06:44:43 -0700 (PDT) Received: by mail-wr1-x42b.google.com with SMTP id j7so5734067wrd.1 for ; Fri, 26 Mar 2021 06:44:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YLAtd8mydvfntiDWdUB503P7gJyCgjjgW2d4sg8k5WE=; b=pKT6PSynWJ3cDXEqEZ33MfLuDtmKSv10JKjQKxXgOWaBIZjRk9lAjsT1oVKJtXRe90 P8Ye0dj1gQprtv4PvaI/Z2knlPW3P/EOakOPZVQvmDYMEpEW45CpMqTVLiscDWVEK1k1 rtNjwo4vgTGIl8bGNNHMzVlby7aKL9EK/qlDIkhWT5Fkjz1w3/iDTzz5Y0BujQsGeMXo nL3JxiTpvz/OuRZoaVGuxL6MVp2EZBL4lQIqKazZ4ZwoqoQzNtKD7ohRBNiNhDX7/ToM cOQ5hGiPYuwb3SaAurpqZRK9R5KOoGRQbe4Ivn1kxLHVDvu219mW+55fRUmIlnPJL4dJ l6ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YLAtd8mydvfntiDWdUB503P7gJyCgjjgW2d4sg8k5WE=; b=Kw/ZZN6WOvTPQk1/Mt/l/iG08fl9wgnXVEMOGTiD73EnD4IgFfV9JZF6wTE92BswBx yAh+0oJiUS3Zfq+CctSyFlhYJx4FyurqDmEgkLvYPorgn03aVTbo0hB/P07j5OZ5r+l3 O1hHoNFmFC+9mMuoYwcatSdHjBbq6gZDS0lxWoVE9wtmQClOOPC1UvmP5RnGVE5SP9pw f7FfL225x+R2/333LPIDfv+SvzfmhQ8wLtuBNGcrZrpI1vKbjQaLYnIxVbkvaYbt5nUH M8b0YM+8gRuZ3zog63zo85eZoDc/KGrDYLHiI6mLTCf5hD7QRvf8vlnEGV+JrPiwCAHD s6qA== X-Gm-Message-State: AOAM532smlI433VRHkBT+cakiUGyQxgJNXOBS0CZFyK0UqaajlYkObY1 xWA4Cb3VVS9luwnU1Vhl8w1x5Hb7bkGTWAxUOvtCzarFCls= X-Google-Smtp-Source: ABdhPJzIY0j6foNlEBRHZIhPYYkdguoC9rp1aqYkz0o6D0jgX8Jqaop+TebMwO2F7wdgQSOqzRvvDUWHUem4KnoSeVE= X-Received: by 2002:adf:ee0a:: with SMTP id y10mr13986804wrn.177.1616766280954; Fri, 26 Mar 2021 06:44:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ben Schwartz Date: Fri, 26 Mar 2021 09:44:28 -0400 Message-ID: To: Nick Sullivan Cc: Christopher Patton , "" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000e1a68b05be70bb4f" Archived-At: Subject: Re: [TLS] Solving HRR woes in ECH X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2021 13:44:49 -0000 --000000000000e1a68b05be70bb4f Content-Type: multipart/alternative; boundary="000000000000dccbea05be70bb95" --000000000000dccbea05be70bb95 Content-Type: text/plain; charset="UTF-8" This seems like a reasonable suggestion to me, so long as the value is purely a "hint", as you seem to be proposing. I would suggest structuring it as an ECHConfig extension. This would avoid the need for multiple points of integration between TLS and DNS, support the use of HRR hints in other ECH use cases that don't involve DNS, and help to exercise the ECHConfig extension mechanism. On Thu, Mar 25, 2021 at 9:28 PM Nick Sullivan wrote: > Hi Chris, > > HRR in ECH does seem challenging. This may be tangential to the PR you > linked, but there may be a way to reduce the likelihood of HRR by moving > even more of the handshake negotiation into DNS. The HTTPS RR is already > used for some types of negotiation (ALPN and ECH key), so why can't it be > extended further to advertise to the client what the server is willing to > support for cryptographic negotiations? > > For example, the HTTPS record could additionally contain the server's > supported supported_groups and cipher_suites. With this information, a > client could know which key_share extensions a server is likely to accept > and adjust its clienthello accordingly. A client who typically sends two > key_shares (P256 and x25519) for maximal compatibility could then reduce > the size of its client hello (no need to send redundant key_shares) or even > prevent an HRR flow altogether in the case that the default key_shares or > cipher_suites are not supported by the server. > > This tweak wouldn't remove the need for HRR completely -- it could be > necessary when changing server configuration, for example -- but it could > remove the need for HRR in the common case. > > Nick > > On Thu, Mar 25, 2021 at 8:05 PM Christopher Patton 40cloudflare.com@dmarc.ietf.org> wrote: > >> Hi all, >> >> One of the open issues for ECH is how it interacts with HelloRetryRequest >> (HRR). The central difficulty is that a client may advertise different >> preferences for HRR-sensitive parameters in the ClientHelloInner and >> ClientHelloOuter. And because the HRR path has no explicit signal of which >> ClientHello was used, the client may not be able to know how to respond. >> The following PR solves this problem by adding to HRR an explicit signal of >> which ClientHello was used: >> https://github.com/tlswg/draft-ietf-tls-esni/pull/407 >> >> The design was originally proposed by David Benjamin in the issue >> referenced by the PR. Along the way, It also solves a handful of other HRR >> issues that have been identified. >> >> One consequence of this particular solution is that real ECH usage >> "sticks out" if the server responds with an HRR. In particular, signaling >> which ClientHello was used also signals whether ECH was accepted. However, >> the solution is designed to mitigate "don't stick out" attacks that attempt >> to trigger the HRR codepath by fiddling with bits on the wire. The >> distinguisher only arises when HRR happens organically. >> >> Feedback is appreciated! >> >> Best, >> Chris P. >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000dccbea05be70bb95 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This seems like a reasonable suggestion to me, so long as = the value is purely a "hint", as you seem to be proposing.=C2=A0 = I would suggest structuring it as an ECHConfig extension.=C2=A0 This would = avoid the need for multiple points of integration between TLS and DNS, supp= ort the use of HRR hints in other ECH use cases that don't involve DNS,= and help to exercise the ECHConfig extension mechanism.

On Thu, Mar 25, 202= 1 at 9:28 PM Nick Sullivan <nick=3D40cloudflare.com@dmarc.ietf.org> wrote:
Hi Chris,
HRR in ECH does seem challenging. This may be tangential to= the PR you linked, but there may be a way to reduce the likelihood o= f HRR by moving even more of the handshake negotiation into DNS.=C2=A0The H= TTPS RR is already used for some types of negotiation (ALPN and ECH key), s= o why can't it be extended=C2=A0further to advertise to the client what= the server is willing to support for cryptographic negotiations?

For example, the HTTPS record cou= ld additionally contain the server's supported=C2=A0supported_gr= oups and=C2=A0cipher_suites. With this information, a client could kn= ow which key_share extensions a server is likely to accept and adjust its c= lienthello accordingly. A client who typically sends two key_shares (P256 a= nd x25519) for maximal compatibility could then reduce the size of its clie= nt hello (no need to send redundant key_shares) or even prevent an HRR flow= altogether in the case that the default key_shares or cipher_suites are no= t supported by the server.

This tweak wouldn't remove the need for HRR completely -- it cou= ld=C2=A0be necessary when changing server configuration, for example -- but= it could remove the need for HRR in the common case.

Nick

On Thu, Mar 25, 2021 at 8:05 PM Christopher= Patton <cpatton=3D40cloudflare.com@dmarc.ietf.org> wrote:
Hi all= ,

= One of the open issues for ECH is how i= t interacts with HelloRetryRequest (HRR). The central difficulty is that a = client may advertise different preferences for HRR-sensitive parameters in = the ClientHelloInner and ClientHelloOuter. And because the HRR path has no = explicit signal of which ClientHello was used, the client may not be able t= o know how to respond. The following PR solves this problem by adding to HR= R an explicit signal of which ClientHello was used:
=
The design was or= iginally proposed by David Benjamin in the issue referenced by the PR. Alon= g the way, It also solves a handful of other HRR issues that have been iden= tified.

One consequence of this particu= lar solution is that real ECH usage "sticks out" if the server re= sponds with an HRR. In particular, signaling which ClientHello was used als= o signals whether ECH was accepted. However, the solution is designed to mi= tigate "don't stick out" attacks that attempt to trigger the = HRR codepath by fiddling with bits on the wire. The distinguisher only aris= es when HRR happens organically.

Fe= edback is appreciated!

Best,
=
Chris P.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000dccbea05be70bb95-- --000000000000e1a68b05be70bb4f Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIPmAYJKoZIhvcNAQcCoIIPiTCCD4UCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ggzyMIIEtjCCA56gAwIBAgIQeAMYYHb81ngUVR0WyMTzqzANBgkqhkiG9w0BAQsFADBMMSAwHgYD VQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UE AxMKR2xvYmFsU2lnbjAeFw0yMDA3MjgwMDAwMDBaFw0yOTAzMTgwMDAwMDBaMFQxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIEF0bGFz IFIzIFNNSU1FIENBIDIwMjAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCvLe9xPU9W dpiHLAvX7kFnaFZPuJLey7LYaMO8P/xSngB9IN73mVc7YiLov12Fekdtn5kL8PjmDBEvTYmWsuQS 6VBo3vdlqqXZ0M9eMkjcKqijrmDRleudEoPDzTumwQ18VB/3I+vbN039HIaRQ5x+NHGiPHVfk6Rx c6KAbYceyeqqfuJEcq23vhTdium/Bf5hHqYUhuJwnBQ+dAUcFndUKMJrth6lHeoifkbw2bv81zxJ I9cvIy516+oUekqiSFGfzAqByv41OrgLV4fLGCDH3yRh1tj7EtV3l2TngqtrDLUs5R+sWIItPa/4 AJXB1Q3nGNl2tNjVpcSn0uJ7aFPbAgMBAAGjggGKMIIBhjAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHzM CmjXouseLHIb0c1dlW+N+/JjMB8GA1UdIwQYMBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MHsGCCsG AQUFBwEBBG8wbTAuBggrBgEFBQcwAYYiaHR0cDovL29jc3AyLmdsb2JhbHNpZ24uY29tL3Jvb3Ry MzA7BggrBgEFBQcwAoYvaHR0cDovL3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvcm9vdC1y My5jcnQwNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LXIz LmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5n bG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEANyYcO+9JZYyqQt41 TMwvFWAw3vLoLOQIfIn48/yea/ekOcParTb0mbhsvVSZ6sGn+txYAZb33wIb1f4wK4xQ7+RUYBfI TuTPL7olF9hDpojC2F6Eu8nuEf1XD9qNI8zFd4kfjg4rb+AME0L81WaCL/WhP2kDCnRU4jm6TryB CHhZqtxkIvXGPGHjwJJazJBnX5NayIce4fGuUEJ7HkuCthVZ3Rws0UyHSAXesT/0tXATND4mNr1X El6adiSQy619ybVERnRi5aDe1PTwE+qNiotEEaeujz1a/+yYaaTY+k+qJcVxi7tbyQ0hi0UB3myM A/z2HmGEwO8hx7hDjKmKbDCCA18wggJHoAMCAQICCwQAAAAAASFYUwiiMA0GCSqGSIb3DQEBCwUA MEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIzMRMwEQYDVQQKEwpHbG9iYWxTaWdu MRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5MDMxODEwMDAwMFoXDTI5MDMxODEwMDAwMFowTDEg MB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24xEzAR BgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMJXaQeQZ4 Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0EXyTLLkvhYIJG4VKrDIFHcGzdZNHr9SyjD4I9DCuu l9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+JJ5U4nwbXPsnLJlkNc96wyOkmDoMVxu9bi9IEYMpJ pij2aTv2y8gokeWdimFXN6x0FNx04Druci8unPvQu7/1PQDhBjPogiuuU6Y6FnOM3UEOIDrAtKeh 6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTvriBJ/K1AFUjRAjFhGV64l++td7dkmnq/X8ET75ti +w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGjQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8E BTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5NUPpjmove4t0bvDANBgkqhkiG9w0BAQsFAAOCAQEA S0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigHM8pr5nS5ugAtrqQK0/Xx8Q+Kv3NnSoPHRHt44K9u bG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmUY/vcU2hnVj6DuM81IcPJaP7O2sJTqsyQiunwXUaM ld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V14qWtNPeTCekTBtzc3b0F5nCH3oO4y0IrQocLP88 q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcya5QBqJnnLDMfOjsl0oZAzjsshnjJYS8Uuu7bVW/f hO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/XzCCBNEwggO5oAMCAQICEAGnjs1119HDOsp/SPG0 XFowDQYJKoZIhvcNAQELBQAwVDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExKjAoBgNVBAMTIUdsb2JhbFNpZ24gQXRsYXMgUjMgU01JTUUgQ0EgMjAyMDAeFw0yMTAyMDUy MzQzNTNaFw0yMTA4MDQyMzQzNTNaMCIxIDAeBgkqhkiG9w0BCQEWEWJlbWFzY0Bnb29nbGUuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1N1uLicDVgtwM9oEggVS/tZ2KAmVdmTJ 5M/y8wlsQeOhdi3DS1kW1U4GywSj64bAhRF1Q8EWWv0eaZuU24dK638JYvl4X4ap99mFyGmsySPS bE+Q/fAsRkpLfRSXK+5ZjZ39ySwTgLsi62BLykDCnxKFv0h5ASmO/jQCfSxTshXQ+b5SRa8xy9/k noIBnT1k3g3Sx86NEzOqFcijEiojz/jhJ7qw2h/CQjlEpgvCKAFgY4DCop6exC8B6eoYS9Lj+/Sc hw2lAfqtueTuMqJErzrSeZcBwys262nOleJN9d1HTfkudv3NAeaPYmyaoYFZXQ1QeAklli0mqaqz odfLmQIDAQABo4IBzzCCAcswHAYDVR0RBBUwE4ERYmVtYXNjQGdvb2dsZS5jb20wDgYDVR0PAQH/ BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQUq0QyOyj+YgHX /rWYb/NHQJkioe4wTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEFBQcCARYmaHR0cHM6 Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wCQYDVR0TBAIwADCBmgYIKwYBBQUHAQEE gY0wgYowPgYIKwYBBQUHMAGGMmh0dHA6Ly9vY3NwLmdsb2JhbHNpZ24uY29tL2NhL2dzYXRsYXNy M3NtaW1lY2EyMDIwMEgGCCsGAQUFBzAChjxodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2Nh Y2VydC9nc2F0bGFzcjNzbWltZWNhMjAyMC5jcnQwHwYDVR0jBBgwFoAUfMwKaNei6x4schvRzV2V b4378mMwRgYDVR0fBD8wPTA7oDmgN4Y1aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9jYS9nc2F0 bGFzcjNzbWltZWNhMjAyMC5jcmwwDQYJKoZIhvcNAQELBQADggEBAELHe2QqUz+Zoz832czTA7nh YMGb1UtuDhhJXGtQa30WhBzFxDw2KvYIT9bB176l/g5RXu9hjgPlNP39BJq+CN7aGp/nYsDUJv+c G/eTn+Lj4aRCXWbcNuetApMvbje/Blk4KfyrBJ6Bef/WGrV+9NLYZU06iOAe7ZIivEzvekianGAQ psQx9DfKqOsP6wGIxXEilIXPLDIObDnXRhYYJQcctmnSQbo3lD8kubWcV1PMRIo9B7T2T6Ao34Hi g2h43eaUHej4E1WVUW0LkqXKtQsAQhwc2QqE8D+MSC79Qn+ke6j3IG4Xef9+b0BGgDJCeftOvpCQ ZVJ3jM316xykETAxggJqMIICZgIBATBoMFQxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxT aWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIEF0bGFzIFIzIFNNSU1FIENBIDIwMjACEAGn js1119HDOsp/SPG0XFowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIE0OoTcOPC8+ XgyOAfBD7+mcLN+xLVTLix4e04GuiuXgMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTIxMDMyNjEzNDQ0MVowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJ YIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcN AQEHMAsGCWCGSAFlAwQCATANBgkqhkiG9w0BAQEFAASCAQCJrCuuMaDgTC3vtYsGOHhKVfkfz5XI ZsGdlQL9o4ukuTgAV8N8EwBM6OEk5LYAdL086oDoiFdJeZOl4uuxzZ0iETmv0p3R4vWnzprlc1Kt GH2MYvelPA/ZKd1gUd40N7dtMQ0J/DI0Fz/wNFbleT2nWlhdtyVn5QNfYqUUj1rZHWb1hyDVZ7Ga 2VhWgwVXLPIGQ/jYtUgosMZ9V0NUsaBBA4YTBkLbPKUNF4GTpK4YUZ7NOC0vWojSEzODfIAH5hXi QDIClUizXokmtp+xfP54oW5Ukg+kv4kgH4DSc67psFdISr/MmW4FNNJF+72la5W4TMa9KDz/H1WG s93lal/a --000000000000e1a68b05be70bb4f--